Wine Traffic #137 For 26�Sep�2002

By Brian Vincent

Table Of Contents

Introduction

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

There were 61 different contributors. 31 posted more than once. 24 posted last week too.

The top posters of the week were:

1. News: Wine Status Update

20�Sep�2002�-�26�Sep�2002 (1 post) Archive Link: "News"

Topics: News

People: ,�News,�Thomas Wickline

Thomas Wickline spent some time recently updating the Wine Status (http://www.winehq.com/about/index.php?status) page. Previous to this, it had been about a year since it had been updated. It's nice to see green overtaking red. Look for more updates soon, there's still a lot of things on the page that need correcting.

2. MS Write Support (con't)

19�Sep�2002�-�20�Sep�2002 (3 posts) Archive Link: "notepad vs write"

Topics: Fixes

People: Sean Young,�Jason Edmeades,�

Back in June there was a thread Issue�#127, Section�#4� (15�Jun�2002:�MS Write Support) about supporting RTF documents and MS Write. Jason Edmeades had an application that expected to find Write in order to view a document. The current built-in notepad with Wine does not handle RTF documents. Dmitry Timshokov suggested having notepad support RTF documents by feeding them to a RichEdit control and then have write be a symlink to notepad.

Sean Young has done some work and posted the following message:

I've written a .wri to RTF converter, which is available here:

It should be almost complete. The output is almost the same as the microsoft converter (including bugs, if desired).

Now I have enough information to write write32.cnv, but is there any need for this?

The initial license was under GPL, but Sean relicensed it as LGPL and added a note in Bugzilla on where to find the code.

3. Proposal for Developer CVS Tree

24�Sep�2002�-�25�Sep�2002 (14 posts) Archive Link: "[Controversial] Developper only CVS sandbox"

Topics: Project Management

People: Lionel Ulmer,�Alexandre Julliard,�,�Patrik Stridvall

Lately there's been some patches coming through reorganizing and cleaning up parts of Wine. Some are common sense, others are more controversial. Not to feel left out, Lionel Ulmer wanted to get feedback for an idea:

As Dimi is not the only one that can start flames on wine-devel, let's start a new one :-)

When I see the work that is starting to go on on D3D8 or even on my old D3D code, I think that it would be nice if there was some CVS 'sandbox' where Wine developper could interact on shared code without going the Alexandre round-trip. This would be much less painful than sending patches back and forth between developpers.

This sandbox would be closed (ie it would be a developper only Wine tree) to NOT start another Wine fork and all development on this sandbox would be merged back in Wine when they are ready (and then would still go the Alexandre way of course).

Now, what does the Wine community think about this ? If people agree, what would be the best way to handle this ?

Patrik Stridvall thought he should just do it and then tell everyone where the CVS tree was. But Lionel said he didn't have enough bandwidth to support it himself. He didn't want to use SourceForge because he wouldn't be able to restrict access to it (Lionel didn't want people who weren't developers poking around and complaining it was broke.) Not to mention the fact he hates CVS. Dimi Paun liked the idea of Alexandre just being able to pull things from a different CVS tree to do commits. And as far as Alexandre was concerned, he didn't object to the idea but wasn't sure it would be useful:

Well, I don't think it would make much difference for me, so I don't really care either way (as long as you don't start sending me URLs instead of patches...)

I'm not convinced that it would really help all that much though; CVS is not good at managing parallel lines of development, and the extra work needed to maintain that tree probably offsets the gains in sharing patches. In fact it's probably easier for developers who need to share code to each maintain a local CVS tree on their machine and use that to generate incremental diffs. At least this way there's no need to setup a server, manage user accounts, etc.

Of course the real solution would be to switch to a source control system with better support for parallel branches of development. Now *that* should be a good flamewar topic <g>

We'll see if anyone volunteers to set this up and maintain it.

4. Updating Developer Info

19�Sep�2002 (1 post) Archive Link: "Call to update the 'Who's Who' page"

Topics: Documentation

People: Jeremy Newman,�

Jeremy Newman put out a call to update some of the info on WineHQ (http://www.winehq.com) :

It's time to update the Wine Who's Who (http://www.winehq.com/about/index.php?who) page.

I need all current developers to send me their info for this page. It is optional to be listed here of course. If you are on the list now and do not wish be be listed let me know. I'll also take anyone's suggestions on how to improve this page.

Optional info I'd like from everyone.

Your name, e-mail, home page url, location, role, and bio.

5. CreateProcessA() and Environment Settings

23�Sep�2002�-�24�Sep�2002 (14 posts) Archive Link: "another MZ_Exec() problem..."

Topics: Fixes

People: Chris Morgan,�Ove Kaaven,�Francois Gouget,�,�Ove K�ven,�Eric Pouech

Chris Morgan was having some problems with one DOS app spawning another. The first problem was just getting MZ_Exec() to run a PE executable. So he posted (http://www.winehq.com/hypermail/wine-devel/2002/09/0495.html) a small patch to check if program being called is PE, and if so to call CreateProcess to handle it. But, Chris needed to pass some info around and first thought he could do it through the commandline. He seemed to run into a problem and wondered why:

I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP()

is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126? Afaict having more than 126 characters may exceed some command.com default. Can someone shed more light on the historical reasons behind this code and whether more intelligent truncation can be performed?

Ove K�ven gave the reason for the boundary:

Yes, it's an intrinsic DOS limitation from the early DOS days. The PSP is a fixed-length structure of 256 bytes, half of which is reserved for the command line; the layout of it is the same as the PDB16 structure (which is the Win16 version of the PSP) in include/task.h. There's no way to fit a longer command line into it; even trying to make the PSP larger won't help for long since the first byte is the command-line length, so it can't be made longer than 255 characters this way anyway. So apps that need unlimited command lines must use a different protocol to pass them. One way could be to use environment variables - for example, I've noticed before that NT's cmd.exe puts the last command line in the "_" environment variable when invoking apps, so I can imagine that apps that take advantage of this look something like

This is only a guess, though, I don't know to what extent something like this is supported by DOS or Windows itself, nor what protocol they really use.

Francois added, " Note that this limitation should only be in effect when calling Dos applications. Win32 console applications can receive command lines of up to 32KB on NT and any size on Win9x. So maybe the problem is that you are using command.com as the COMSPEC. Does this happen with wcmd.exe (or the native cmd.exe)?"

Chris wasn't using command.com, but seemed to be using something similar. Next, Chris thought he'd use environment variables, " Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. "

Eric Pouech mentioned it was currently broken, Ove K@aring;ven explained:

In the same fashion that MZ_Exec() extract the command line from the PSP with

you can get the environment block from the EXEC parameter block with (this is currently ignored by MZ_Exec, which is a bug, it should really be passed to MZ_DoLoadImage and be used as "oldenv")

or, if desired, you can grab the current environment block from the current PSP (which is currently what MZ_DoLoadImage does) with

The format of the environment block should be the same as that returned by GetEnvironmentStringsA(), so you can probably pass this pointer straight to CreateProcessA(). (Letting CreateProcessA() just inherit from its idea of the parent process doesn't work since its idea of the parent would be the Wine process that runs the DOS VM, not the DOS app currently running inside.)

6. Programming with Wine and COM

22�Sep�2002�-�24�Sep�2002 (5 posts) Archive Link: "how to declare COM class?"

Topics: Winelib

People: Yong Chi,�Lionel Ulmer,�Francois Gouget,�J�rgen Schmied,�

Yong Chi asked:

Hello! I am one of those lurkers who finally decide to write code after many attempts.

I declared a COM class best I can from looking at other COM class but I am getting syntax errors. I could not find any guide/manual on COM development.

Can someone help or point to a guide on COM development?

It was unclear whether he meant COM in general or specifically how Wine implements the interfaces. For general COM programming, Lionel Ulmer suggested a Microsoft resource, " the nicest introduction I found about it is this URL ' http://www.microsoft.com/Com/news/drgui.asp (http://www.microsoft.com/Com/news/drgui.asp) '."

J�rgen Schmied pointed out that Wine implements COM objects in pure C, so a guide might not be too helpful. However, the URL Lionel gave does talk about that, he explained, " in the Dr GUI URL I sent yesterday, there are some examples of C COM objects (and a link to Inside OLE where there is some actual C code for a COM object). As for 'Inside OLE' one can find it in .PS form on the web using Google :-)"

Francois Gouget said the best Wine-related resource was to simply " read the comments in ' include/wine/obj_base.h (http://cvs.winehq.com/cvsweb/wine/include/wine/obj_base.h?rev=1.47&content-type=text/x-cvsweb-markup) '. "

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.