<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Well the situation is a bit more complicated. Our application is built
under the DBC database framework which is not free. I have access to
the source code of our application but it is DBC source code, and will
only run under the DBC framework. The program works fine under
windows, and is supposed to build a blank page, pull a TIF imaged
document from a master image folder, resize the TIF to fit the blank
page, apply the image to the page, then draw a box at the lower
right-hand corner of the page with the volume and page of the hard copy
volume that the image came from. When we print through Wine, we only
get one error message about Hatches related to the drawing of the box,
but the box and volume/page numbers always print correctly. The TIF
image, however, is always solid black. I built a perl script that
listens on a socket and dumps everything it receives to a file, then
set this up as an socket printer in my cups config twice. Once using
the PPD file that I use for the system printers, and again using a
generic postscript ppd file. Printing to each printer gives me the
same results. When I view the file in ghostscript, the page looks
identical to what comes out of the printer, i.e. solid black images but
the volume/page box prints correctly. The only difference is that in
ghostscript you can see a solid red line about 1/4" wide across the
bottom of the page.<br>
<br>
I'm not sure why the problem works differently on windows then in wine,
but it has to be in interpretation of the TIF images and the way they
are embedded into the post script file. With the complicated licensing
involved in DBC I don't know how I could get a version to anyone for
testing, but I would imagine I could make arrangements for a test
system to be set up that a developer could access by remote if need be.<br>
<br>
In the meantime, however, I need to know the answer to my original
question about whether or not a program running under wine can execute
programs in linux native mode. We have to have some sort of work
around on this ASAP as it is holding up a major project for our company.<br>
<br>
Thanks,<br>
Brent Davidson<br>
<br>
<br>
<br>
L. Rahyen wrote:
<blockquote cite="mid:200711161752.37808.research@science.su"
type="cite">
<pre wrap="">On Friday November 16 2007 16:14, Brent Davidson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">If I have an application running under wine, and it, in turn, calls a
system command, could it call that command in the Linux format, or would
the command be spawned in "wine space" for lack of a better term?
I'm trying to solve a printing problem where my application cannot
correctly print TIF files under wine due to errors in the way the
database framework it's built on builds the postscript spool file. The
solution I'm thinking of is to modify the app so that all print requests
create a randomly-named postscript file in a temp directory then have
the program call "lpr -r filename" on the file so that it will bypass
wine to print the PDF. I have verified that the PDF's built by the
system print correctly under Linux. Of course, if the program running
under wine is can only run Win/DOS applications, then this solution
won't work. Might have to install Irfan View on the on the linux box
and use that to print the PDF via wine. Everything we try to do with
this application is too d**n convoluted but it's a custom app and there
is nothing on the market that even comes close to having all the special
features we've had added over the last 3 years.
</pre>
</blockquote>
<pre wrap=""><!---->
If your application works fine under Windows, you have correct setup and
fresh WINE version, everything should work for you. Of course sometimes it
doesn't; in this case try to upgrade to newest WINE version (currently
0.9.49) and run:
mv ~/.wine{,.backup}
wineprefixcreate
wine setup.exe
cd ~/.wine/drive_c/Program\ Files/MyApp/
wine myapp.exe
Where "setup.exe" is an installer of your program. If still doesn't work then
this is a bug to be reported at <a class="moz-txt-link-freetext" href="http://bugs.winehq.org">http://bugs.winehq.org</a> .
Of course if your application isn't free and you cannot (or don't want to)
make it downloadable it may be somewhat more difficult to fix the bug (but
possible if you create useful bug report with detailed information about your
problem).
As far as I understand you have access to the source code? Is this correct?
If so it should be very easy to create almost "empty" Windows application
with just one function: printing of test TIF file that works on Windows but
doesn't work on WINE yet. And then attach source code and executable of this
simple test app to your bug report. This should help to fix the bug faster.
Thank you for using WINE.
</pre>
</blockquote>
</body>
</html>