• 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.

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.

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

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).

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?

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
user 0m4.129s
sys 0m0.102s

In other words, preprocessing is like 10% of compilation, so it can't be unbearably slow.

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

http://www.winehq.com/news/?view=36#Wine's%20resource%20compiler

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.

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.

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.

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?

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:

http://www.dssd.ca/wine/winecfg1.png http://www.dssd.ca/wine/winecfg2.png

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.

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.

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...

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.