|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
Git Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins |
Table Of Contents
| 1. | 16 Apr 2001 | (1 post) | RH 7.1 gcc fixes compiler bug |
| 2. | 17 Apr 2001 | (2 posts) | InstallShield and ole question |
| 3. | 19 Apr 2001 - 20 Apr 2001 | (2 posts) | GDB remote debugging |
Introduction
This is the 92nd release of the Wine's kernel cousin publication. It's 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:
Head on over to the download page and grab the source.
1. RH 7.1 gcc fixes compiler bug
16 Apr 2001 (1 post) Archive Link: "RH 7.1 gcc fixes compiler bug"
People: James Juran, Francois Jacques, , Ulrich Weigand
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 Issue #101, Section #1 (21 Dec 2000: Recommended GCC Compiler Version)
2. InstallShield and ole question
17 Apr 2001 (2 posts) Archive Link: "InstallShield and ole question..."
People: Mike Bond, Marcus Meissner, Daniel Walker,
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 prefered 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..
3. GDB remote debugging
19 Apr 2001 - 20 Apr 2001 (2 posts) Archive Link: "GDB remote debugging for wine"
People: Ove Kaaven, , Ove Kåven
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
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.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |