Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #133 For 29 Aug 2002

By Brian Vincent

Table Of Contents

Introduction

This is the 133rd 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).

Mailing List Stats For This Week

We looked at 108 posts in 313K.

There were 42 different contributors. 24 posted more than once. 22 posted last week too.

The top posters of the week were:

1. News: LinuxWorld 'Best Desktop Office Solution'

24 Aug 2002 - 29 Aug 2002 (1 post) Archive Link: "News"

Topics: News

People: CodeWeavers, , codeweavers, News

Not much in the way of news this week. CodeWeavers won a 'Best Desktop Office Solution' at LinuxWorld for their CrossOver Office product. Press release posted on their web site.

2. Using Intel's Compiler

25 Aug 2002 (5 posts) Archive Link: "Problems compiling wine with Intel Compiler"

Topics: Build Process

People: Unknown, Patrik Stridvall, Marcus Meissner, Joerg Mayer, , Patrik Stridval

Someone posted a question about using Intel's compiler:

I'm getting compiler errors when I try to compile wine with the Intel C++ 6.0 Compiler. This works fine with the g++ compiler.

It looks like the wine headers need a level of the gcc version for the compiler, but since I'm not using gcc, there is no gcc version level set. Has anyone built wine with the Intel Compiler? If so, what was done to get this to work?

Is any work being done to allow the usage of the Intel compiler with wine?

Patrik Stridvall suggested:

The Intel compiler like the Microsoft compiler probably already supports __int{8,16,32,64}.

The typedef are protected by a

This will have to be changed to

where XXX is some that indicate that the Intel compiler is used. Check the manual.

Presumably the Intel compiler like the Microsoft compiler already defined __cdecl and __stdcall. In that case similar to first problem above the line

will have to be change to

where XXX is the same as above.

Joerg Mayer suggested just building a check into autoconf and letting it figure it out. However, Patrik pointed out, " In the header files it can't be done that way because the same header files must support multiple compilers and thus they can't have a shared config.h file."

And then Marcus Meissner asked, " Does the icc have a stdcall calling convention? Otherwise it will get difficult to run Win32 binaries."

3. PPC / MacOS X Support

25 Aug 2002 - 28 Aug 2002 (11 posts) Archive Link: "Wine Ma os X port"

Topics: Ports

People: David Suarez, Lionel Ulmer, Marcus Meissner, James Hatheway, , Gavriel State, Andriy Palamarchuk

David Suarez wondered about a MacOS X port, " Im kinda new to Wine, and I hope to get into very much, however I had one question which im sure everyone has heard alot of. Is there any way to run WINE on mac OS X being that it is based on FreeBSD. I have played around with the mac's and have gotten several linux programs to run, however i haven't tried wine yet. I do no that os X comes with many development tools that could possible be used for porting an app, but then again i am new at this so im not sure. Any information on this would be greatly appreciated. "

Lionel Ulmer figured there was at least some hope since the PowerPC architecture was being worked on:

Winelib already works on PPC (or at least Marcus is trying to get it to work). That is already a first step :-) After, there are a lot of tricky stuff to do, but no big rewrite (well, except in the core DLLs like Kernel and the server).

I wonder if anybody ever started a 'bug' or 'task' on Bugzilla to write down everything that would be needed to support Wine + emulation.

Marcus Meissner followed that up with an explanation:

There is just 1 open patch (the powerpc signal handling), which alexandre needs to apply and then you have winemine, notepad and some other sample winelib apps running on PPC.

The ABI is incompatible due to a r13 mess up in the ELF ABI, but this does not matter for sourcecode ported apps.

The discussion delved into hooking up a CPU emulator into Wine. Lionel Ulmer mentioned running Linux inside a Bochs emulator and then running Wine inside that. He also pointed out that Windows itself could be run instead.

Andriy Palamarchuk suggested looking at bug #44 in Bugzilla. This same question came up a few years ago. At the time James Hatheway posted a list of issues that might come up. At the time Gavriel State had taken a shot at porting Wine but hadn't finished.

4. Microsoft Docs From DoJ Settlement

27 Aug 2002 (5 posts) Archive Link: "New win api docs"

Topics: Microsoft Windows

People: Dmitry Timoshkov, Andreas Mohr, , Michael Stefaniuc

Part of Microsoft's settlement with the DoJ involved publishing documentation on "Microsoft Middleware", API's used by Microsoft in their own applications. Supposedly this will open the platform for other software developers. A lengthier discussion of the events is available from The Register. It seems Microsoft went ahead and "complied" by releasing documentation that is incomplete, outdated, and already known. Michael Stefaniuc posted a link to the new documentation. Dmitry Timoshkov noted:

And nothing regarding undocumented comctl32 interfaces...

Almost all disclosed APIs are already known or useless.

Andreas Mohr was surprised they published anything at all.

5. MP3 Decoder Licensing

28 Aug 2002 (5 posts) Archive Link: "removing mp3 code"

Topics: Multimedia, Licensing

People: Marcus Meissner, Patrik Stridvall, , Patrik Stridval, Michael Stefaniuc

Last week news supposedly broke that the developers of MP3 software, both encoders and decoders, are required to pay royalties. The patented MP3 format has been a source of licensing problems for years so no one was probably surprised to see that Thomson MultiMedia had a page about licensing. Marcus Meissner wondered about the decoder in Wine:

Apparently distributing even mp3 decoders is not royaltee free anymore, according to the slashdot thread and the Thomson MultiMedia pages.

So we probably should remove the msacm mp3 decoder we include. :(

However, Michael Stefaniuc posted link to a Heise article (Google translation) that had a statement from Thomson that basically this isn't news and free docoders are still free.

Patrik Stridvall wondered why Wine bothered with an MP3 decoder at all:

At the very least we should make it compile option that is by default disabled.

I don't think we need to go that far as to remove it. IIRC LAME an mp3 ENCODER (that was non royalty free even before) got around it by only distributing source code and so can we.

BTW: Why do we include a mp3 decoder in the Wine tree? Why not just link to an external library? I can't see maintaining a mp3 decoder being in the best intrest of Wine anyway patents or not...

6. Case Sensitivity and Filesystems

27 Aug 2002 - 28 Aug 2002 (7 posts) Archive Link: "DOSFS_FindUnixName and unix filesystem (was: Re: (HELP) ...)"

Topics: Filesystems

People: Martin Wilck, Andreas Mohr, Alexandre Julliard, , Eric Pouech

This thread goes back to June. Martin Wilck posted a message describing a problem running tests:

What am I doing wrong? I have tried this and that, but I don't seem to be able to run the tests. This happens for any tests I try. It seems that wine isn't looking for "tests/kernel32_test.exe.so" below the current directory.

No one else really seemed to be having the same problem. Eric Pouech reported everything was working for him.

Martin finally figured out his problem was with the way filenames were being matched:

I have finally figured this out. It has to do with some (intentional?) DOSFS_FindUnixName() weirdness.

My wine sources are in a directory /home/martin/Software/Wine/CVS/wine. /home/martin is my Windows drive Y:

Now in /home/martin/Software, I have subdirectories "Wine" and "wine". DOSFS_FindUnixName() uses "wine" because

  1. DOSFS_ReadDir returns it first,
  2. The DOS short names match (the Unix names obviously don't).

Since "wine" is the wrong path, the search fails shortly after. This happens even if I set the Filesystem type of drive Y: to "unix".

I guess this is the right thing to do on Windows-style file systems, but should it be this way on a "unix" file system, too?

The patch below does what I'd consider "sane" behaviour on Unix. Alternatively, on a "unix" filesystem, one could search the whole directory for exact matches, and try short names only if that fails.

Andreas Mohr thought it seemed to make sense:

Well, if your patch makes sure that on a "unix" mapping (as opposed to "win95" !) we only lookup the *exact* case sensitive name instead of iterating through all sorts of case cases (heh ! :), then I guess your patch is right.

I guess nobody really cared about having correct behaviour of the "unix" mapping mode. (since everybody should use "win95" for normal use anyway)

Alexandre thought there was no perfect solution, " I'd say that DOSFS_ToDosFCBFormat should fail when the file contains upper-case chars on a case-sensitive file system. This will probably make it impossible to access some files in certain cases though. I'm afraid it's not possible to support case-sensitive file systems 100% right given that Windows apps don't preserve case correctly."

Martin also thought when it was Unix filesystem that a possible DOS filename should be looked for if no Unix ones match. He supplied a patch, but it didn't (as of yet) get applied by Alexandre.

 

 

 

 

 

 

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.