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 #139 For 10 Oct 2002

By Brian Vincent

Table Of Contents

Introduction

This is the 139th 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 137 posts in 556K.

There were 44 different contributors. 23 posted more than once. 22 posted last week too.

The top posters of the week were:

1. News: Wine-20021007, TransGaming Update, Frank's Corner

4 Oct 2002 - 10 Oct 2002 Subject: "News"

Topics: News

People: Alexandre JulliardTransGamingMartin WilckFrancois GougetNewsThomas Wickline

Alexandre announced Wine-20021007 on Monday:

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

The listview rewrite is ongoing, fifteen more have been committed since Wine-20021007 was tagged. Dimi Paun has sent a flurry of patches over the past few weeks. The fact that he organized them in a logical manner and separated out the changes no doubt helped get them committed. The winemaker work by Francois Gouget and Martin Wilck was aimed at restoring functionality broken by new naming conventions and other changes. The RLE video codec was a last minute addition - the patch appeared Monday courtesy of Michael Günnewig.

The status page on WineHQ had more work done. I took some time and referenced WWN coverage for each of the items. Digging through 130+ issues took some time, so the list is by no means complete, but for most things it should be a good primer. Thomas Wickline updated the "To Do" part of the page. The list is not necessarily 1.0 specific.

TransGaming released WineX 2.2 on Tuesday. This was based off the same codebase as 2.1. Changes include:

TransGaming also posted a development status outlining progress they've made and their future plans. TransGaming's development is partly driven by subscribers who vote each for the work they'd like to see done. The EverQuest work is an example. The top ranked poll items from September requested improvements on Direct3D, sound support, and InstallShield support.

It looks like Frank's World has now moved to Frank's Corner. Along with it there's all kinds of new stuff. Check out:

2. Jack Audio Driver

7 Oct 2002 (1 post) Archive Link: "Re: jack audio driver"

Topics: Multimedia

People: Chris MorganEric Pouech

Chris Morgan asked Eric Pouech about a new audio driver:

I have an audio driver for the jack audio server, http://jackit.sourceforge.net. This is a callback based server, so each time the server needs audio data it executes a client callback function. I was wondering if there was any interest in having this driver as part of mainline wine code as an example of how to write a wine audio driver for a callback based architecture.

Eric replied:

well, it depends what you look at jack way well be the standardized API for audio application interoperability on Linux but, some folks may argue that arts may well become the same as of today, I don't like the number of sound drivers that we already have (OSS, alsa, arts, nas) just for linux it, of course, reflects the mess in low level audio interface in linux what I really fear is the real maintenance of those drivers as of today, OSS is maintained, I cannot really tell the same for the others it's never a bad idea to share code, but I fear we're not going to be able to maintain all the drivers (but we don't maintain them all today anyway) so go for it (sorry for thinking while writing ;-)

No code appeared on wine-patches nor did Alexandre commit it directly.

3. Creating Test Framework for New DLL

5 Oct 2002 - 6 Oct 2002 (3 posts) Archive Link: "How to add a new test dir?"

Topics: Testing

People: Greg TurnerOve Kaaven

Greg Turner has been busy porting and fixing up Ove Kaaven's RPC code. After submitting a few patches Greg decided to tackle creating some tests. He detailed what he did to get the framework in place for the new rpcrt4 DLL and it's probably a good intro for another new DLL:

I'm trying to create a tests directory for rpcrt4. So far I've done the following:

But that wasn't enough and Greg couldn't figure out what he was missing. However, since it was the weekend the list traffic was pretty slow and no one responded. Greg kept at it and discovered the problem a few hours later - a line needed in configure.ac for autoconf:

He then submitted a patch for the new framework with some actual tests.

4. Languages & Locales

6 Oct 2002 - 7 Oct 2002 (6 posts) Archive Link: "Languages/Locales"

Topics: Internationalization

People: Steve LustbaderAlexandre JulliardUnknownShachar Shemesh

Steve Lustbader posted a patch to implement GetUserDefaultUILanguage and GetSytemDefaultUILanguage but wasn't sure of the details of using them:

I implemented these functions in codepage.c since similar functions (GetDefaultLangID and GetDefaultLCID) were already there. Why are these functions in this file, instead of in dlls/kernel/locale.c?

It seems locales and languages aren't really implemented yet (just hardcoded to English) - is this going in for 1.0 or is it not planned for the immediate future?

As to the first question, Alexandre said the functions were needed by ntdll, so for now they live in codepage.c. Eventually that will be changed. As for the implementation, Alexandre pointed out a lot of it has been done and lives in " dlls/kernel/locale.c and ole/ole2nls.c. "

Someone else wondered about how locales work, "I often see Dutch stuff while using Wine (other than Dutch programs of course), so I don't think everything is hardcoded to english." Shachar Shemesh explained:

You see dutch because the english locales in many of our apps are marked as sublanguage "NEUTRAL" instead of "DEFAULT".

This causes a problem when your locale is not matched by any of the resources. Usually, English is picked as a fallback, but since the english resource is incorrectly defined, English is not matched either. As a second fallback, the first resource language is picked, which happens to be Dutch.

I fixed the problem for Notepad a while back ( http://www.winehq.com/hypermail/wine-patches/2002/08/0078.html). I fixed it only for the English locale there (the rest are not that important to my specific problem), but as far as I understand the matter, "DEFAULT" should be used for all lanugagues unless the sublang is important. If I understand correctly, sublang NEUTRAL should only be used when asking to perform a match, never when defining resources.

As an interesting anacdote, when loading resources with LANG_HEBREW, Visual Studio works great. It won't let you define such resources from the GUI, however. I always thought this was because they didn't want to support that language for some strange reason, until I tried loading resources from WINE that had languages only defined in WINE. Visual Studio kept complaining and wouldn't load the resources, despite the fact that the languages were defined as numbers and no symbols were missing.

Now I am confused regarding the reason that Visual Studio won't let me define Hebrew resources. It appears that it is aware of the language, but will not give it a GUI. A deliberate action? Just one more to life's little misteries.

5. User Level Security in Apps

9 Oct 2002 (7 posts) Archive Link: "Re : wine/programs/wcmd wcmdmain.c"

Topics: Integration, Filesystems

People: Alexandre JulliardJoerg MayerGeoff Thorpe

Alexandre committed a patch that allowed CreateProcess to attempt to run a program even if SHGetFileInfo failed. The theory being it would still allow Unix binaries to run if the executable was able to be found. Sylvain Peteolle wondered if that was really a good idea though and though some programs might maliciously gain access to something that couldn't normally be launched. Specifically, Sylvain wondered what would happen if a program had access to ping. Alexandre didn't think it was a big deal though:

There is no way to prevent a Windows application running under Wine from doing everything a Unix application could do. Even if you don't let CreateProcess launch Unix programs the Windows app can always do a straight system call. If you want to avoid inadvertently running /bin/ping you can make sure /bin is not accessible from a DOS drive. But you can't prevent a malicious app from doing it.

Joerg Mayer summarized that as, " This leaves just two options for the paranoid: Don't run untrusted applications - yeah I know that comes as a surprise :-) or run Wine inside UserModeLinux."

Geoff Thorpe thought this was worth having in Wine and suggested another option, " Or run it as a different user? Wine doesn't run a virtual machine, so you can't prevent running code (ie. whether it was loaded by wine or not) from doing anything that the user it's running as could do. Therefore, logically, the only rules that wine-loaded win32 code can't break are the same rules that no other program running as the same user can't break. So the way I see it there's no logical argument for putting restrictive rules into WINE that only make something *potentially* useful more difficult (and a lot less elegant) to do. In fact it could be very useful, especially for people wanting to mix "shell"-like tools which are in some cases native to win32 (eg. "cl.exe" or "somewebserver.exe") or native to unix (eg. "gmake" and "/etc/init.d/w32server/index.html", respectively)."

 

 

 

 

 

 

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.