On Fri, 06 Feb 2009, Mindaugas Kavaliauskas wrote: Hi,
[...] > Conclusion: no SetCurrentDirectoryW() is called at all. > GetCurrentDirectoryW() returned 6 bytes sting (i.e., "D:\PRG"). So command > result (C:\Documents and Settings\Administrator) is printed from cmd.exe > "cache". Thank you very much for tests. So the final conclusion is that In WinXP process has only one attribute "current directory" which is global for process and not divided for devices like in pure DOS though some tools (maybe also CRTLs) may try to emulate old DOS behavior. Probably the last question is when this modifications was introduced: with Xin9x, NT, 2K or XP. This is probably also an answer for some user "bug" reports about wrongly set/restored current directory when drive is changed. It also create additional question for us. Should we try to emulate DOS disk drives behavior in HBRTL or not. It may help in porting Clipper applications to different OS-es (such emulation may work also in *nixes - we can define drives to directory mapping, f.e. SET DRIVE A TO /media/floppy) but I do not know if it's worth to invest time in it. For sure we should intorduce one function which will change/restore current drive and directory in one call. Current Harbour code which operates on drive letters in windows builds seems to be buggy. We are using CRTL functions to change current drive and API calls to change current directory so we have desynchronization between CRTL current directory buffers and real process current path. If we want to keep DOS like emulation of current directory in Windows builds then we have to create our own current drive emulation. Otherwise we should remove all existing directory hacks and mixing CRTL with WINAPI calls because it may be source of unpredictable results and document it as native OS behavior. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
