On Sat, 17 Jan 2004 20:29:00 +0000, Jason Edmeades wrote:
I'd be worried this may cause more problems than it solves.
Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are tested by running it from explorer or the shell, which seems to use full paths though. So the fact that we usually run without a full path seems to be problematic. I guess there's a slight chance it could break apps designed to be run from the command line in Windows which might make similarly bad assumptions. Perhaps a config option, override-able in appdefaults, which controls passing the full path to the app - on by default.
This leaves the question of where it gets the command line from, of course. If not argv[0], not WinMain, then where? I find it hard to believe the game does a TEB->PEB to get this, given that those structures are undocumented.
This is an interesting one in that wine *does* correctly emulate windows behaviour, but the app is broken to only expect a full path. Aside from an app specific option (perhaps we could add in app specific config options into a central compatibility ini file), I think the only way to capture this is to document in eg. the appDB.
I'm sure this would cause mighty flamewars but a compatability db we ship with Wine for obscure/broken/impossible-to-generalise apps might be an idea. Even Microsoft does this with their shims database. I'm not sure how else we're supposed to solve problems like IE setup trying to use a (broken/old) native advapi32, or issues like this where the app is broken but because of the fundamentally different nature of Windows it's never seen.
The appdb isn't really suitable for this IMHO as it mixes up lots of different things - user talking, app rating: advice for running it could easily get buried and there is no way to remove old stuff. If there was a compatability db (perhaps a set of registry entries) it could be held in CVS and updated using patches. Feels messy, but if Windows does it we may have to anyway one day.
thanks -mike