WWN Issue 106

This is the 106th release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator). This week's press release comes out of TransGaming. They've licensed Macrovision's SafeDisc copy protection technology to incorporate into their products. For more info, check out the press release: LINK

This week, 162 posts consumed 595 K. There were 51 different contributors. 30 (58%) posted more than once. 15 (29%) posted last week too.

The top 5 posters of the week were:

27 posts in 73K by Alexandre Julliard
13 posts in 131K by Francois Gouget
11 posts in 29K by Uwe Bonnes
9 posts in 25K by Eric Pouech
9 posts in 30K by [email protected]

Memory Fragmentation	10/10/2001	Archive
Gavriel State posted patch that worked around a memory allocation problem: We just spent about 3 days tracking down a very subtle memory fragmentation problem in an app we're working on. The problem: App allocates lots of little blocks, then a few large blocks, then lots of little blocks. Throughout this process, many blocks would be freed from all over the heap. Repeat ad infinitum. We ended up creating a new subheap every time one of these larger blocks came along. The new space from the subheap then went to the top of the freelist, so all the small allocations then filled it up until the next large block allocation. IE: We never got a chance to reuse freed blocks in older subheaps - at least not very well. This fix addresses the problem by pushing 'large' freed blocks to the end of the free list, leaving 'small' blocks at the front, to be found sooner. The size of 'large' vs 'small' is tunable. Despite the workaround, we're still not too pleased with the current heap allocator. It's quite slow, and still not as efficient as it could be. It would probably be worth the effort to integrate a new allocator - anyone know if there's a high-quality Wine-license- compatible allocator out there? Several people jumped in and discussed how to go about improving performance. Gavriel went on to list several things that need to be considered. Ove KÃven mentioned, Those issues are all part of the "free block selection algorithm" I talked about above. We just need to change the algorithm used there; its effect would be the same as plugging in a whole new allocator. . Pretty much everyone agreed that something could be done to make it work better. Whether that meant ripping out the current algorithms and replacing them or merely tweaking the existing code was up for debate. Adam Moss replied, I remember an analysis of various allocators which was done for Mozilla. This one came out very favourably (I think it had the lowest fragmentation, for example) and it's also public domain. http://g.oswego.edu/dl/html/malloc.html . So far nothing has appeared in CVS.

Memory Fragmentation

10/10/2001

Archive

Gavriel State posted patch that worked around a memory allocation problem:

We just spent about 3 days tracking down a very subtle memory fragmentation problem in an app we're working on. The problem:

App allocates lots of little blocks, then a few large blocks, then lots of little blocks. Throughout this process, many blocks would be freed from all over the heap. Repeat ad infinitum.

We ended up creating a new subheap every time one of these larger blocks came along. The new space from the subheap then went to the top of the freelist, so all the small allocations then filled it up until the next large block allocation. IE: We never got a chance to reuse freed blocks in older subheaps - at least not very well.

This fix addresses the problem by pushing 'large' freed blocks to the end of the free list, leaving 'small' blocks at the front, to be found sooner. The size of 'large' vs 'small' is tunable.

Despite the workaround, we're still not too pleased with the current heap allocator. It's quite slow, and still not as efficient as it could be. It would probably be worth the effort to integrate a new allocator - anyone know if there's a high-quality Wine-license- compatible allocator out there?

Several people jumped in and discussed how to go about improving performance. Gavriel went on to list several things that need to be considered. Ove KÃven mentioned, Those issues are all part of the "free block selection algorithm" I talked about above. We just need to change the algorithm used there; its effect would be the same as plugging in a whole new allocator. . Pretty much everyone agreed that something could be done to make it work better. Whether that meant ripping out the current algorithms and replacing them or merely tweaking the existing code was up for debate.

Adam Moss replied, I remember an analysis of various allocators which was done for Mozilla. This one came out very favourably (I think it had the lowest fragmentation, for example) and it's also public domain. http://g.oswego.edu/dl/html/malloc.html

So far nothing has appeared in CVS.

Solaris x86 Port	10/15/2001	Archive
Francois Gouget posted a rather lengthy email about some work cleaning up some header files. He ended the email with, Doing this (except for port.h) I have a tree that builds on Solaris with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have patches that are almost ready. This announcement prompted a few emails including one from Roger Fujii: does this build run on solaris? I've been trying for the last couple of days to get the beast to run (compiles ok), but it segfaults in various places (currently in NtCurrentTeb()). This in on a solaris 8 dual CPU unit. This is using gas/gld (results were worse with as/ld). Any pointers on debugging this thing? Jeremy White went on to explain that it's absolutely necessary to use the GNU toolchain (gas, etc) instead of the stock Solaris tools. He also recommended grabbing the latest cvs update after Alexandre has all of Francois' patches applied. And then he added, FYI, the #1 bug we're hitting is that in Linux/glibc, you can do printf("%s", NULL), and in Solaris that brings righteous death. Francois also explained: You need to first make sure that you are using the GNU toolchain to build Wine. Otherwise Wine will not work. I believe that not even "./wine" will work. Do you have warnings about an unresolved main symbol when you link Wine's dlls? This is one of the symptoms. Another is when that strip does not understand "--strip-unneeded". Also note that just tweaking the PATH is not enough to switch from the Solaris toolchain to the GNU toolchain. That's because gcc is hard-coded to use '/usr/bin/xxx'. What we have done is to make these symlinks to the GNU toolchain (an alternative is to recompile gcc with the right path... but it takes more time). We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use. The discussion delved into some of the specifics of using GNU tools on Solaris and some of the things that still need to be done. Jeremy White mentioned he had Solitaire working. Hey, what more do ya need out of Windows system?

Solaris x86 Port

10/15/2001

Archive

Francois Gouget posted a rather lengthy email about some work cleaning up some header files. He ended the email with, Doing this (except for port.h) I have a tree that builds on Solaris with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have patches that are almost ready.

This announcement prompted a few emails including one from Roger Fujii:

does this build run on solaris? I've been trying for the last couple of days to get the beast to run (compiles ok), but it segfaults in various places (currently in NtCurrentTeb()). This in on a solaris 8 dual CPU unit. This is using gas/gld (results were worse with as/ld).

Any pointers on debugging this thing?

Jeremy White went on to explain that it's absolutely necessary to use the GNU toolchain (gas, etc) instead of the stock Solaris tools. He also recommended grabbing the latest cvs update after Alexandre has all of Francois' patches applied. And then he added, FYI, the #1 bug we're hitting is that in Linux/glibc, you can do printf("%s", NULL), and in Solaris that brings righteous death.

Francois also explained:

You need to first make sure that you are using the GNU toolchain to build Wine. Otherwise Wine will not work. I believe that not even "./wine" will work. Do you have warnings about an unresolved main symbol when you link Wine's dlls? This is one of the symptoms. Another is when that strip does not understand "--strip-unneeded".

Also note that just tweaking the PATH is not enough to switch from the Solaris toolchain to the GNU toolchain. That's because gcc is hard-coded to use '/usr/bin/xxx'. What we have done is to make these symlinks to the GNU toolchain (an alternative is to recompile gcc with the right path... but it takes more time).

We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.

The discussion delved into some of the specifics of using GNU tools on Solaris and some of the things that still need to be done. Jeremy White mentioned he had Solitaire working. Hey, what more do ya need out of Windows system?

InstallShield 6 Success	10/13/2001	Archive
Ove KÃven has been working on getting the latest version of InstallShield based installers working. He's submitted several patches into CVS lately. On Saturday he announced: Apart from the two patches I just submitted to wine-patches, a stdole32.tlb from real Windows, and the registry entries in winedefault.reg, you need my interprocess com hacks, which I've now put on WineHQ: http://www.winehq.org/~ovek/install.diff The installation progress bar doesn't seem to display for some reason (might be a repaint issue or something else related to Alexandre's latest work, or something completely different, don't know), but anyway, even if it doesn't tell you its progress, it actually successfully installs now! I hope I can get enough time to structure that interprocess com stuff properly, so that it can work the way MS designed it, which involves RPCRT4.dll and friends... Dan Kegel was quite happy and wanted to know where to send the pizza and beer. Gavriel replied: Well, in addition to sending pizza to Ove (I don't think he likes beer), you might consider telling all your friends to sign up for our subscription services. 8-) Ove's work has been part of the final push we're doing before going live on October 22nd.

InstallShield 6 Success

10/13/2001

Archive

Ove KÃven has been working on getting the latest version of InstallShield based installers working. He's submitted several patches into CVS lately. On Saturday he announced:

Apart from the two patches I just submitted to wine-patches, a stdole32.tlb from real Windows, and the registry entries in winedefault.reg, you need my interprocess com hacks, which I've now put on WineHQ: http://www.winehq.org/~ovek/install.diff

The installation progress bar doesn't seem to display for some reason (might be a repaint issue or something else related to Alexandre's latest work, or something completely different, don't know), but anyway, even if it doesn't tell you its progress, it actually successfully installs now!

I hope I can get enough time to structure that interprocess com stuff properly, so that it can work the way MS designed it, which involves RPCRT4.dll and friends...

Dan Kegel was quite happy and wanted to know where to send the pizza and beer. Gavriel replied:

Well, in addition to sending pizza to Ove (I don't think he likes beer), you might consider telling all your friends to sign up for our subscription services. 8-)

Ove's work has been part of the final push we're doing before going live on October 22nd.

Implementing netapi32.dll 10/18/2001 Archive

Implementing netapi32.dll	10/18/2001	Archive
Michael Riedel posted a note wondering what might be needed to get some software to work: I am going to migrate the EDA software environment from Windows NT to Linux but I have still some software components requiring Windows. That's why I use Wine. I own and use some software packages licensed to a valid MAC address (flexlm MAC based license) and the corresponding NIC is present in the Linux system. Using wine-20010824 I get the following message: `fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS` I scanned the Web resources and studied the file 'win32/device.c' a little bit but I got no answers to my questions. Is there already a solution/implementation for this service? I am also ready to contribute (at least I hope I'm able to do so and it would be fun ;-) but I need some advice (docus, especially related to the VNETBIOS VxD and some general hints). I'm looking forward for any hints. Uwe Bonnes responded first, I guess, the license isn't bind to a physical dongle on the parallel port. So one can conclude that the software tries to read the MAC. This probably happens in a NETBIOS.DLL call which then probably calls the NETBIOS.VXD. I propose you run with `--debugmsg +relay,+snoop,+vxd` and try to decipher what is going on before that failing VXD call. In the easiest approach, you can build a fake builtin NETBIOS DLL, with the appropriate function returning the MAC in the first approach hardcoded or really reading it with OS calls. Patrik Stridvall added, NETBIOS.DLL is not documented like NETAPI32 AFAIK is so it is more likely that it calls NETAPI32. Also note the NETAPI32 imports the NETBIOS.DLL function _Netbios so it would be a little strange if the application called NETBIOS directly but you never know. :-) Michael sent in a trace like Uwe asked. Patrik took a look and replied: Good. It seems to work exactly the way I thought (or rather hoped) it would. Now we can presumably forget about the VxD and the undocumented NETBIOS DLL and concentrate on implementing the documented NETAPI32 DLL. It would be interesting to know what's the content of the NCB structure that Netbios takes as pointer to as argument. So the next step would be to make a Wine implementation of the NETAPI32.DLL with a stub with an appropriate TRACE to display to NCB structure. I don't think I have time do it is the next few days though. Can somebody else please do it? PS. On second thought perhaps we should make the NETAPI32.DLL just a forward to the NETBIOS.DLL. It seems from the trace above that the Netbios function in NETAPI32.DLL is the same function as _Netbios in NETAPI32.DLL and Netbios is the only function in NETAPI32 while NETBIOS have more functions even though they are AFAIK undocumented. Then the discussion turned toward implementing a netapi32.dll since the functions there were documented. One of the first things brought up was how to get the MAC address of an ethernet card. Several suggestions were thrown about including looking at the source for ifconfig and using an ioctl() on /proc/net entries.

Michael Riedel posted a note wondering what might be needed to get some software to work:

I am going to migrate the EDA software environment from Windows NT to Linux but I have still some software components requiring Windows. That's why I use Wine. I own and use some software packages licensed to a valid MAC address (flexlm MAC based license) and the corresponding NIC is present in the Linux system.

Using wine-20010824 I get the following message:

fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS

I scanned the Web resources and studied the file 'win32/device.c' a little bit but I got no answers to my questions. Is there already a solution/implementation for this service? I am also ready to contribute (at least I hope I'm able to do so and it would be fun ;-) but I need some advice (docus, especially related to the VNETBIOS VxD and some general hints).

I'm looking forward for any hints.

Uwe Bonnes responded first, I guess, the license isn't bind to a physical dongle on the parallel port. So one can conclude that the software tries to read the MAC. This probably happens in a NETBIOS.DLL call which then probably calls the NETBIOS.VXD. I propose you run with --debugmsg +relay,+snoop,+vxd and try to decipher what is going on before that failing VXD call. In the easiest approach, you can build a fake builtin NETBIOS DLL, with the appropriate function returning the MAC in the first approach hardcoded or really reading it with OS calls. Patrik Stridvall added, NETBIOS.DLL is not documented like NETAPI32 AFAIK is so it is more likely that it calls NETAPI32. Also note the NETAPI32 imports the NETBIOS.DLL function _Netbios so it would be a little strange if the application called NETBIOS directly but you never know. :-)

Michael sent in a trace like Uwe asked. Patrik took a look and replied:

Good. It seems to work exactly the way I thought (or rather hoped) it would.

Now we can presumably forget about the VxD and the undocumented NETBIOS DLL and concentrate on implementing the documented NETAPI32 DLL.

It would be interesting to know what's the content of the NCB structure that Netbios takes as pointer to as argument.

So the next step would be to make a Wine implementation of the NETAPI32.DLL with a stub with an appropriate TRACE to display to NCB structure.

I don't think I have time do it is the next few days though. Can somebody else please do it?

PS. On second thought perhaps we should make the NETAPI32.DLL just a forward to the NETBIOS.DLL. It seems from the trace above that the Netbios function in NETAPI32.DLL is the same function as _Netbios in NETAPI32.DLL and Netbios is the only function in NETAPI32 while NETBIOS have more functions even though they are AFAIK undocumented.

Then the discussion turned toward implementing a netapi32.dll since the functions there were documented. One of the first things brought up was how to get the MAC address of an ethernet card. Several suggestions were thrown about including looking at the source for ifconfig and using an ioctl() on /proc/net entries.

Figuring Out Media Types	10/18/2001	Archive
Ove KÃven posed a question: I'm trying to think of a way to make multi-CD installers work under Wine. Right now, the hardest part is that when the installers tell you to change discs, the Setup.exe file mappings are still open. I'm thinking of making Wine not map the file, but read it straight into RAM, if the executable to be mapped is on removable media. But since to do this, MapViewOfFile needs to know the media type, and the file name is only known in CreateFile, I apparently need to store the media type in the wineserver object to accomplish this. Would changing the wineserver protocol in this way be a good idea? He included a patch to include the media type in the protocol. Alexandre replied, It's certainly a possibility. It would be nice to be able to tell directly from the file descriptor, so that we wouldn't depend on the user getting the drive specifications right. But I can't think of a Unix function that would allow doing this cleanly. And that's about where the thread left off.

Figuring Out Media Types

10/18/2001

Archive

Ove KÃven posed a question:

I'm trying to think of a way to make multi-CD installers work under Wine. Right now, the hardest part is that when the installers tell you to change discs, the Setup.exe file mappings are still open. I'm thinking of making Wine not map the file, but read it straight into RAM, if the executable to be mapped is on removable media.

But since to do this, MapViewOfFile needs to know the media type, and the file name is only known in CreateFile, I apparently need to store the media type in the wineserver object to accomplish this.

Would changing the wineserver protocol in this way be a good idea?

He included a patch to include the media type in the protocol. Alexandre replied, It's certainly a possibility. It would be nice to be able to tell directly from the file descriptor, so that we wouldn't depend on the user getting the drive specifications right. But I can't think of a Unix function that would allow doing this cleanly.

And that's about where the thread left off.

Remote Win32 API	10/19/2001	Archive
Luke Leighton (of Samba fame) posted a short note about more Win32 API's being available: hi there, i thought i'd put up a more eye-catching subject line. to clarify: yes, that's right, FreeDCE has a set of remote Win32 APIs. see http://sourceforge.net/projects/freedce for details. if anyone would like to help get these integrated into wine, please contact me for more information.

World Wine News