This is the 148th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
I'm on vacation this week, so my apologies if I've missed any interesting threads. As always, check out the wine-devel mailing list to find out what's really going on.
TransGaming released "The Sims - unplugged on Linux" in their webstore. I've read the product description and I still have no idea if that means you can buy The Sims without buying the full blown "Mandrake Linux 8.1 Gaming Edition". However, you do get a cool t-shirt.
Also in TG is the December status and voting report. One item, a shared memory wineserver prototype, is covered below. Also interesting is their areas of focus in the coming months:
- Stabilizing the main development branch of CVS to prepare for the next release
- Completing support for new Direct3D 8 features such as vertex and pixel shaders
- Additional 3D performance analysis and tuning
- Stabilization of the ALSA back-end sound driver found in the main branch
- Better support for copy protection with the most recent versions of SafeDisc used by some games
- Complete InstallShield related OLE/DCOM restructuring with the help of the community to improve visual feedback during the install process
- Integration of available Windows Installer code from the WineHQ tree
- A simple, easy-to-use front end to help novice users configure and use games on WineX.
CodeWeavers released version 1.3.1 of their CrossOver Office Server Edition. I could have swore there was already a release of the server edition, but it appears that only a beta version was released back in August. Here's some quotes from the press release:
Jackson State University's Michael Robinson, a recent adopter of Server Edition, agrees. "Server Edition was exactly what we needed to maximize our investment in SunRay thin client stations. With CrossOver technology, we get the power and ease of thin-client computing, the convenience of letting our students and faculty run their favorite Windows applications, and a very affordable solution. At a time when IT budgets are really being squeezed, this was a perfect way for us to get more for less."
CrossOver Office Server Edition 1.3.1 supports the same applications as CrossOver Office 1.3.1, including core office-automation packages such as Microsoft Office, Outlook, and Internet Explorer. It also supports Lotus Notes, and Visio 2000, Microsoft's business and technical diagramming application. Support for additional client environments, like Windows, HP-UX, Apple, and SGI, is planned for future releases.
The news was also broadcast on Slashdot. Since I'm on vacation I refuse to read discussions about licensing.
Peter Hunnisett of TransGaming announced:
in the quest for speed parity in multimedia applications TransGaming has investigated a few options in dealing with the nasty overhead of the present wineserver implementation. I have just recently posted a prototype patch for a shared memory wineserver, to the ReWind project, ( http://sourceforge.net/mailarchive/forum.php?thread_id=1413925&forum_id=8836) which, in a small benchmarking suite, has shown some remarkable performance gains. The concept for the shm wineserver came about during discussions at the OLS in 2002 and remained a concept until a little while ago we had enough time to create a working prototype.
TransGaming is donating this code to the ReWind project in the hopes that it will encourage other Wine developers to continue to share code under the more open BSD/X11 style license and to help overcome the remaining issues with this approach.
Rather than make a really long technical email, we decided that a bit of a paper would be more appropriate (it also has links to the patches). The paper can be found at http://www.transgaming.com/papers/shmserver.html
This is some interesting work that shows dramatic speedups in some applications. The paper introduces the topic by describing exactly what the whole shared memory thing means:
The ShmServer solution attempts to simulate, entirely in user space, the reason the kernel is more efficient - namely, that it is possible for the kernel to view information about other processes without a context switch - and at the same time offers the benefits of being a user space approach, thus avoiding the kernel module issues listed above.
Using shared memory for storing the WineServer's data structures, and restricting write (and possibly read for simplicity) access through a global exclusion primitive, such as the very fast futex implementation in the 2.5 series Linux kernel, it should be possible to produce a solution which provides much better performance than the present situation. This solution is hybrid in that the WineServer process still exists but is only occasionally used. Concerns about the safety of buggy application code improperly overwriting the shared memory area can be addressed by protecting the memory against write access except for the 1 owning process since it's not possible to do this for a unique thread (actually SysV memory management only seems to have user/group/world type permissions that are set for everyone - BSD style mmap on the other hand can).
Two threads appeared this week essentially about the same thing. First, Armish noticed there was a Turkish keyboard layout but he couldn't figure out how to make some special characters such as ı,ş, and ğ appear. The way these work is there's another key on the keyboard (the dead key) that needs to be pressed before the letter to be accented. Jeff Smith had the same problem with the Spanish keyboard. At this point Zsolt Rizsanyi mentioned he had a workaround but it wasn't the proper fix:
I dont think that the problem is with the keyboard layout. I had poblems entering hungarian keys odoubleacute and udoubleacute. I fixed that problem with a hack to convert non Latin-1 keysyms to Unicode. I have sent that patch for inclusion, but I was said that there is a more correct patch in CX Office (the codeweavers' wine version) that will be merged soon.
BTW what's the state of that merge?
The next day Richard Allen reported problems working with an Icelandic keyboard. Zsolt replied again and referenced the earlier thread, but this time included a patch for keyboard.c.
Dimi Paun had a seemingly simple question,
Anyone remembers why we need our own cpp implementation,
instead of simply using cpp/gcc -E?
This is invoked as the first pass of compilation to
preprocess things like #defines and #includes. Using gcc -E
is just a way to stop compilation after invoking the preprocessor.
Patrik Stridvall replied first and said the reason was simply
for speed - he said having a special preprocessor was much faster.
Dimi didn't buy it though,
What?!? You got to be kiddin', right? If you can measure
any difference in build time between the forking gcc -E
and using wpp I'll give you a dollar in small change.
Later he did some tests to see just how much time was consumed by the preprocessor during compilation:
So how do you account for the fact that compiling a .c file is fast? It certanily does a hell of a lot more than preprocessing. Look:
[dimi@dimi server]$ time gcc -c -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c
real 0m5.276s[dimi@dimi server]$ time gcc -E -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c
In other words, preprocessing is like 10% of compilation, so it can't be unbearably slow.
Eric Pouech gave a more historical reason for having wpp:
IIRC it was a standalone program that Bertho maintained (and used in lots of other contexts than wine) (but I don't remember which ones)
anyway, the tool has been incorporated into wine as it was some options must remain from those days
Alexandre thought that at the time wpp was written there
were some special needs that had to be addressed,
I believe it was mostly issues with getting rid of C code in header
files, though that is handled in the main parser now. Still, it's not
guaranteed that the C preprocessor would handle non C code correctly.
Ove Kåven confirmed that Bertho Stultiens had implemented the preprocessor and gave a link to WWN #36 that described exactly why it was done:
Seems you argued against wrc having its own cpp implementation already back then. So the real reason why we now have wpp is probably because it was Bertho who implemented wrc and nobody else, and he wanted wrc to have an integrated preprocessor. No really compelling reasons were cited, but volunteers willing to do something themselves need no better reason. And I wouldn't mind keeping it, it's fast, easy to use, and guaranteed to work with Microsoft source code. wpp got factored out of wrc when I decided to use Bertho's preprocessor for widl too.
The folks working on Mono (the open source C# implementation) are interested in using Wine to implement the graphical systems.windows.forms methods. However, as part of that project it's necessary to have built-in garbage collection. Miguel de Icaza couldn't get it to work:
With the help of Hans Boehm, I have been tracking the problems we have to run the Windows.Forms code with GC enabled. Turns out that the problem is not the Boehm code at all, it just exposes a problem that might be happening elsewhere.
The problem is that by the time that Wine has been initialized, using setjmp/longjmp will always lead to a crash. The code in pthreads that performs the longjmp will first try to invoke the pthread cleanup routines, and then invoke longjmp. This never happens.
He posted a little snippet of code that he had problems with. Immediately a bunch of a people recognized the problem and informed Miguel he shouldn't link Wine with the pthread library since Wine has its own implementation. Patrik Stridvall explained:
I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug.
Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented.
So please try again without linking with -lpthread.
Miguel didn't seem to be comfortable with that:
The problem is that this is very hard for us to do as two of the underlying libraries we are using (libmono and libgc) both link against pthread to achieve their threading capabilities.
It might be better to investigate what are Wine's requirements for having its own pthread implementation, and have those changed pushed to the maintainers of pthreads.
In particular, we are interested in using WineLib, maybe it would be possible to have WineLib use the standard pthread implementation instead of rolling its own?
Stay tuned to see where this goes.
Last week when Dimi asked what the problem was with moving
configuration into the registry and Alexandre replied with,
Not much, it basically means making the Wine/Config branch into a
normal registry branch. It's more a user interface issue, we need
tools to edit it because you don't want to make users dig through
This week there was more discussion of configuring Wine that
occurred in several separate threads. Steven Edwards mentioned
that the ReactOS guys had a registry editor that could be adopted
The ReactOS project has a fully working console registry editor called regexplorer but it is GPL
and done in C++. If anyone is interested in it or needs it under another license let me know.
Dimi thought configuring Wine meant more than a registry editor:
However, I don't think this is what Alexandre had in mind.
Jaco was working on a cool tool, I don't know what the status of that is:
Jaco Greeff replied with a quick status update,
Second week in Jan 2003 for a
preview and some serious feedback. I've only got about 4 days left before
taking a bit of a break hence the longinsh delay. I've wanted to be quite a
bit further along and have something out there by now, but this is problably
better - it allows me to give serious attention to the feedback in Jan.
A few days later Dan Kegel forwarded a post from the Samba-technical list:
A registry editor, editreg, is slowly taking shape in Samba-head.
The goal is to be able to do things like:
- delete keys and values
- add keys and values
- change keys and values
- Change the SIDS/SecDescs applied to keys.
- write out the changes tree
- create a tree from scratch
What would be useful is some thoughts on how the interface should be constructed, as in command-line, or a .reg file of commands, etc.
Scott Cote asked,
I've found that many of the test applications I've tried installing failed
due to the lack of MSIEXEC. If it is implemented, could you tell me where
to find it? If not, I'd like to contribute, could you tell me if any work
has been done and who to coordinate with?
Zsolt Rizsanyi pretty much summed up the current status,
It is not implemented. That's sure. (Tough installing MS Office 2k installs it
for you) I have not heard anybody speaking about implementing it on this list
Duane Clark suggested a way to work around it by downloading the freely available executable from Microsoft:
Just go to http://search.microsoft.com/default.asp
Type "msi" into the search box, and a couple different versions are available. Seems to work fine.
Greg Turner outlined his thoughts in a lengthy but amusing post:
IMO, eventually wine should probably implement msiexec, but it might be pretty challenging, and, considering it's "just a free download" I guess it's a pretty low priority compared to things like uh, cabinet.dll (I heard somebody was supposed to be working on this but was screwing around with kde3.1rc5 instead :(. "Potato Guy" is a real breakthrough of modern OOP programming techniques, you should all check it out! Just think: only 18 hours of compiling, and you, too, can have a small worm crawl across on top of your foreground window. I think this means Linux has finally caught up with Microsoft!).
Er... but I digress...
Those MSI's are really nasty. IIRC, theyre like one big relational-database-style table in there, and, since they are cramming all the features of this particular "app" (the "Windows Installer Service," I guess) into a single table, you can guess how elegant and beautifully orthogonal the results are. I haven't really messed with them but I get the impression it might be kinda hairy/undocumented territory.
Anyways, what was the point of my post? Oh yeah: despite all of the above reasons not to implement MSIEXEC for wine, I think, in an ideal world, you wouldn't need to go to Microsoft and download things just to run installers in wine. The more wine users depend on MS to make their wine work, the easier it is for MS to pull the plug, screw it up, etc. (which is not to say that MS has been taking such measures against wine... yet... but if past performance is any indicator of future returns, as soon as wine becomes a threat to the OS monopoly in their view of the world, this could instantly change).
Oh, and while I'm on a rant... if we wanted to be smart-asses and play dangerous lawyer games, we could redistribute msiexec with a native compile of winemine or some other small frob.
Ultimately, my guess is Microsoft simply wouldn't want wine-associated folks redistributing msiexec, whether their rules allow for this or not... so IMO nobody should do so unless they are willing to duke it out with an army of lawyers, go to the media, start a legal defense fund, endure nuisance lawsuits, etc., over the issue -- however remote that possibility may be, being prepared for the worst-case scenario is the only way to be ready for life's nasty surprises when they do come... And there is also that aphorism about picking one's battles...
Shachar Shemesh provided some more details on exactly what's involved with creating a native Wine version:
Well I think Windows 2000 shiped with MSI 1.0, which was, to put it mildly, inadequate.
Which is not to say we are going to have a nice time of it. Not at all. I have played around with MSI a bit back in the times (about two years ago), and it is going to be a bitch. It is a semi-relational database, and it has SQL language to make it tick. It has a bunch of mandatory tables, and a few less-mandatory. It carries it's own CAB files inside a streams table. The format for the binary file will need to be understood.
Also, I know of at least one table that is there if queried by name, but does not appear if table listing is being requested. That particular table appeared in the MSDN docs. What about the others? If we are going to be rev-enging the MSI file format, that is not going to be much of a problem (Probably!), and I don't really think that the MSI itself is going to have too many undocumented APIs (let's not forget that most installations are produced using InstallShield and Wise, not by MS).
Also, MSI installed apps have a special kind of shortcut that tracks uses and allows for delayed installations (i.e. - install just the icon now, we'll install the actual file when needed). I'm pretty sure there is a heavy dependancy of MSI on file and directory tracking (it's ability to recover slightly missing installs).
So, it's not going to be easy, and there is a lot of infrastructure still missing.
Other folks pointed out that since Microsoft has started shipping the MS Installer with the latest versions of it's operating systems that more programs will be using it. Because of that, applications will gradually become more braindead and just expect it to exist. The smarter ones will include it and install it if it isn't found.