This is the 106th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator). This weeks 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
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.
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-uneeded".
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?
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.com/~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.
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 requireing 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 VNETBIOSI 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
Patrik Stridvall added, --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.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 intresting to know what the content of 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.
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.
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://dcerpc.net for details.
if anyone would like to help get these integreated into wine, please contact me for more information.