This is the 105th 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).
Alexandre kicked out release 20011004 this week. The announcement lists the following changes:
This week in the news we have an interview with Jim Graham, the CTO of CodeWeavers. Jim wraps up the interview with:
A CTO of a large organization with a thousand desktops can buy
one copy of Red Hat Linux, for example, and install it on all
of those desktops without violating any license agreements. With
that, you've got the ability to maintain those from one central
location and work with servers and communicate with any other
desktop (Macintosh, Apple, or Windows) all from the same environment.
We might see a larger utilization of Linux in the workplace, but
I don't believe we're going to get all of the applications over
there immediately. There's going to be a demand to provide both
until there's more application software in the Linux market.
Tools like this are going to provide that bridge.
Guilherme Kunz was having a problem getting a program to run after compiling it with winelib. He was going through the following steps:
I am trying compile a mfc program with winelib.
Well, i compiled the part of mfc which i need for use the program without erros or unresolved functions and compiled the mfc program with the libmfc.so without errors or unresolved functions, but when i ran the mfc program hapned "Segmentation Fault".
I tried use gdb and winedbg but i can't run these debuggers, with gdb happned "Segmentation Fault" with or without breakpoints in the begining of the source and winedbg write only the first line in the window and go out.
Francois Gouget wanted to know what kernel and compiler version was being used. Eric Pouech just wanted to know what the one line of output was. And Aric Stewart thought that the problem was more widespread:
This appears to not just be mfc programs.. recently I have been unable to use gdb on any wine program with either the 2.4.0 or 2.4.9 kernels.
same problems, i get a seg fault when loading libntdll.so
Daniel Sabo wrote in wondering,
What is the proper way to submit a patch to wine? Do you need a
special password to use cvs commit or can you only mail in diffs?
How do you make a propper diff (yeah, I'm really new at this)?
If someone could just add the needed 'fi' to the end of tools/winelauncher.in
I'd be happy too :).
Eric Pouech told him to go check out www.winehq.com for instructions. Bill Medland actually went into detail and suggested:
This is the way that I do it.
My .cvsrc file specifies
cvs -z 3
update -Pd
diff -uThe -u on the diff is important.
Then I sit just below the "wine" on my machine and, for example for all the changes in the documentation directory, I do cvs diff wine/documentation > diff.txt
I then edit diff.txt (actually I number my diff files for my convenience) and add my name and email address at the top and then the description of the change. At the same time I check that the diff file makes sense.
If I wer a good boy I would then test the patch against a clean local copy of the code, using "
patch --dry_run"Finally I email in the diff file to wine-patches.
Uwe Bonnes was having some problems with dll's loading. He provided some debugging info and explained:
some programm using a dll with Borland style imports crashes if the dll is loaded a second time. When PE_fixup_imports is called for the first time, resolving goes fine.
Now ordinal is replace by the function pointer in PE_fixup_imports. The second PE_LoadLibraryExA however goes astray, as it tries to resolve the function pointer as an ordinal in PE_fixup_imports.
What is the right solution? Only treat the value as an ordinal if it is smaller then 0x10000( I suspect that an dll may only have 0xffff entries or the IMAGE_SNAP_BY_ORDINAL wouldn't work)? Or is it an error that we call PE_fixup_imports for the second time at all for an already resolved dll?
Fixup is the process by which a DLL loaded into memory has its executable image changed to take into account the difference between it's base address and actual load address. Alexandre replied that fixup should never be done twice to a DLL. Uwe asked for help at this point because he couldn't figure out how to inhibit that behavior.
Ian Stewart was having a problem loading a program on his daughter's computer. He described what he was trying to do:
Due to resource constraints (75 MHz processor, 1.2 GB hard drive, 16 MB RAM), we recently replaced Windows98 on our daughter's PC with Linux Mandrake, using the IceWM window manager. It isn't quite as flashy as Windows, but it boots beyond the startup screen, which is more than can be said for Win98.
Well, to make a long story short, I've installed and configured Wine following the instructions in the Wine User's Guide. Everything seems to be working properly, but when I attempted to run the setup.exe for 'Jim Henson Muppets Letters: Capital and Small', I received the following errors:
err:ddeml:DdeConnect .. but no Server window available
err:ddeml:DdeClientTransaction Invalid conversation handle
err:ddeml:DdeClientTransaction Invalid conversation handle
err:ddeml:DdeClientTransaction Invalid conversation handle
fixme:ddeml:DdeUninitialize16 stub calling DdeUninitialize
Following the recomendations in the Wine User's Guide, section 3.2 (Installing Wine Without Windows), I re-ran wine with --debug msg +module,+file. I didn't see anything in the trace that jumped out at me, but I've attached it here, just in case it means something to someone else.
One last thing. The setup.exe appears to be a 16-bit app, originally designed for Windows 3.1. Not sure if that makes any difference or not.
Any help in resolving this would be greatly appreciated.
Eric Pouech replied that DDEConnect currently did not work between two different processes.