date:20030109

[RFC] io.h friends

2003-01-09 Thread Dimitrie O. Paun

Folks,

Just as I thought 'fine, I'll add the #ifdef, and get it over with', this
thing comes back to haunt me. For the record, I've delete the previous
thread, _and_ the io.h patch from my tree, thinking the issue was put to
rest.

As you can probably guess, I have the io.h problems in wxWindows, simply
because this is what I work on right now. Let me state the problem again:
  -- When you compile with winegcc, you get these macros:
__WINE__, __WIN32__, __UNIX__
  -- You want your source to compile with the native libc and/or msvcrt
  -- You want it portable between Wine/MinGW/Cygwin.

So, let's say I do:
#ifndef __UNIX__
#include io.h
#endif

Well, this will not work if I want to compile with msvcrt, because
__UNIX__ will be defined anyway. So what do I have to test for? 
I have to define a new symbol (USE_MSVCRT) and test for it

#if !defined(__UNIX__) || defined(USE_MSVCRT)
#include io.h
#endif

But this is not all! For example, wxWindows includes stuff like this:
#include sys/unistd.h
#include sys/stat.h
Since they are available in mingw, and cygwin, and in UNIX, but if
I want to use msvcrt they conflit with stuff from there!

It's a mess. As you can see, the defines alone can make a grown man
cry, and this is for a simple include. And I don't even know I've
covered all the basis! Problem is that there are already 5 platforms:
UNIX, Wine, Cygwin, MinGW, MS. And complexity grows exponentially
with the number of platforms and combinations you have to test for.

This way lays madness. It is now clear to me why the Cygwin people
included io.h. It's so that you can compile with or without the
-mno-cygwin switch, and have everything work. The only way for that
to happen without ungodly defines and tests, is to have a flat space
of include files: a union of MS  Unix files. Even if they are
empty! This way you can simply do:

#include unistd.h
#include io.h

and you make sure you get the access() definition regardless if you
use the msvcrt of the libc.

I'm not sure what to do. I was hoping to get a include/cygwin
and/or a include/mingw directory so we can deal with these problems.
I didn't know mingw had Unix headers as well, this complicates matters.

Any fresh ideas in this matter are highly appreciated.

-- 
Dimi.

Re: Help with /?? stuff

2003-01-09 Thread Alberto Massari

Hi Shachar,

At 23.59 08/01/2003 +0200, Shachar Shemesh wrote:

Hi,

I'll clarify my specific predicament.

It seems that when MoveFileEx is called with MOVEFILE_DELAY_UNTIL_REBOOT
flag, an entry is written into the registry with the file names to rename.
Windows being what it is, a MULTI_SZ entry is used in a way that is
totally and utterly incopatible with the MULTI_SZ definition, but we'll
leave that rant to another time.

You can read from the MSDN page
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/movefileex.asp)
what is the format used by MoveFileEx. That string is a NULL-separated list
of pairs of files, where the first one is the source and the second is the
target of the move operation (if the target is missing, the file should be
deleted). I guess Wine is converting the NULL into \?? to be able to store
it as a string.

BTW, do you need any help on this task?

Here is an excerpt of the doc:

If the dwFlags parameter specifies MOVEFILE_DELAY_UNTIL_REBOOT, MoveFileEx
stores the locations of the files to be renamed at restart in the following
registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\PendingFileRenameOperations

The function fails if it cannot access the registry.

The PendingFileRenameOperations value is of type REG_MULTI_SZ. Each rename
operation stores a pair of NULL-terminated strings. The system uses these
registry entries to complete the operations at restart in the same order
that they were issued. For example, the following code fragment creates
registry entries that delete szDstFile and rename szSrcFile to be szDstFile
at restart:

MoveFileEx(szDstFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT);
MoveFileEx(szSrcFile, szDstFile, MOVEFILE_DELAY_UNTIL_REBOOT);

The system stores the following entries in PendingFileRenameOperations:

szDstFile\0\0
szSrcFile\0szDstFile\0\0

Because the actual move and deletion operations specified with the
MOVEFILE_DELAY_UNTIL_REBOOT flag take place after the calling application
has ceased running, the return value cannot reflect success or failure in
moving or deleting the file. Rather, it reflects success or failure in
placing the appropriate entries into the registry.

The system deletes a directory tagged for deletion with the
MOVEFILE_DELAY_UNTIL_REBOOT flag only if it is empty. To ensure deletion of
directories, move or delete all files from the directory before attempting
to delete it. Files may be in the directory at boot time, but they must be
deleted or moved before the system can delete the directory.

The move and deletion operations are carried out at boot time in the same
order they are specified in the calling application. To delete a directory
that has files in it at boot time, first delete the files.

61 matches

Mail list logo