World Wine News

WHAT'S NEW with Wine-20030911: (see ChangeLog for details)

• Many improvements to the winecfg configuration tool.
• Massive header files cleanup for better source compatibility.
• Some more progress on the kernel/ntdll separation.
• Lots of bug fixes.

TransGaming's Toronto and Ottawa offices were both hit by the massive power outage that affected about 50 million people in portions of the US and Canada. As late afternoon rolled around, our computers abruptly turned off leaving us increasingly wondering "would the bar down the street have power"? Unfortunately cold beer was not to be found as bars were shut, public transport was crippled, and people and cars filled the streets. We hope that those similarly affected managed to enjoy the forced extra long weekend and did not suffer any major disruptions.

Here are August's top-ranked technology poll items:

• DirectX 8 Support: Direct3D
• Improve overall sound support
• Support new features in XFree86 4.3
• Support Older Games
• Improve 3D performance

I doubt this will ever make it in to WINE as Martin has been using C++ to implement our explorer clone but you might want to have a look at it if you want an explorer clone for WINE.

http://www.sky.franken.de/explorer/index.html

You will want to get the current source from ReactOS CVS. Martin has made a lot of changes to support both WINE and ReactOS and been working on improving WINEs shell32.

I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.

Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).

compiling with --with-nptl gets me slightly further. Running wine without parameters produces the help printout. However, when I try to actually run something, this does not work. It doesn't matter what I try to run (whether winelib or Windows). I get a series of "unhandled expection". This happens even for the regedit that is supposed to install my default registry via tools/wineinstall

Any ideas? Anyone?

If they are not still on your system ( /var/cache/apt/archives/ ) you can download them from a local Debian mirror in pool/main/g/glibc.

Then I did

| dpkg -i libc6-dev_2.3.2-5_i386.deb libc6_2.3.2-5_i386.deb locales_2.3.2-5_all.deb

I've just got a bug report on it (#210300) so I've taken a look. So, this pthread_cond_timedwait.dpatch contains:

--- libc/linuxthreads/sysdeps/pthread/pthread-functions.h.jjÂÂ 2003-04-20 03:37:06.000000000 -0400
+++ libc/linuxthreads/sysdeps/pthread/pthread-functions.hÂÂÂÂÂ 2003-09-01 05:35:34.000000000 -0400
@@ -54,6 +54,8 @@ struct pthread_functions

ÂÂ int (*ptr___pthread_cond_signal) (pthread_cond_t *);
ÂÂ int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);
+ int (*ptr___pthread_cond_timedwait) (pthread_cond_t *, pthread_mutex_t *,
+ ÂÂÂÂÂÂÂÂÂÂÂÂconst struct timespec *);
ÂÂ int (*ptr_pthread_equal) (pthread_t, pthread_t);
ÂÂ void (*ptr___pthread_exit) (void *);
ÂÂ int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);

Compare with Wine's scheduler/pthread.c:

struct pthread_functions
{
...

int (*ptr___pthread_cond_init) (pthread_cond_t *, const pthread_condattr_t *);
int (*ptr___pthread_cond_signal) (pthread_cond_t *);
int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *);
int (*ptr_pthread_equal) (pthread_t, pthread_t);
void (*ptr___pthread_exit) (void *);
int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);

...
};

See the problem?

Hmm, now should I complain to Debian's glibc maintainers, or is this Wine's problem?

When trying to compile Wine without optimizations, the compilation fails. I'm trying clean sources, with the "--with-nptl" flag.

The failure (so far, I'm still trying to figure these things out) are when compiling ntdll and the wine executable itself. Both cases, the problem is that same. The linker complains that "InterlockedCompareExchange" cannot be found. Adding kernel32 to the IMPORTS Makefile at dlls/ntdll and miscemu/wine seem to solve these problems, but I'm somewhat worried, and would like to get a second opinion before I submit a patch about this.

Don't do it then <g>

That's a temporary problem because dll separation is not finished. It will be fixed soon, in the meantime just make sure to compile at least ntdll with optimization.

For a very long time now, enabling DGA causes mouse/keyboard events to be ignored. There have been a few threads on this issue in the past, and it seems nobody is willing to actually fix this problem (even though some have submitted patches to fix it, nothing has ever made it into CVS). Why is this? Overall, the problem seems to be related to the use of separate per-thread X display handles, along with a global (separate) "GDI" display. At first I tried just making the first thread's display the "global" display, but since that didn't work, and I don't have the patience to figure out why this dichotomy exists, here's a simple patch which at least works for a few games I tried (but still has mouse problems with a few other games I've tried - there was a mouse fix on an earlier thread(1) on this subject, but it doesn't work -- perhaps it has something to do with the fact that DGA only returns relative mouse movement, and non-DGA returns absolute movement). On the other hand, you could just at least make your default behavior and sample config not enable DGA.

all those patches are based on having gdi_display receive events. It should not. Consequently, DGA should be initialized using a per-thread display so that events arrive on a per-thread display. Originally I had thought that the DGA driver could create a separate thread and use its thread display, but it may not be strictly necessary, given that DirectDraw needs a cooperative window, and windows are per-thread objects, so the thread that owns the cooperative window could also own the DGA display. If we also assume that this thread calls SetMode, it's probably okay to just use the current thread_display() instead of gdi_display. But I suppose it's probably still safer to let DGA create its own thread, though somewhat more involved (you may have to use XSendEvent or some kind of wineserver stuff to forward keyboard and mouse events to the thread that owns the cooperative window). Besides, a separate thread would allow the DGA code to handle its own events, instead of scattering DGA special cases around the rest of the x11drv event-handling code.

It'd be nice to use fontconfig in future to locate font installation paths. There is a simple API:

FcStrList FcConfigGetFontDirs (FcConfig *config);

which should let us use a small part of it, even if we don't use all of it. It means we don't need to make the user manually configure font paths.

Does anybody know how hard this would be?

I don't have or use any windows installation or compilers, but as a wine user and openssl developer I was curious anyway about how well win32 versions of openssl programs and libraries would function under wine. It turns out that the PRNG polling touches on some system monitoring functions for additional sources of entropy, and these were generating some exceptions.

So this just adds two stub functions that cause openssl to work (the error values returned from these two stub functions prevent the oodles of other functions from being used). This should help not only openssl programs (and scripts that use them), but also any win32 programs that depend on openssl DLLs.

PS: the types added with NetStatisticsGet are not used, but will be needed if the stub is later implemented. The structure definitions in both patches were taken from msdn's online API reference - so don't commit if this is a violation of any legal fineprint.

PS2: I could have added stubs for the other Heap32<foo> functions too, but after doing the first one (and learning a little about the ntdll/kernel build) everything worked. Should I send stubs for the rest too?

Now, can you tell me if the code seems ok to you? :-) It's my first submission to wine-patches and I note that it hasn't as yet elicited any response, either as a rejection or a commit. FWIW: I was using the prebuilt openssl installer for version 0.9.7b from:

http://www.shininglightpro.com/search.php?searchname=Win32+OpenSSL

This installer appears to run well under wine. My changes were sufficient to get "wine /path/to/openssl/bin/openssl.exe -- speed rsa1024 " working, and although the timing mechanisms for benchmarking don't appear to work properly (another problem for another time), it is nonetheless doing crypto operations satisfactorily. As these routines include assembly optimisations and there being a somewhat clunky win32 compilation system behind it (long story), this was a useful test from my point of view.

But anyway, the point was to get the libs and crypto executing, and I suspect those two stub functions would be enough now for any applications using openssl libraries under wine.

HP has recently extended the loan I requested on this alpha pws500 workstation for another year. If anyone is interested in working on porting WINE or ReactOS to the alpha email me privately and I can setup a account for you on the system.

I have another system a friend has let me borrow for at least a few months if anyone is interested in doing some porting work on it. Its a SGI Indigo 2 IMPACT 10000. I still need to load linux on it and get it up on the network though it will be a few weeks before anyone can use it if they are interested in starting a MIPS port