April's polling section has now been closed and the new votes for May are up. Check out the topics at in our voting section.

We have made sufficient progress with WineX 3.0 and Point2Play that the following poll topics have been removed:

• Better support for Installshield
• Separate installation sites for each game (this is a primary feature of Point2Play)
• Improved support for copy protected games

FYI With the attached patch on top of the wine cvs tree, a no-cd install (requires native msvcrt until I fix the 'thiscall' issue) and running 'wine war3' warcraft 3 now appears to be pretty much right!!! (No more screen distortion / misplaced faces etc).

Thanks to everyone who has helped get this far, especially Raphael and Lucho.

I tested GTA3 again, but this time with the latest cvs. GTA3 runs much faster now and produces only one error:

fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402fc60) : stub

Again, no in-game textures are being shown, only polygons and colors. The only texture that is being shown is the title of the game in the game menu.

I had been running wine on 7.2 with Lotus Notes 5.0.11 successfully. I made the unfortunate discovery about RH9 and threads and wine a little too late after upgrading to RH9. I will be more careful next time...

Anyways, I downloaded the source (2003-05-08), and managed to configure with --with-nptl

But I ran into a problem that has already been reported at (thank you google)

http://www.winehq.com/hypermail/wine-devel/2003/05/0141.html

(the issue was unresolved. Kevin rolled back to a previous wine source from 5/1/2003). As with that post, there had been no changes to the install in the wine directory. The Lotus Notes splash screen comes up. The background for Notes itself comes up. The password box appears, and the error happens when I punch in the password and hit OK.

My apologies for not announcing this sooner, but it seems that the DCE RPC documentation package, which many of you kindly donated funds for, is a no-go. I've spent some time researching what, if anything, we need from OpenGroup, and unfortunately, I've never been able to get a coherent answer, even from OpenGroup's sales people.

Part of the problem seems to be that the DCE standard is "discontinued" by OpenGroup as a project. We wouldn't care if we knew what documents had relevance to wine. But it turns out that DCE covers a lot more than just RPC, most of which is not of interest to wine's RPC implementation. The RPC part of the standard, as far as I can tell, is freely available for download, including the fascinating "DCOM/ActiveX" standard (which refers to a separate ORPC standards document I have been unable to find, I'm afraid, to document the ORPC wire protocol :(; btw, I think Microsoft let their similar document fall of the 'net as well, you'll see links to it in various places... but I digress....)

So, insofar as I have questions about whether or not there's anything useful in there, OpenGroup's sales lady is unable to help -- she don't even seem able to give me the information thats available on the website, much less elaborate on it. That leaves me with no choice but to guess what is useful based on the information available to me: which seems to indicate that we don't need anything we can't get for free from OpenGroup.

So, the obvious question is, where does everyone's hard-earned money go? I've confirmed with Jeremy that refunds are an option; if you want your money back, let Jeremy know, and presumably he will make arrangements with you in private to get your money returned.

For those of you who would rather have your donations go to some other wine-releated cause, the matter is open for discussion. One idea which has been tossed around in private discussions between myself, Jeremy and Dimi is to rededictae these funds to the Wine Party Fund or some other wine conference fund. Another would be to find some other documentation we need to buy and use it for that. But, it's your money, and since every contributor essentially has veto power over their own portion of the funds, we obviously want to build some kind of consensus.

Sorry it took me so long to break this news, I spend a fair amount of time trying to salvage the original plan to buy the DCE doc's but it just didn't seem right to spend it on something which potentially has no value to wine... and then the guilt and procrastination set in... ;) Thanks for your patience on this matter.

For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website:

http://developer.kde.org/~sewardj/

no patching needed to WINE or valgrind. Just get the latest snapshot of WINE (or a CVS checkout), build for debugging, get the pre-patched valgrind and use it!

there are still plenty of bugs in WINE which need fixing - most are simple 1 line edits..

I am doing some work trying to seperate Ole* and Ole32 for use in ReactOS. Before we can make use of most of the WINE code all of the Non-Win32api imported functions are going to need to be compiled out or rewitten. I dont need someone to do this for me but I am going to need a little hand-holding as I dont want to waste my or anyone elses time.

Currentlly Ole32 Imports these non-Win32api functions:

• From GDI32.dll
  • CloseMetaFile16
• From Kernel32.dll
  • FreeLibrary16
  • GetCurrentTask
  • GetModuleHandle16
  • GetProcAddress16
  • GlobalAlloc16
  • GlobalFree16
  • GlobalLock16
  • GlobalReAlloc16
  • GlobalSize16
  • GlobalUnlock16
  • K32WOWCallback16Ex
  • K32WOWGlobalAllocLock16
  • K32WOWGlobalUnlockFree16
  • LoadLibrary16
  • LockResource16
  • MapLS
  • UnMapLS

Anywhere here is the first patch that removes a few of these imports if --disable-win16 is passed to configure. I still have a lot to go and this may need some cleanup/review from a OLE guru on Linux but it builds for me without warnings or errors under Mingw.

Changelog: Seperate Win16 and Win32 Ole support in memlockbytes.

Well, you are probably going to laugh, but now that we are using some MIDL-generated code, I'm racking my brains on how to improve the exception handling macro's built into wine. The MIDL-generated code utilizes the typical Microsoftian (Borlandian?) try { } except(bool expr) { } / try { } finally { } construct.

Possible goals are:

• achieve real "SEH"-style syntax, that is, no bloody __ENDTRY macro.
• fix "break"
• fix "return" from try/finally blocks.

Now here comes the part that will make you laugh: I'm supposed to do all this without patching gcc, using c++, or doing anything nonportable. In reality, an x86-specific solution that really worked would probably cut the mustard, IMO, at least as a starting point for cross-platform support.

I made some proof-of-concept patches which use the existing wine macros and various gcc-ism's to achieve some of these goals (they are not "right", of course). I had given up on it, or at least put it on the back burner, but Ove's recent DCOM patches inspired me to continue bashing my head against the wall...

Anyhow, I'll take a look at the dwarf2 goodies, maybe I'll decide that it's do-able, but more trouble than its worth... either way, I intend to make some kind of patch out of this whole investigation, as I am pretty darn sure I can at least fix one of the forementioned deficiencies, maybe even two, without making any major sacrifices.

If I'm lucky, I will stumble upon a solution to all three, but I'm kind of learning some of this (OK, all of it ;) ) as I go, and somewhat skeptical of my chances...

Knowing you, Dr. Weigand, you probably instantly know how to achieve this, so don't worry about spoiling the fun, you can go ahead and tell us ;)

Implement gcc-specific "__TYPED_TRY" macro supposedly capable of intercepting return and running the finally clause. If it compiles, it should work on x86... If it fails to compile, it needs you to specify the return type as in

__TYPED_TRY(float) {
} __FINALLY(func) {
} __ENDTRY

Other arches may have much less success ;) of course, almost any problem of this kind should be fixed by turning __TRY into the appropriate __TYPED_TRY. __TRY generates warnings, some may be fixable.

Cool! now you can start considering how to support continue, break, and goto ;-)

(I don't want to discourage you, but I think you will eventually come to realize that the only way to make this work right is to do it in the compiler)

For the first time we are in the first 30 downloads (position 29 :)) on SourceForge:

http://sourceforge.net/top/toplist.php?type=downloads_week

We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;)