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).
Thomas Wickline spent some time recently updating the Wine 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.
Back in June there was a thread
Sean Young has done some work and posted the following message:
I've written a .wri to RTF converter, which is available here:
http://www.msxnet.org/word2rtf/write.c
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.
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.
Jeremy Newman put out a call to update some of the info on WineHQ:
It's time to update the Wine Who's 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.
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 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()
if(length > 126) {
ERR("Command line truncated! (length %d > maximum length 126)\n", length;
length = 126;
}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
cmd = dos_cmdline(); env_cmd = getenv("_"); if (strncmp(cmd, env_cmd, strlen(env_cmd)) == 0) cmd = env_cmd; main(cmd);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
LPBYTE cmdline = PTR_REAL_TO_LIN(SELECTOROF(blk->cmdline),OFFSETOF(blk->cmdline));(this is currently ignored by MZ_Exec, which is a bug, it should really be passed to MZ_DoLoadImage and be used as "oldenv")
LPBYTE envblock = PTR_REAL_TO_LIN(blk->envseg,0);or, if desired, you can grab the current environment block from the current PSP (which is currently what MZ_DoLoadImage does) with
PDB16 *psp = psp_start;
LPBYTE envblock = PTR_REAL_TO_LIN(psp->environment,0);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.)
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'.
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'.