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 www.winehq.org
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.
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:
- Use Visual Studio's remote debugging
- 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:
- all symbol information storage is now module relative, so we can unload a module (and it's debugging information), and a process without pain
- portabiblity to another CPU should be easier now (CPU dependent backend)
- speed up memory allocation
- stabs related fixes:
- now correctly handling symbol's size
- blocks {} in functions are now correctly recognized and stored (also applies to local variables scoping)
- better basic types management (less wild guesses in the code)
- full support of inline functions (source stepping now shows the code in .h files for example)
- removal of external debugger (attaching with gdb is just fine to debug winedbg)
- fixed a couple of issues for symbol address handling (address lookup, incorrect type binding)
- winedbg now has a man page
The biggest changes since from the end user point of view:
- the $regs variable has disapeared
- all the 'walk' commands have now been merged into the 'info' ones. 'walk' is no longer a valid command
- module identification in symbol name now has the form of <module>!<symbol> which is the dbghelp/windbg way (instead of <module>:<symbol> or <module>.<symbol>)
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.)
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:
http://www.winehq.org/hypermail/wine-cvs/2004/04/0357.html
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:
- each header does some magic like #define stat_t MSVCRT_stat_t
- than #include <original/header.h>
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 msvcrt.dll.so 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.
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:
wine: failed to initialize: /opt/wine/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memoryattached to this mail the output of "strace32 wine"
one of the last lines is (i have 512Mb of ram)
old_mmap(NULL, 482376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot allocate memory)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.