Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #225 For 4 Jun 2004

By Brian Vincent

Table Of Contents


This is the 225th issue of the Wine Weekly News publication. Its main goal is to keep from getting sunburned. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at

Mailing List Stats For This Week

We looked at 160 posts in 582K.

There were 47 different contributors. 24 posted more than once. 20 posted last week too.

The top posters of the week were:

1. News: SpecOpsLabs Response

29 May 2004 - 4 Jun 2004 (1 post) Archive Link: "News"

Topics: News

People: CodeWeaversNews

SpecOps responded to WWN issue #222. I'd summarize it here, but it's worth reading in full. They make some valid points, but it still remains to be seen if they have actually developed anything. It's perfectly legal for them to keep everything under wraps until they distribute a product, the LGPL specifically allows for that. There were some threads in various forums that may have hinted otherwise, but I was pretty careful not to include them in this newsletter. Of course like any company that does development behind closed doors, it's unknown whether any of their design decisions will ever be beneficial to Wine. Also unknown is whether there is a duplication of effort in progress and to what extent. Slashdot's link to the article drew mixed responses.

2. Winedbg Issue and New Changes

26 May 2004 - 30 May 2004 (9 posts) Archive Link: "Help with winedbg"

Topics: Debugging

People: Shachar ShemeshEric Pouech

Much of this thread occurred last week, but it wasn't resolved until this week. Shachar Shemesh wanted to use Wine's debugger, Winedbg, but couldn't get it to run:

I'm trying to get a Visual C compiled program to run on Wine. I have the sources and full debug info for the PE part of the program. Obviously, however, it was not compiled on the same machine on which it is running.

To make things even more interesting, I would rather use some GUI frontend for the debugger.

As far as I can tell, I have two options to go about this:

  1. Use Visual Studio's remote debugging
  2. Use winedbg as a gdb backend for ddd

Option 1 fails miserably. I suspect the project is just too complex for Visual Studio to handle over the wire. When I try to do that, the Visual Studio front end (the one running on a Windows machine) crashes. This leaves me with just option 2.

When I try to run it like that (winedbg --gdb --no-start), winedbg starts ok. When I hook ddd to it, however, winedbg complains about a missing source file (one that is not in the Windows source, btw). In the mean while, ddd claims to time out on the connection, and closes down.

Eric Pouech asked Shachar to try running just winedbg and not bring ddd into the picture. Shachar got a chance to try it and eventually was able to produce an error log that ended with this line:

err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting

Eric quickly diagnosed the problem, " You don't have fixed font installed that matches wineconsole's needs. Usually, it means you don't have a fixed font installed."

Shachar wondered why a font would stop Winedbg from running at all. Eric explained that it was really a problem launching the console window for Winedbg. To make things more interesting, Eric made some large changes to Winedbg last week. These actually came about after Shachar's problem report. From the changelog:

it's time to make winedbg use dbghelp for its internal working This is the full patch (quite big), that's why it's been gzip:ed.

Among the biggest changes:

The biggest changes since from the end user point of view:

3. Winedbg & DDD

2 Jun 2004 - 3 Jun 2004 (10 posts) Archive Link: "debugger symbols and NPTL on RedHat 9"

Topics: Debugging

People: Shachar ShemeshEric Pouech

Following on the heels of that thread, Shachar ran into another debugging problem that was tougher to solve. Being able to use a graphical debugger is very important for Shachar's work:

I figured that going through the process of getting the program compiled as winelib was unnecessary, so I am still compiling it on Windows using Visual Studio. This, naturally, means that it's a PE. After resolving the font problems, I can finally get the program running through winedbg. While I'm doing ok at working like that, the client really prefers working with a GUI. When I try to run the program using the --gdb switch (with or without --no-start), debug symbols for the PE part are not shown. I get all the symbols for the ELF dlls (wine's DLLs), but not for the PE program.

Is this a solveable problem? The program is using PDBs for debug symbols, they are not compiled into the PEs. I can change that, I guess, but I would really rather not. Will changing that solve anything?

Eric Pouech thought the first thing to try would be to change the debugging options in Visual C++:

I assumed you compiled your program with a recent version of msvc. winedbg doesn't support the latest version of msvc symbolic information. There are IIRC some options to turn on the eldest options (which may end up in putting the info inside the EXE, but that's not mandatory. but since I don't recall all the msvc switches YMMV).

BTW, I still looking for a decent documentation on latest MSVC symbolic info to enhance your debugging support. If someone has some info, I'm interested.

Eric then explained the problem with using gdb, " when run with gdb, the PE symbol lookup doesn't work, gdb doesn't know anything about PE. You need to use winedbg without the gdb proxy. But you will loose the GUI debugging part (a la DDD, or kdbg...). "

Shachar really needed a graphical debugging tool and wondered if it might be possible to simply bypass gdb:

Damn, I was afraid of that answer.

I really wanted to think that the symbol interpretation was done by the backend (winedbg) rather than the frontend.

How possible is it to run "winedbg" as the backend to ddd/kdevelop instead of gdb? Are they even remotely close enough in command line?

Eric thought it might be possible since part of the support was already there:

I never tested that. As far as I can tell, both ddd and kdbg are using the regular gdb command line (not the MI* extensions from gdb). While rewriting winedbg I tried to make the commands as close as possible (from a syntax point of view) from the gdb one's. However, I didn't check yet format of answers and output. The idea anyway was to make winedbg look (command input, but we could do output too) as close as possible to gdb to ease up the migration of users from gdb to winedbg).

But it's likely we'll have some discrepencies in the output (and also the I/O control from the graphical front-end on winedbg which may play some tricks on us). Anyway, it won't be a five minute fix (and Alexandre needs to commit first the "small" pending winedbg part for me to go further).

Alexandre committed Eric's patch later in the week. (Which happens to be one of the largest single patches I can recall being committed in a while.)

4. MSVCRT Headers

1 Jun 2004 - 3 Jun 2004 (8 posts) Archive Link: "Re: [MSVCRT] Cross build fix"

Topics: Ports

People: Hans LeidekkerDimitrie PaunAlexandre JulliardBoaz HarroshMicrosoft

MSVCRT.DLL is a tricky library to deal with. MSVCRT is the Microsoft Visual C++ Runtime. Now, for Winelib apps this is what they expect to use when invoking common C functions such as scanf(), strcpy(), etc. However, Wine itself uses the native C library, which on Linux would be glibc. Hans Leidekker ran into a problem trying to compile on MinGW:

This patch:

broke the MinGW build of msvcrt. The changelog says it's a compatibility fix. Dimi: what compatibility were you aiming at with this patch?

Dimi explained the problem had to do with Winelib app requirements:

Compatibility with other headers. _WCTYPE_T_DEFINED is in a way part of the public interface, and when we use the headers in Winelib apps, we need to define it so we don't end up with duplicate declarations for wint_t/wctype_t. When we build msvcrt it's a different story of course, and we seem to need the exact opposite. Which is why I find the entire MSVCRT() thing not only ugly, but a bit problematic also.

Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts.

Alexandre didn't think it was quite that easy, " No I don't think we want that. The headers are not that stable, we are still making changes to them. We also need the MSVCRT definitions in multiple dlls so there would be a lot of duplication. "

Although the headers themselves aren't stable, Dimi thought the interfaces were. Boaz Harrosh then jumped into describe another method of using one header to redefine parts of another:

When compiling with STLPort I saw a method that can eliminate the need for the MSVCRT macro and yet produce MSVCRT_xxx for those who need it and an xxx for those how don't. Basically you have your Regular cleanroom headers-set for wine-lib and external dlls. And you have another set of headers for msvcrt compilation. In The second set:

Now compilation units that need the MSVCRT_xxx use an extra -I "$wine_include/internal_msvcrt" switch in the make files.

should I random pick an header and demonstrate the Technique?

From what I understand, the need for these differences are so the could define it's own set of functions and in place use gcc-glibc for implementation. This way stirring a way from both duplicates in Linking and conflicts with gcc-glibc headers. [Q] Why don't we avoid glibc all together. Take what ever code we are missing and have a complete self contained implementation? Just like MinGW's -nocygwin

(Now if we where using C++ the problems would be solved in 2 seconds flat: "namespace". Was not "namespace" back ported to C )

Dimi seemed to like the idea, " This can work, one problem is that if we go this way, we'll have to 'shadow' all symbols, or else we'll get conflict with the C library. In any event, it's a tricky method that can result in some strange bugs if we don't redefine all symbols, so Alexandre will have to comment on it if we are to try it out."

Alexandre went back to the original problem that Hans pointed out to show Boaz's method wouldn't work in that particular instance. Dimi went back to the idea of duplicating parts of the headers:

Right, it will not solve problems like this (for Boaz: _WCTYPE_T_DEFINED is a sentry for not defining a type twice, check out pretty much any header under include/msvcrt/ to see how it's used).

However, I did grep the source, and it seems that we're using the MSVCRT_ prefix only in dlls/msvcrt/*.c. And so it's not clear to me that duplicating part of the headers is going to be that bad. I mean, we will need duplication only for the stuff that we use internally across files. That doesn't include math functions for example, and a bunch of other stuff.

If you're positive this is not a good idea, I'll drop it, but if there is a chance it would be acceptable, I might give it a try...

Alexandre felt it might be worth trying as long as regression tests were added to make sure the definitions all remained in sync.

5. AMD64 Issues

3 Jun 2004 - 4 Jun 2004 (2 posts) Archive Link: "(Still) problem on AMD64 with wine CVS"

Topics: Ports

People: Maurizio MongeAlexandre Julliard

There's been some reports lately of people trying Wine on AMD64. It doesn't sound like there's anyone who's been successful. Maurizio Monge tried compiling for a 32-bit environment and reported the following memory allocation problem:

Hello, i have retried to compile wine CVS on amd64 (gcc 3.4 with -m32, etc + kernel 2.6.4-rc2), where i was thinking the 0xc0000000 problem was solved. but i get:

attached to this mail the output of "strace32 wine"

one of the last lines is (i have 512Mb of ram)

It looks like my kernel absolutly wants to allocate memory > 0xc0000000 :-) Any idea?

Alexandre didn't have an immediate solution, but asked for some help narrowing down the problem, " Does it make a difference if you bypass the preloader and run wine-kthread directly?"

Maurizio tried it and ran into the same problem.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.