This is the 156th release of the Wine's kernel cousin publication. It's main goal is to subvert the dominant paradigm that PC applications must be run on a Microsoft operating system. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).
This isn't really related to Wine, but you might find it interesting. IBM's
developerWorks web site has an article on
cross-compiling Windows apps on Linux,
The Xmingwin/bin directory includes not just a cross-compiler,
but cross-linker, cross-library-manager, and almost two dozen
related tools for common developer operations. With a bit of
practice, you can generate deliverables for Windows just as easily
as you currently do for Linux, probably from the same Makefiles
you're already using.
Preface: we began covering this last week in issue #155
The questions about the new threading model that can be enabled in
the latest glibc came up again. This time Steven Edwards was
wondering about getting Wineserver to run under Cygwin, but
the discussion quickly delved into using pthreads for threading. Marcus
Meissner once again pointed out the problem with the new threading
is going to surface soon,
Redhat Phoebe is affected already (is that 8.1?). Shipping soon.
Mike Hearn mentioned some other early reports,
There were some rumblings on the crossover users list, so I think it's
safe to assume Phoebe is a no go
However, Phil Bordelon said his Gentoo distribution with glibc 2.3.1
wasn't affected. Michael Stefaniuc explained that it was a combination
of a new kernel and glibc that caused the trouble,
you need also an nptl enabled kernel to enable the new threading
model. This would be an actual 2.5 kernel or a 2.4 kernel from Red Hat's
Rawhide or Phoebe.
People began questioning exactly what needed to be changed how
long it would take. Dimi Paun pointed out,
I know Ingo Molnar has been (one of) the
main developer working on the glibc threading stuff, and I also know he
used to follow the Wine project. I am sure he's not indifferent to our
fate, and being so deeply involved with the glibc changes, he's probably
an invaluable resource. Unfortunately, I'm not sure he's even aware of
the problem -- has anyone contacted him? Anyone want to do so? (Dan? :))
Michael discovered this issue had been recognized months
To resolve any doubts that Ingo isn't taking care of wine read this:
Michael also seems to have contacted Ingo privately and gotten the following reply:
here is Ingo's answer:
could you try:
export LD_ASSUME_KERNEL=2.2.5prior starting up Wine, does this fix the problem for you?
Francois Gouget reported,
According to reports on the CrossOver mailing lists this works on
Phoebe 1 but does not work anymore on Phoebe 2.
Also it causes Wine to fail on some platforms like SuSE 8.1 so it should
not be blindly set.
Michael did some testing and found that particular kernel had a problem with signals and that it had already been replaced in the latest Rawhide repository. Testing with the even newer kernel worked as expected.
Chris Tooley offered
workaround involving a small library. Apparently Wine
isn't the only program affected,
there was a workaround on the vmware newsgroup (vmware is
afflicted with a similar disease) that preloads a small .so to make it
work. This might be useful for some people. I've used it with some
success on my installation of wine.
Marcus noted that solution wouldn't work in all cases though either. Then Marcus, Eric Pouech, and Ulrich Weigand started an exchange on the exact problems faced and how capabilities of the new threading model could be exploited. Eric started with:
among the things we have to take care of:
- signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten
- in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
from what I've seen, the LDT/GDT with nptl should be easier:
- for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation
- for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now
and it's likely there are quite a few other items I forgot
(I'll attempt to add some explanation, but I'm pretty stupid when it comes to memory management. LDT is the "local descriptor table" in Linux for user space. Every task has one LDT. GDT is the "global descriptor table" for kernel space. TEB is more of a Windows concept - "thread environment block".)
As far as thread control goes, Ulrich dug around and
in the Linux / glibc 2.3.x case, there's a new gettid
call that returns a 'thread ID' that used to be the pid, and a new tkill
system call that can be used to send a signal to one TID, just like the
old Linux kill would send a signal to a specific thread. I think using
those we could carry over our old Linux-specific hacks one to one, and
it still should work even if our threads are glibc 2.3.x pthreads.
Notably absent from the thread was Alexandre. He jumped in to
I've been in touch with Ingo, and I'm looking into the issue. However
I'm currently moving, so things are a bit hectic around here, and I
don't have good internet access. Hopefully things will settle down a
bit soon so that I can get some real work done...
Look for the thread to continue for a while.
Last week I covered a thread where Greg Turner talked about
figuring out to make remote procedure calls communicate over the
wire. I left out the last paragraph of Greg's post where
Combined with the pseudo-documentation of the format strings from MSDN, the
Microsoft headers and MIDL output, the DCERPC source, tcpdump, etc., there's
enough comprehensible clues out there to actually accomplish something -- it
still feels pretty sparse to me, but I guess there's nothing I can do about
that but forge ahead (or maybe shell out for the DCE package :) )
Following that, Dimi Paun replied with an offer:
The DCE package is like $400USD. Not that bad. Maybe we can put some money togther (what about the Party Fund, that would be a good use of that money), and buy the DCE docs for the Wine project.
I contribute $40USD, if other contribute to make the 400.
Pretty soon others joined in to reach the goal. The following people offering to donate some of their personal cash to get the docs:
A little impasse was reached on how exactly the money could be donated though - especially for folks not in the United States. Jeremy White posted a note about formalizing it:
I'm filing papers (on a personal basis ) in Minnesota to do business as 'The Wine Project', and I've opened a personal account with the name 'The Wine Project', and I'm a few days away from having a Paypal button all ready to go to accept donations.
You can thank Tom for this; he's the one that harangued me into it <grin>.
I think I've mostly held up in the past because we didn't have anything to spend money on. However, Tom has pointed out that we can use the money to fund travel for a Wineconf 2003, and this also sounds like a worthy cause.
That led into the next thread...
Jeremy White wrote in to announce a link he set up for donations:
There is now a Paypal donations link up at www.winehq.com; donations there go into a bank account I opened under the name "The Wine Project".
I promise to only embezzle small, unnoticeable amounts of the funds <grin>.
We should probably decide what we want to use this money for; I'm happy to send of for the DCE package as soon as the $400 accumulates (or to reimburse someone else).
Beyond that, I think Tom is right - we should fund a periodic conference. But I'll start a new thread for that.
What? A conference? Read on...
Last year's Wineconf 2002 gathered 30 of Wine's most active developers together. By most accounts, it was quite successful. Jeremy decided to ask what everyone would think of having another:
I think we should have another Wineconf.
The last one was a blast, and I think helped lead to a really great 2002 for Wine.
However, I'm not wealthy enough to fly everyone around the world. Maybe next year <grin>. But just because Lindows isn't going to pay for it doesn't mean we can't get together.
Assuming we have another Wineconf, the main questions are where and when?
For where, I would think it's time to hold it in Europe.
On the other hand, if we hold it in St. Paul, I would be happy to arrange (and pay for) a conference site. It would also let a lot more of us CodeWeavers make it.
Also, it would seem to make sense to hold it in conjunction with a Linux conference; that would probably make it easier for others to do the travel.
People began tossing around ideas for European conferences.
How about we hold it as a satellite conference to LinuxTag, Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big, very cool event. See http://www.linuxtag.org/2003/en/conferences/cfp.html
I suppose the Linux Summit in Finland in Febrary is another possibility: http://www.sot.com/en/sot/summit2003.shtml but it's a much smaller (and colder!) show, and there isn't really enough time before then to prepare.
Another event is Linux Kongress. In the last years, some funding by the german government was available for special interest groups. We already had a get together with that money 1999 in Erlangen.
There is also the Linux Developers Conference (run by UK Unix Users Group) in Edinburgh at the beginning of August. Might be an opportunity for someone to get to see the festival cheap.
Steven Edwards posted a message letting the Wine developers know ReactOS had its first release. ReactOS is intended to function as a drop in replacement for those operating systems from Redmond.
Just wanted to let everyone know that we've hit our first major milestone with ReactOS. I dont have the changelog in front of me but to some it up here it the list that I know off the top of my head.
- Self-hosted builds now works
- Simple Windowing (User32 Code adapted from WINE)
- More MS_VC applicaton/driver support
- Started implementing support for WINE dlls
- Better Networking support (TCP still broken)
Once WINE hits 1.x we will again take a snapshot of your tree so we have standard debugging interfaces. Right now in or tree we dont use libwine but have our own dll that implements the debug channels. We also still need to adapt alot of the controls from WINE for our user32.
Thanks for all the help
Regarding adapting the controls, he explained in more detail,
ATM I think wines comctl32 and shlwapi work under WindowsNT so once ReactOS gets a little more
fine tuned we should have no problems using them. There are still some issues with the commdlg32
and shell32 + everything else but we are working on it. Right now the big thing is to compleate
our user32/Win32K and then we can make better use of the WINE code. I am trying to get the rest of
the ReactOS people to also use the WINE regression test framework for our test suite so we can
share that also. Rest assured any fixes or new features will find thier way back in to the main
I guess this is the week of continuing threads. Dave Miller got to work on creating a "database" (or at least at this point a list) of how various Windows DLLs relate to each other. For the most part the data has been collected, now it's just a matter of putting it into a human-readable format:
I've begun cross referencing the windows dlls in a 'map' format as Dan Kegel suggested. I'm not finished yet because it seems when I sort alphabetically I am sorting the entire path. Sample output is here:
Be aware though this HTML is around 900K. If anyone has comments or suggestions on how to improve it or the next logical step please let me know.
There's definitely a lot of useful data in there. But for now it just has what DLL's are being imported by another DLL. Several people had ideas for how to represent it. Dimi Paun suggested:
Sure, here are my suggestions (in order of importance):
- Transform the output to a matrix (a square matrix, a DLL per row & column, the entry at row r and column c gets an X if the DLL on row r imports the DLL in column c.
- Get rid of the path from the DLL filenames, it's useless, and it eats up space. That is, just say userenv.dll instead of c:\windows\system32/userenv.dll.
- Get rid of the .dll extension for similar reasons.
- Remove the columns from the matrix that have no X's.
- Order columns by order of importance. That is, the ones with more X's come first.
Shachar Shemesh had some ideas for how to go about ranking
the number of imports done by a DLL in order to make the resulting
matrix more organized. Dan Kegel wanted,
two numbers next to each
line: the number of libs imported directly and indirectly by the named file.
That would give some idea of "distance from the core".
Hetz Ben Hamo asked:
I'm testing some apps installation with either the free WineHQ, WineX, Crossover Office, and many times I see buttons and other GUI related stuff in the wrong size or place, and I understand it's a GDI related issue, so here's 3 questions..
- Is the GDI implementation is so bad that it needs hacking per app to make it look ok?
- Is there a way to take GDI parts from native WIndows and use it in Wine?
- Funding - can any company (transgaming, CodeWeavers, others) can estimate the cost of rewriting a better (and faster - the speed of Wine graphics today is something in magnitude of 486 PC!) GDI?
Dimi Paun thought the problem might be in the X driver or the controls. Mike Hearn felt most of the apps he ran had perfectly acceptable performance and wanted to know if this was a real world problem. Then he went on to test it himself:
Well, I just tried a simple comparison of the Adobe SVG plugin under Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when doing repeated bitblts such as the plugin does on an animation I have, but it's certainly not something that'd actually affect real world usage. I don't think GDI performance is really an issue at present, most apps don't do these kind of repeated double-buffer switches (i assume flash doesn't actually use the gdi to render into its backbuffer?) so it only affects apps like photoshop and director/flash.
In particular when I run the SVG plugin, I can see a FIXME talking about a potential optimization, so really the issue is just a case of elbow grease for optimizations (esp in bitblt) rather than a rewrite I'd guess.
Not much more was discussed. I guess it ranks as a known area of
optimization, but not exactly a high priority. Johan Gill did
mention he had plans of looking at it,
I'm looking at fixing up the DIBSection handling. Will probably submit
something this year at least :)