John asked
[ How do I launch Windows apps from Unix apps and pass filenames to them?] execl (the_path_to_wine, "wine", path_to_the_windows_program, command_line_parameter_for_windows_app, NULL);
Relative unix paths will often work with Windows apps, but in general, you will have to translate command_line_parameter_for_windows_app, and any paths that appear in data files, from Unix to Windows before launching the app. The winepath utility may help there, or you can translate them yourself once you know how Wine maps filenames.
Also, I recall being in a situation where I had to put the commandline in a batch file and do wine cmd.exe /c foo.bat because there wasn't another other way to make the windows app happy... something about the commandline that made me need to use CreateProcess, and cmd.exe was the easiest way to use CreateProcess. - Dan
On 7 Jun 2012, at 19:30, Dan Kegel wrote:
John asked
[ How do I launch Windows apps from Unix apps and pass filenames to them?] execl (the_path_to_wine, "wine", path_to_the_windows_program, command_line_parameter_for_windows_app, NULL);
Relative unix paths will often work with Windows apps, but in general, you will have to translate command_line_parameter_for_windows_app, and any paths that appear in data files, from Unix to Windows before launching the app.
Thanks Dan,
Paths in data files I can understand but from what Hin-Tak said earlier, it sounds like Wine itself will translate any paths that I pass as a command line parameter (or did I misunderstand that?)
FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years. It was only yesterday that I began to wonder if there might be a problem in non-English locales. Up to now, nobody's ever reported a problem (though, as we all know in programming, that doesn't mean there isn't one!)
John
--- On Thu, 7/6/12, John Emmas johne53@tiscali.co.uk wrote:
<snipped>
FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years. It was only yesterday that I began to wonder if there might be a problem in non-English locales. Up to now, nobody's ever reported a problem (though, as we all know in programming, that doesn't mean there isn't one!)
That depends on whether your application uses the *W file operation WIN32 api or the much older *A routines. For example, I have a quick look at bcc32.exe (part of borland's compiler, time stamp july 2000, 12 years old) with 'winedump -j import bcc32.exe' . It loads only 3 *W routines but 25 of the *A ones. Whereas cl.exe from visual c++ express 9 (2008, 4 years old) loads 31 *W routines and only 2*A routines. So MS VC 9 is far happier in non-English locale than the much older borland 5.5 compiler.
On 8/06/2012 4:57 AM, John Emmas wrote:
FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years. It was only yesterday that I began to wonder if there might be a problem in non-English locales. Up to now, nobody's ever reported a problem (though, as we all know in programming, that doesn't mean there isn't one!)
Wine (and Windows NT OSes) use unicode for the command-line. Wine would convert the UTF-8 unix command-line to a UTF-16 Windows command-line.
It is then up to the Windows locale conversion to convert that UTF-16 string to the locale's character set.
John wrote:
from what Hin-Tak said earlier, it sounds like Wine itself will translate any paths that I pass as a command line parameter (or did I misunderstand that?)
Example: wine notepad /home/dank/foo.txt This fails because notepad treats / as the beginning of an option (see http://source.winehq.org/source/programs/notepad/main.c#L616 ).
So, no, Wine doesn't translate arguments for you.
FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years.
That's great. Do you actually pass filenames? - Dan
--- On Thu, 7/6/12, Dan Kegel dank@kegel.com wrote:
John wrote:
from what Hin-Tak said earlier, it sounds like Wine
itself will translate any paths that I pass as a command line parameter (or did I misunderstand that?)
Example: wine notepad /home/dank/foo.txt This fails because notepad treats / as the beginning of an option (see http://source.winehq.org/source/programs/notepad/main.c#L616 ).
So, no, Wine doesn't translate arguments for you.
It would probably work in any of these though:
z:/home/dank/foo.txt h:/foo.txt \home\dank\foo.txt h:\foo.txt
(the double backslash for its been interpreted by bash, or whatever shell you use)
or cd /home/dank && wine notepad foo.txt
FWIW the Windows app launches perfectly if I use
execl() in the Linux app - and in fact, this has all worked perfectly for years.
That's great. Do you actually pass filenames?
- Dan
That probably means it does not use "/" for options . ("-" or no options at all?).
On 7 Jun 2012, at 21:43, Hin-Tak Leung wrote:
--- On Thu, 7/6/12, Dan Kegel dank@kegel.com wrote:
Example: wine notepad /home/dank/foo.txt This fails because notepad treats / as the beginning of an option (see http://source.winehq.org/source/programs/notepad/main.c#L616 ).
So, no, Wine doesn't translate arguments for you.
It would probably work in any of these though:
z:/home/dank/foo.txt h:/foo.txt \home\dank\foo.txt h:\foo.txt
(the double backslash for its been interpreted by bash, or whatever shell you use)
Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example.... Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:-
47 C3 B6 72 61 6E -- (6 bytes)
whereas Windows would expect something like this (depending on the user's locale):-
47 F6 72 61 6E -- (5 bytes)
Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string "Göran" as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app).
Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks.
John
--- On Tue, 12/6/12, John Emmas johne53@tiscali.co.uk wrote:
<snipped>
Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example.... Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:-
47 C3 B6 72 61 6E -- (6 bytes)
whereas Windows would expect something like this (depending on the user's locale):-
47 F6 72 61 6E -- (5 bytes)
Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string "Göran" as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app).
Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks.
I have already answered that question - it depends on your application, how it uses win32 API. win32 api's is divided into the older *A routines which expects ascii, and the newer *W routines, which expects WCHAR (UTF16LE).
On 12/06/2012 8:59 PM, John Emmas wrote:
Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example.... Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:-
47 C3 B6 72 61 6E -- (6 bytes)
whereas Windows would expect something like this (depending on the user's locale):-
47 F6 72 61 6E -- (5 bytes)
Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string "Göran" as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app).
By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active.
Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks.
Wine first converts the command-line to Unicode according to the active host locale.
Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale.
If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale.
The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area.
If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?].
On 12/06/2012 8:59 PM, John Emmas wrote:
Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example.... Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:-
47 C3 B6 72 61 6E -- (6 bytes)
whereas Windows would expect something like this (depending on the user's locale):-
47 F6 72 61 6E -- (5 bytes)
Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string "Göran" as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app).
By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active.
Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks.
Wine first converts the command-line to Unicode according to the active host locale.
Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale.
If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale.
The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area.
If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?].
On 7 Jun 2012, at 21:04, Dan Kegel wrote:
John wrote:
FWIW the Windows app launches perfectly if I use execl() in the Linux app - and in fact, this has all worked perfectly for years.
That's great. Do you actually pass filenames?
Yes, our host app is cross-platform (Windows, Linux and OS-X). On all 3 platforms it passes a file path to the Windows/Wine client app. On Windows, this file will be in the user's "My Documents" folder (e.g. C:\Documents and Settings[user name]) so there's a very good chance that in non-English locales, the user name might have non-Latin characters. For that reason we specifically have to make a translation from UTF-8 ourselves.
However, it only occurred to me a few days ago that (even though we don't translate the file path on the non-Windows platforms) nobody has ever complained. This suggests either that the paths (on those platforms) never have names with non-Latin characters - or that Wine is silently making the conversion for us.
To be honest, I've no easy way of knowing which explanation is the true one. In fact, they could both be true!
John
-
Ben Peddell -
Ben Peddell -
Dan Kegel -
Hin-Tak Leung -
John Emmas