http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html was just mentioned at http://developers.slashdot.org/developers/03/02/23/1939225.shtml?tid=156
Yup, I've been doing this, and the author is right: the commandline tools show off a few rough edges of Wine. As more people start using them, maybe we'll get them smoothed off (e.g. my fix to wcmd the other day to keep it from stripping off switches too zealously)...
if I look at the issues:
- filename conversion (including #include to lowercase) => wine maker handles this
- passing file names on command line (DOS vs UNIX paths) => wine requires DOS paths to work in all cases
- inheriting in wine environment vars from DOS => either convert them as Unix vars, or use the yet to be committed autoexec.wine in wcmd
- compilation time: maybe linked to process startup (I don't see a need of lots of synchronization issues in cl.exe, but who knows)
- complaints on wcmd (which in fact apply to wineconsole) are mostly fixed (patches are committed, need to be applied) (=> size modification, clipboard corruptions)
- the console creation at wcmd startup should we removed when run under wineconsole (but, this would be rather annoying for some users). I have a patch for this, but it would mean that there are two ways of running wcmd: 'wineconsole wcmd /switch_for_no_new_console' or 'wcmd' (for using a brand new console)
- TRACE messages while running cl => does someone have a copy of those ?
- msvcrt lookup (native/builtin) => fixed in CVS
so, I don't think the situation is so bad: - a bunch of real bugs, which have been mostly fixed - a need for a bit more of documentation for this type of needs
A+ -- Eric Pouech
