WineHQ

World Wine News

All the news that fits, we print.

05/09/2003
by Brian Vincent
Issue: 169

XML source
More Issues...

This is the 169th release of the Wine's kernel cousin publication. Its main goal is to inform you of what's going on around Wine (the Un*x Windows emulator).


This week, 214 posts consumed 623 K. There were 67 different contributors. 34 (50%) posted more than once. 30 (44%) posted last week too.

The top 5 posters of the week were:

  1. 22 posts in 56K by Dimitrie O. Paun
  2. 16 posts in 50K by hatky
  3. 14 posts in 52K by Uwe Bonnes
  4. 12 posts in 25K by Eric Pouech
  5. 12 posts in 31K by Sylvain Petreolle

News: Wine-20030508, Lycoris GamePak 05/03/2003 Archive
News

Another Wine drop, you know the drill. Alexandre noted the following changes with Wine-20030508:

WHAT'S NEW with Wine-20030508: (see ChangeLog for details)

  • Some more reorganizations of the source tree.
  • A few more steps towards kernel/ntdll separation.
  • Many Direct3D improvements.
  • More compatible COM interfaces definitions.
  • Lots of bug fixes.

Lycoris announced their GamePak distribution:

Breaking down one of the barrriers to widespread adoption of Desktop/LX as a mainstream operating system, Lycoris and TransGaming unleash the GamePak. A powerful package of five (5) native Desktop/LX games, the GamePak comes bundled with access to one free month of WineX which allows Desktop/LX users to play over 250 Windows games on their Desktop/LX PC. At the low price of $34.95, the GamePak gives Desktop/LX users value, action and compatibility in a single, simple to install package. The GamePak is immediately available from The Lycoris Store .

Looks like an easy way to get WineX installed and configured. TransGaming has no announcement on their web site.

eWeek has a positive albeit lame review of CrossOver Office 2.0.


Compiling Mozilla With Wine Tools 05/08/2003 Archive
Winelib

I asked the following on Thursday:

Anyone see the release info for Mozilla 1.4 Beta? It says:

    "As of Mozilla 1.4b, it is possible to build Mozilla for Win32 using GCC."

Here's the specific build instructions for Windows:

It notes:

    "GCC for Win32 is available as part of the MinGW project. The following mingw packages are required for building:
    • gcc >= 3.2.2 (20030208)
    • binutils >= 2.13.90 (20030104)
    • w32api >= 2.3
    • mingw-runtime >= 2.4"

Mozilla used to be listed on the fun projects page. It was removed last month because Mozilla could only be compiled with MSVC. Yes, we all know Mozilla has native versions for zillions of platforms, but compiling the Win32 version with Winelib would stress the toolchain and uncover things that need to be fixed. Dimi wrote back with a list of known issues that still need to be resolved:

Yes, the 1.4 release will build on MinGW/Cygwin. With a bit of luck, we'll have a binutils release in a week or two, so we can remove some of the ugly, ugly hacks that were put it to work around windres problems that have since been fixed.

Some of this fixes will help a little with an eventual Wine port, but this one will be tough. We still need a lot of work on winegcc/winewrap to get this to work, let alone possible enhancements to gcc for -mthread support.

We are currently failing on simple things with winegcc. For example:

  1. It seems that MinGW's gcc support both main() and WinMain() as entry points irregardless of the -mwindows flags. We don't. This results in configure tests. For example, we can't currently build wxWindows using their configure script because configure invokes winegcc with the -mwindows flag even though it builds simple console apps that have a simple main() function. This obviously works under MinGW. I have little knowledge about linking issues like this, how can we support that in wingcc/winewrap?
  2. We need to add support for the -shared flag to winegcc. This is a big task, and we haven't even started to look at these issues.
  3. I haven't tried, but I don't think we do the right thing when we're invoked with the -mthread flag. Alexandre, what extensions (if any) we need to gcc to be able to support Windows programs that use the -mthread flag?

Alexandre replied and felt the first issue shouldn't be hard to support. As far as the -mthread option goes, he thought maybe it could be ignored.


Solaris x86 Status 05/05/2003 Archive
Ports

In the you're-the-one-who-uses-that-OS category, Peter Lees wanted to know the status of Wine on Solaris x86:

what is the status of WINE development for solaris x86?

i'm running into some fairly fundamental build bugs & would like to know if anyone has got it working.

Robert Lunnon reported working on it recently and gave some pointers:

Wine can be made to work on Solaris X86 with a few patches. To compile you will need the patch kit and a copy of gcc that uses gas rather than AS. the Solaris assembler expect intel assembly while gas expects AT&T.

I sent diffs last week but I don't know how long it will take for them to reach cvs or if they will ever get there.

Alexandre reported that some of the patches were applied but other parts needed to be cleaned up before he would commit them.


Broken flex 05/01/2003 Archive
Build Process

I meant to put this one in last week, but it slipped through the cracks. Someone had a problem compiling Wine out of CVS and posted some info on their tools and the error generated:

  • Debian Sid x86
  • kernel: 2.4.20
  • flex version: 2.5.31-4
  • bison: 1.875a-1
  • gcc: 3.2.3
  • binutils: 2.13.90.0.18-1

    gcc -c -I. -I. -I../../include -I../../include -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o lex.yy.o lex.yy.c
    ./ppl.l:97:1: warning: "/*" within comment
    ./ppl.l: In function `pplex':
    ./ppl.l:309: `pp_incl_state' undeclared (first use in this function)
    ./ppl.l:309: (Each undeclared identifier is reported only once
    ./ppl.l:309: for each function it appears in.)
    ./ppl.l:309: `pp_pp' undeclared (first use in this function)
    [....] /usr/include/stdlib.h: At top level:
    lex.yy.c:15493: warning: `yyunput' defined but not used
    make[2]: *** [lex.yy.o] Error 1
    make[2]: Leaving directory `/root/cvs/wine/libs/wpp'

A few minutes later Rein Klazes responded with the solution, Flex 2.5.31 bug. Downgrade to 2.5.3a, "make clean" in the tools directory and you are back.


Building a Windows API Database 05/02/2003 Archive
Utilities

Back in issue #156 we discussed building a table or database of how Windows DLLs are interrelated. By running a perl utility you can scan a Windows installation to locate DLLs and dump API imports and exports using winedump. Dave Miller wrote in to announce more work he'd done on this tool:

The script which dumps dll imports and exports now seems to parse everything correctly and organize it nicely in a text file. We need the script run against various windows versions. The output can be sent directly to me, but please verify I do not already have the data for that particular version of windows. I don't need 10 copies of win2k SP3 for example. :)

The script is available at http://home.ptd.net/~compsol . Please make sure you get createdb.pl. There is another script, createwinedb.pl which will ONLY parse the wine spec files.

To run this you will need winedump, perl, and access to your windows directory from within Linux. The cleaner the windows install the better. We don't want to clutter the database with info from dlls not provided with windows. Usage is as follows:

    createdb.pl -d -p <path to windows dir> -o <winver> (ex. win98)

This will save the imports and exports and also create winver.ref, where winver is specified on the command line with -o. The .ref file is the one which will contain all the info we need. This will be a large file, so I recommend compressing with gzip if you are going to email it to me. It may be large enough to bounce back into your mailbox if you do not. :)

The resulting filename was discussed and everyone decided the output should be named something like <name>-<version>-<service-pack>.ref, such as wine98-4.00.123-SP6a.ref


WinZip Registry Patch 05/04/2003 Archive
Fixes

Nick Brereton announced a small patch to help Winzip work better:

Attachment is a windows registry file.

Integration of this file directs WinZip to not use the Rich Edit control when displaying comments in Zip files by changing a flag that WinZip read from the registry. This means that it will work with all zip files rather than crashing out on zip files with comments.

Should I post this anywhere else? eg the wine-patch list? Any comments would be appreciated.

Dimi liked the idea and suggested submitting a patch against the default Wine registry. Sylvain Petreolle felt more should be done, Im not against this patch, but this is hiding a problem and not resolving it. We should make sure a bug is open about this or add comments into richedit/winedefault.reg.


All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.