Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
>
> > all winelib programs exhibit this
> > I sent a few weeks ago a patch that solved it (in fact partly,the 'current'
> > dir had to be mapped onto a DOS drive, as defined in ~/.winerc)
> > but, Alexandre didn't commit it yet (didn't like it ?)
>
> The right fix IMO is to make chdir() follow SetCurrentDirectory(), so
> that the Unix and Windows curdirs are always in sync. This will
> require some hacking in the 16-bit task switching (since the 16-bit
> curdir is per-task, not per-process). Maybe in the meantime we should
> remove the chdir("/"), it seems to cause more problems than it fixes;
> and maybe this will encourage Marcus to implement the right solution ;-)
>
One problem with this is that DOS/Windows keeps the current directory on a per
drive basis (at least from a user interface point of view, don't know how it is
implemented internally). Of course since you also know the current (aka
default) drive as well as the current directory you can change the current
UNIX dir when the drive is changed. However I could see this causing problems
if a process's current directory is a CD-ROM drive it will prevent the
CD-ROM from being unmounted. That is both good and bad. Under DOS it is
perfectly valid to eject the CD-ROM even if you are on that drive. Under
Windows it will generally give you a message about the drive being in use and
ask if you want to eject it anyway.
I am not exactly sure how to deal with this extremely screwed up behavior. Of
course that is the story of Wine so what else is new.
-Dave
