January 2003 - Wine-Devel - list.winehq.org

Re: [RFC] io.h & friends

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > 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 think it would work. What you have to do is something like: #ifndef __UNIX__ #include <io.h> #else #include <unistd.h> #endif (you could also use #ifdef _MSC_VER instead, since unistd.h should work everywhere except on MSVC) This would require us to add a unistd.h to our msvcrt headers, but that's much less problematic than having two versions of io.h. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2003

Re: Registering DLL's

by Alexandre Julliard

"John K. Hohm" <jhohm(a)acm.org> writes: > The main reason I used a static list was to make it impossible to forget to > unregister one of the interfaces you registered; that is why the unregister > functions take the entire structures (but only need the first members). > > OTOH, if we might someday want to avoid unregistering one or more interfaces > or classes we registered, having separate functions would make that easier. > > I think I still prefer the structures, but are you convinced enough? Not really, but I don't feel strongly about it, so do it the way you like. > What would it take to make a static library work for this? Unlike a dll, > that would not have any overhead, would it? I'm a real sucker for elegance, > you know. :-) It's possible, but it adds quite a bit of complexity to the build process, and creates annoying dll dependencies. I'd prefer that we start with the duplication for now, and see how ugly it gets. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2003

Re: html browser for wine (khtml)

by Dimitrie O. Paun

On January 9, 2003 12:14 pm, Alexandre Julliard wrote: > I'd prefer to avoid C++, but if there's no other choice then of course > we'll have to do it. I'm still hoping that we can find a way to avoid > duplicating all that code inside Wine, C++ or not. Well, it seems the only worthy alternatives are Mozilla and KHTML, and they are both written in C++. I am 100% with you on the non-duplicating bit: even if we get something in the tree, it's not going to be maintained, and it will bitrot to fast for words. It would be a huge addition and burden to maintain for the Wine project. Galeon does not include Mozilla -- it uses it. There's got to be a way to use KHTML in a similar manner. Even my first hand approximation (using the Win32 build of Mozilla) seems like a better option than duplicating code. If we get that working, I'm sure we can work with the Mozilla team to find a way of embedding the Linux version. Heck, Galeon does it! But since I'm not doing that work ... -- Dimi.

Jan. 9, 2003

Re: [RFC] io.h & friends

by Dimitrie O. Paun

On January 9, 2003 12:12 pm, Alexandre Julliard wrote: > I think it would work. What you have to do is something like: > > #ifndef __UNIX__ > #include <io.h> > #else > #include <unistd.h> > #endif This so fast! :) Remember, __UNIX__ is always defined when compiling in Wine, so we can never include io.h. Which begs the question: why do we have it in msvcrt in the first place? :) I'd like to be able to compile an app with _and_ without the msvcrt runtime, by adding/removing the -mno-cygwin switch. The simplest thing to do would be to just: #include <io.h> #include <unistd.h> and when compiling with the -mno-cygwin, I get an empty/small unistd.h, and without the -mno-cygwin I get an empty/small io.h. A include/cygwin would solve this nicely, we can simply stick in there all the cygwin extensions (like io.h, and others), and in msvcrt we can put the mingw extensions (such as unistd.h). The two includes will be mutually exclusive, and you can choose between them with the -mno-cygwin switch, the same as you do on Windows. -- Dimi.

Jan. 9, 2003

Re: [RFC] io.h & friends

by Dan Kegel

Dimitrie O. Paun wrote: > #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> Applications that use autoconf surround each #include with a test for that header's presence, e.g. #if HAVE_IO_H #include <io.h> #endif #if HAVE_UNISTD_H #include <unistd.h> #endif That's best practice when writing applications. When creating a platform, on the other hand, it's probably best practice to have all those headers, even if they're empty, so everyone can #include them without worrying about the #if HAVE_BLAH_H's. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 9, 2003

Re: html browser for wine (khtml)

by Hetz Ben Hamo

On Wednesday 08 January 2003 22:27, Dimitrie O. Paun wrote: > On January 8, 2003 02:11 pm, Hetz Ben Hamo wrote: > > Whats the difference? now you don't need QT, so license wise - it's > > kosher ;) > > But I guess it's still C++, no? I'm not sure if Alexandre will accept > C++ dlls... Well, last time the talking here was that due to QT license, KHTML couldn't be used, and now with the Safari you don't need any QT (you can use other GUI kits around)... As for C++ - well, anyone is welcome to look at mozilla code - I'm affraid that it looks like a big spaghetti, compared to (pretty neat) KHTML code ;) Thanks, Hetz

Jan. 9, 2003

Re: html browser for wine (khtml)

by Dimitrie O. Paun

On January 9, 2003 10:44 am, Hetz Ben Hamo wrote: > As for C++ - well, anyone is welcome to look at mozilla code - I'm affraid > that it looks like a big spaghetti, compared to (pretty neat) KHTML code ;) I'm not saying it's an unreasonable request. All I'm saying is that it would be a change in policy to accept C++ code in Wine. So you need to take it up with Alexandre :) -- Dimi.

Jan. 9, 2003

Re: Registering DLL's

by John K. Hohm

Quoting Alexandre Julliard <julliard(a)winehq.com>: > That's much better than the previous one. I'm not convinced you really > need to build a static list, you might as well have a function to > register a single interface and call it a number of times. The main reason I used a static list was to make it impossible to forget to unregister one of the interfaces you registered; that is why the unregister functions take the entire structures (but only need the first members). OTOH, if we might someday want to avoid unregistering one or more interfaces or classes we registered, having separate functions would make that easier. I think I still prefer the structures, but are you convinced enough? > I'm afraid copying it is the best choice; I don't think we want a new > dll for just a couple of routines. It's not very elegant to duplicate > it, but it shouldn't be a lot of code anyway. What would it take to make a static library work for this? Unlike a dll, that would not have any overhead, would it? I'm a real sucker for elegance, you know. :-) I used to think any library, even a static one, had to have a certain amount of bloat, until I came across the dietlibc (http://www.fefe.de/dietlibc/)

Jan. 9, 2003

Re: widl patch

by Kari Hurtta

Comment about http://www.winehq.com/hypermail/wine-devel/2003/01/0390.html | I don't see why it can't be there if we do something like | | #ifdef HAVE_SNAZZY_COMPILER | #define RpcTryExcept __try | ... | #else | #define RpcTryExcept if (1) | ... | #endif | | People compiling Windows apps under Winelib would usually need to use a | compiler with a lot of extensions anyway, and people needing to compile | RPC/DCOM marshalling code should either use such a compiler, know what | they're doing, or (when it becomes possible) use widl to generate such | code. One hint: Sendmail 8.12 uses also exception mecanism. On it's implementation 'try' uses setjmp() ( Look macros include/sm/exc.h -- you can not of course copy these but that should tell enough that it is doable just plain C ) / Kari Hurtta

Jan. 9, 2003

Re: Help with /?? stuff

by 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/bas…) 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. " Alberto

Jan. 9, 2003