WWN Issue 92

This is the 92nd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (a port of the Windows API to Unix-based operating systems).

This week a new snapshot was released, 20010418. In the CHANGELOG Alexandre pointed out the following new features:

DirectDraw restructuration and improvements.
MSVCRT headers for compiling Winelib apps.
Postscript driver enhancements.
Several multimedia fixes.
Lots of bug fixes.

Head on over to the download page and grab the source.

RH 7.1 gcc fixes compiler bug	04/17/2001	Archive
RedHat 7.0 users will want to upgrade their gcc packages to the ones in RedHat 7.1. As discovered about two weeks ago by Francois Jacques and Ulrich Weigand, Red Hat's gcc-2.96-69 package has a bug which shows up in the HOOK_CallHook function in windows/hook.c (and possibly other places). Red Hat 7.1 contains gcc-2.96-81, which fixes this bug. Users of Red Hat 7.0 should install the gcc and cpp packages from Red Hat 7.1 to fix this problem. RedHat took a lot of grief last year when they released what many people consider an experimental compiler. Officially there is no such thing as gcc 2.96, but RedHat made the internal decision to include a development snapshot pulled from the CVS tree. However, as of January gcc has been in a feature-freeze. The next major release, gcc 3.0, will be based on this code. From the Wine HOWTO : Here is a list of packages you need. ... gcc version 2.7.2.3 or egcc (egcs) [now gcc 2.9x] This topic has been covered in numerous online forums, for some other discussion of it refer to Kernel Traffic <kcref></kcref>

RH 7.1 gcc fixes compiler bug

04/17/2001

InstallShield and ole question	04/18/2001	Archive
Mike Bond wrote: Quick brief, I've been lurking for quite some time around WineHQ and the wine project, but don't really have time for putting a lot of devel into it. It seems wine is finally getting close enough to working for most things that I can put some time into tracking problems without gobbling up many hours. All that said, I've been trying to get some InstallShield v6 based installers to work with wine without much success. I've tried various combinations of builtin and native versions of the ole related dlls, each configuration with it's own hitches. With a mostly 'native' configuration, I get the 0x80070008 (ERROR_NOT_ENOUGH_MEMORY) error when trying to load IKernel.exe. I did not spend a lot of time with this as 'builtin' really is the preferred method anyway. My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration. Installing programs has been a huge headache for a long time. Lately there's been work done in this area that will eventually allow programs to be installed without Windows. However, there are issues with installation programs requiring interprocess OLE communication. This is what Mike was referring to. Marcus Meissner replied: This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff. This is not a trivial 100 line patch, its more like 20000+ lines. Daniel Walker disagreed and thought, The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL. In a related post, Daniel Walker also wrote: I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why. The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work..

Archive

Mike Bond wrote:

Quick brief, I've been lurking for quite some time around WineHQ and the wine project, but don't really have time for putting a lot of devel into it. It seems wine is finally getting close enough to working for most things that I can put some time into tracking problems without gobbling up many hours.

All that said, I've been trying to get some InstallShield v6 based installers to work with wine without much success. I've tried various combinations of builtin and native versions of the ole related dlls, each configuration with it's own hitches.

With a mostly 'native' configuration, I get the 0x80070008 (ERROR_NOT_ENOUGH_MEMORY) error when trying to load IKernel.exe. I did not spend a lot of time with this as 'builtin' really is the preferred method anyway.

My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.

Installing programs has been a huge headache for a long time. Lately there's been work done in this area that will eventually allow programs to be installed without Windows. However, there are issues with installation programs requiring interprocess OLE communication. This is what Mike was referring to. Marcus Meissner replied:

This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff.

This is not a trivial 100 line patch, its more like 20000+ lines.

Daniel Walker disagreed and thought, The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL.

In a related post, Daniel Walker also wrote:

I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why.

The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work..

GDB remote debugging	04/20/2001	Archive
Ove KÃven wrote in with: As we all know, gdb isn't very compatible with wine, since gdb makes so many assumptions about the operating environment that isn't true in wine. But lately it occurred to me that perhaps it's possible to use gdb's remote debugging features to solve these issues. So recently, I've been secretly experimenting with writing gdb-server code in the wineserver. It goes something like this... `./configure --enable-remote-gdb [...blah...] $ wine stuff gdb socket ready at: target remote localhost:1234 $ gdb wine (gdb) target remote localhost:1234` and you're currently able to look at registers, backtrace, list all the threads, change thread, and read process memory... neato. But its usefulness might be quite limited since gdb doesn't know about the dynamically-loaded dlls so it doesn't automatically load their symbols... does anyone have ideas on how to solve that? It doesn't appear that the standard remote protocol have a command to tell gdb, and I don't know how gdb ordinarily does it.

World Wine News