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