Using Visual C++ on GNU/Wine gives me all the benefits of being able to develop a 100% compatible MS-Windows version of the game, while saving me the time of maintaining another Win2k machine version of the source and moving to that machine to compile. It has been a great time saver for me and I strongly expect this information will be very useful to myself and others in the future.

With CrossOver Office Server Edition, those cost savings can be furthered by allowing Windows applications to be run on Tarantella ia Server Edition, rather than MS Terminal Server. Server Edition delivers the same core Windows productivity applications that users need, but at a fraction of the cost of MS solutions. In addition, users free themselves from the need for MS Windows OS licenses, as well as the need to license individual CALs for each thin-client station.

If you don't have Windows, but really like to play around with MS Paint, you can download it here: ms paint Just type wine mspaint95.exe to install it.

I have started reading up the wine source code and understand basics of the wineserver message passing and the TEB / tls system. I know little about windows programming though. Any hint on what I can work on, help, to get this working again?

generic pthreads simply doesn't offer the functionality we need. It's possible to use the glibc nptl pthreads, but that's only because of the way they are implemented on top of kernel threads; this isn't a general property of pthreads, so a 100% POSIX threaded Wine is not possible.

Once I get the nptl support working there will probably be a number of things that can be done to take better advantage of the new threading support, and any help with that is welcome. But in all cases such code can only be added as an option, it can't replace the existing code since we have to run on older kernels as well as on other systems.

It's a neat hack, but it doesn't preserve the core idea behind the server design, which is that processes are properly isolated. With the shm server you basically go back to the Win9x days where any buggy process can trash the system structures; and I don't think that this is where we want to go.

OK, so there's msvcmaker, but I don't use guis, so I threw together a way to build the wine tests using cl and nmake. I have the following files in ~/bin:

nmake:

wine -- wcmd /c F:\\bin\\nmake.bat "$@"

nmake.bat:

call f:/bin/vcvars32.bat
echo on
nmake %1 %2 %3 %4 %5 %6

vcvars32.bat:

same as normal one, but without quotes

nmakemaker:

(attached)

Then in any dll/tests directory, I can type

nmakemaker > foo.mak
nmake /f foo.mak

and build all my tests with msvc. Each test is built as a separate executable, but that's the way I like it for testing anyway.

Now I guess I'll submit patches to make everyone else's tests actually *compile* under msvc.

It was real funny to see that article on slashdot appear as I was doing this. I seem to have gone a bit further than that guy, since I don't have to use that awful, horrible wcmd window.

I was wanting to do some work on x11drv dll separation. The last remaining dll separation between x11drv and ntdll is VIRTUAL_SetFaultHandler. This is called from X11DRV_DIB_CreateDIBSection, where it tries to set the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and arg=res.

From reading the code it seems that this is done because it is not known whether the calling app requires read or write access to the data in bmp. If the app then tries to read or write and doesn't have the appropriate access, this will generate an exception which will then raise the X11DRV_DIB_FaultHandler which would then set the appropriate access, in a way that ensures data gets handled correctly.

I presume I'm misunderstanding this, because looking at MSDN for CreateDIBSection, it says:

The CreateDIBSection function creates a device-independent bitmap (DIB) that applications can write to directly.

Windows NT: You need to guarantee that the GDI subsystem has completed any drawing to a bitmap created by CreateDIBSection before you draw to the bitmap yourself. Access to the bitmap must be synchronized. Do this by calling the GdiFlush function.

So it would seem apps could always be given read-write access to this bitmap.

Why is the special fault handler needed? What is the best way to approach getting rid of it?

I wrote some documentation a while back on this when we (TransGaming) submitted our dibengine to rewind/winehq.

You can read the docu at:

http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html

Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, in that it has properties of both: The app can write directly to the pixel data while also being able to perform GDI operations on it, which we do through X. Because of the way X works we therefor have to have two copies of the DIBSection hanging around, and be able to sync them when required (eg, if the most 'up to date' version is in X, we need to know when the app tries to write to / read from the DIB so as we can sync them).

And really - the best way to get rid of it is to finish the DIB engine :)

Would that actually let you drop a file into MS Windows and suddenly allow any windows app to be export via X11 at the API level?

If so, then all I can say is "whoa". If not, then, well, that'd be a cool hack some day :)

Yup, that's the point ... will take quite a bit of work but until the x11drv and gdi32 dlls are separated out it's not even feasible ... if you're interested see http://sources.redhat.com/XOpenWin/ which is a currently quite dormant project to try do this. The relevant bugs for dll separation are:

http://bugs.winehq.com/show_bug.cgi?id=538

DLL Separation: x11drv from gdi32

http://bugs.winehq.com/show_bug.cgi?id=540

DLL Separation: x11drv from user32 (clipboard)

http://bugs.winehq.com/show_bug.cgi?id=542

DLL Separation: x11drv from user32 (misc)

http://bugs.winehq.com/show_bug.cgi?id=543

DLL Separation: x11drv from ntdll (FILE_DupUnixHandle)

http://bugs.winehq.com/show_bug.cgi?id=545

DLL Separation: x11drv from ntdll (VIRTUAL_SetFaultHandler)

The wine internal libraries are still about a megabyte of code, and it's silly to duplicate all of that whenever a single function changes. Symbol versioning is much better solution to that problem, and I don't see much reason for not using it (except on platforms that don't support it of course).

I have a question about Wine's font handling. I am experiencing behavior in Wine that I don't believe is normal. At the very least, it is not desirable.

Ever since the first time I installed Wine over a year ago and up until the present, I couldn't figure out why Wine would, seemingly at random, decide it had to rebuild the font metrics when starting a Windows app. And this takes a fair length of time on my older machine with quite a few MS fonts installed. Sometimes, I would go a week or more without it having to rebuild the font metrics; other times it would be almost after every reboot. I couldn't figure out a pattern. Until this morning.

It seems to be Java related.

So here's my question: Is this normal?

What is happening is that a default set of fonts are known to the font server, presumably xfs. When Wine is run, it checks that list of fonts and caches them.

When you run Java, it registers some additional private fonts with xfs. Now when you run Wine, it sees that the list of fonts has changed and reruns the caching.

You have a couple of alternatives. With that version of Redhat, you really don't need to have Wine use the xfs font server ("server side" font rendering). If you install a collection of TrueType fonts into your windows/Fonts directory, wherever you have your fake C: drive installed, then Wine should do direct rendering of fonts("client side" font rendering). When Wine does direct rendering, you will never cache fonts again. Yea! ;)

You can get fonts from the C:\windows\Fonts directory on a real Windows installation, and also from here:

http://corefonts.sourceforge.net/

Alternatively, if you want to continue to use "server side" font rendering, figure out where the Java fonts are located, and add that path to the default search path for xfs, so that xfs (and therefore Wine) already knows about them. Assuming it has not changed since RH7.3, the font paths are set in the file /etc/X11/fs/config.

Not hard at all, I've created a new script http://people.redhat.com/mstefani/wine/smatch/wine_locks.pl that takes care of locks of the form:

lock(this);
do_something();
unlock(this);

and put all of the above locking pairs into it. To add a new locking pair all that's needed is to add an entry for it in the %locks hash.

Running wine_locks.pl requires this patch http://people.redhat.com/mstefani/wine/smatch/smatch.pm.diff for smatch.pm because it treats every ARGV entry as filename (i'll contact the smatch author to find a solution that dosn't require this hack).

Besides some NOTABUG's in the CriticalSection locking i found only this:

wine/windows/win.c 104 127 create_window_handle(31) 1 USER_Lock not released

I'm not sure if it's a bug or not.

That reminds me, on the Wine 0.9 TODO it says "expect a preview of the wine config applets in the second week of 2003". Anybody know what the status of these are? I think it makes sense to start pro-actively targetting 0.9 tasks, and having control panel applets for Wine seems like a good idea.

Hmmm, do we even have a control panel? Presumably programs can install control applets (capplets in gnome-speak), but I don't see any way to see them other than executing the cpl files manually.

Last time I talked to Jaco, he was busy finding work. Hopefully he'll resurface soon, maybe he has a nice surprise for us :).

Thing is, that particular configuration applet is the key to our autoconf efforts. Once that's in place, we can do C1 right away, as well as C3. C5 seems to be just a matter of getting some work done, as the proposed solution appears to be working just fine. C6 seems to be simple, once all the other pieces are in, while C7 looks like it's in a usable state already.