WHAT'S NEW with Wine-20021125: (see ChangeLog for details)

• Finished conversion to STRICT compilation mode.
• WinHelp revival.
• Client-side fonts supported even without RENDER extension.
• Regression tests no longer require Perl.
• Lots of bug fixes.

Just in case anyone here cares, I have implemented the linux ftruncate64, truncate64, and mmap2 syscalls in the linuxulator on my computer, (mostly cut 'n pasted the mmap2 from regular mmap with a couple of changes) and with these changes it is possible to run the linux version of winex (the one you have to pay for) to run warcraft 3. IT works in both direct3d mode and in opengl mode using the following commandline:

winex --dll dsound=n --dll quartz=n --dll d3d8=b War3.exe -- War3.exe

Anyway, just thought someone might want to know. If anyone wants step-by-step instructions to getting this working I'll have those worked up in the next few days and posted somewhere along with the patches to the linux kernel module.

Version 0.1 of the Winelib Applications page is available here:

http://www.dssd.ca/wine/Winelib-Apps-0.1.html

The current version is always available at this address

http://www.dssd.ca/wine/Winelib-Apps.html

Your comments, and suggestions are highly appreciated.

Winelib can be a solution for porting such software to Linux by only rewriting those parts that need to be rewritten, replacing NT with Unix functionality. This is much easier than doing a native port; most of the application's code can be left untouched.

IMO this is the "real world" reason for doing Winelib development - you can *combine* Windows and Unix code. OTOH Putty and Mozilla are apps that I'd expect to be able to run natively.

FYI: the way it works is that instead of compiling the app as an executable, we generate a .so that's loaded by wine. Now, wine is simply a one page program that loads the libraries that the program expects (like kernel, gdi, user), and then loads the program itself. This is required by some apps which have C++ static initializers, which expect to be able to call Win32 functions, and they do so before we get a chance to initialize them, if we were to have the app load the libs.

In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix.

And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order.

I do not want to turn on relaying for only one DLL (as I have no clue at all where the problem is)... What I want is to turn on relaying for all DLLs *after* the program has started (and *from* one of Wine's DLL and not from the loader or any other 'special' code).

Ie, the program starts, loads the level / stuff for 10 minutes (and whould have produced a 2.5 GB log unreadable without big file support) and then only the last 10 seconds are important. So I would like to only relay these.

The easy way would be to print some magic string at that point, and pipe the output into a sed that deletes everything before that string. It will still be a bit slow though.

The harder way is to call wine_dbg_parse_options("+relay"). This would work for a normal debugging option, but for relay there is some work that needs to be done at startup so you need to handle that too. A way would be to start with +relay, turn it off with wine_dbg_parse_options, and then turn it on again when needed.

The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html

has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/

That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.

X11DRV_OpenGL_Init(display);
/* If OpenGL is available, change the default visual, etc as necessary */
if (desktop_dbl_buf && (desktop_vi = X11DRV_setup_opengl_visual( display )))


Well, before my patch, in one of the X11DRV rewrite, the option got somehow lost and was enabled by default whatever the value of the entry in the config file. So that it was working before was a 'feature' :-)

Now let's try to explain the reason of this option : in Windows, you first create the Window and then only tell it that one wants to do OpenGL drawing in it (single or double buffered). Now, in X11, if you plan to use a window to do OpenGL drawings, you first need to be sure that the visual you choose for it is compatible with OpenGL (ie does it support double buffering ? has it a stencil buffer ? ...). The problem is that when Wine detects that the application wants to do double buffered OpenGL drawings in that window, it's too late as the window was already created with the default visual => hence the option to have the default visual used by all windows be double buffered.

I do not think putting it as default is such a good idea as it may lead to performance problems to all the people not using OpenGL... And the gamerz just have to read the config file (if they know how to read, sometimes we wonder when doing 'support' on #WineHQ 8-) ).

As to why it's called 'DesktopDoubleBuffered' and not something else, it's also historic : at the beginnings, OpenGL only worked properly in Desktop mode :-)

Finally, Alexandre (if you read this :-) ), now that you rewrote most of the internal Windows handling code (ie with the Wine window == X11 window stuff), would it be possible to somehow recreate the X11 window when we detect OpenGL attaching to it and replace the old window in Wine's window hierarchy ?

This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully.

The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list.

My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-)

I'm doing a proof-of-concept for my boss to demonstrate that we can port a large-ish application developed on Windows (using mostly crossplatform libraries like wxWindows, STLport, Xerces) to Linux using winelib to cover a few WIN32 API calls we've made.

I've just started into it, and have compiled a dozen files so far, but ran into trouble with the thread code. I cannot find SwitchToThread anywhere, not even in the winbase.h header file I expected it in. There are some changelogs to indicate that it exists, and the symbol does live in libntdll.dll.so, but I cannot find a header file that defines it.