Problem with ghc on Windows ME

[Joachim Durchholz]

Simon Marlow wrote:

> After Googling around a bit, I found this description of exactly how
> Windows interprets command lines in the C runtime:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp

Note that this is how the startup code of programs compiled with a 
Microsoft C/C++ compiler interprets the command line.
On Windows, it's the responsibility of the programs to parse the command 
line; there is no real standard way of interpreting it (and I can 
imagine that programs compiled by compilers from other companies, or 
even other Microsoft compilers, will interpret things differently).

Here are some pages that give informations on Windows-related 
limitations and deviations from Unix conventions:

http://support.microsoft.com/default.aspx?scid=kb;en-us;830473
Command lines and environment variables effectively limited to 8191 
characters on Win XP, 2047 on NT/2000 (probably even less on Win 9x):

http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/WINDOWSXP/home/using/productdoc/en/percent.asp
Command-line substitution under Windows XP. IIRC these facilities (or at 
least a large subset of them) are available on Win NT and 2000. Some 
might be available on Win 9x.

http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/WINDOWSXP/home/using/productdoc/en/Cmd.asp
How CMD.EXE processes command lines.


My personal summary is that it's generally unwise to try to utilize any 
Microsoft command shell.
Their behaviours depend on too many external influences, most 
prominently the exact Windows version, but (to a lesser extent) registry 
settings; command-line processing is riddled with kludges that work for 
99% of practical cases but will fail in a spectacular and miraculous 
manner for the remaining 1%.
Call programs directly. Using that, you know exactly what's going on, 
and don't have to worry about the MS kludges of tomorrow. Port bash to 
the MinGW environment if you really, really want or need a full-featured 
shell (I wouldn't recommend that either, the Unix shells are too 
feature-laden to easily determine how to make a specific call faultproof 
- besides, they are incompatible with each other, too).

Oh, there is *one* scenario where I could imagine that calling the shell 
is a good idea: when the user provides a command line (maybe as user 
input, maybe as configuration option), and the Haskell program is 
supposed to run that command line unchanged (or after some substitutions 
in it).
For this case, the libraries *should not substitute anything*.
Trying to mimic Unix behaviour is probably a generally bad idea (*what* 
Unix behaviour? bash? csh? ksh? zsh? ...)

Regards,
Jo
--
Currently looking for a new job.