This is the 173rd release of the Wine's kernel cousin publication. It's main goal is to be as short and concise as possible so I can enjoy my vacation. It also serves inform you of what's going on around Wine (the Un*x windows emulator).
Mike Hearn wanted to know the status of RedHat 9 RPM's,
Can somebody please remind me what the plan for these are? In IRC we
seem to say "go to newrpms.sunsite.dk" all day, every day. It's really
poor IMHO that after all these months, the site STILL does not mention
this.
Vincent Beron, the RedHat RPM maintainer, wrote back:
I've built some and put them on sf (without announcing them, me bad). If our download page doesn't mention them, it probably doesn't mention Mandrake either, which is available as well (can't recall if it's for a specific version of Mandrake).
The differences between the newrpms and sf ones' should be minimal, as I studied both spec files before deciding some features for RH9.
If you're interested in grabbing them, check out the SourceForge repository.
Mike McCormack posted a large patch and announced,
This
is a merge of the reactos regedit GUI implementation. I've only
provide a tarball, as there's lots of new files, however I've tried to
keep the diff on existing files as small as possible.
Steven Edwards provided some more details about the code:
A few notes on this merge. ATM the GUI functions are read-only except importing and exporting a file. You cannot modify the registry from the GUI. All of the command-line options still work thanks to Mikes fixes and there are still a few other minor things like the resource files need to be cleaned a little bit. If you see fit to go ahead and test/merge then I will cleanup the resource files when I get back in town next week. If not let us know any other things that need to be fixed before we can merge.
Alexandre hasn't merged the patch into the tree yet.
TransGaming did some work on the WinINet library and made the code available under LGPL. Mike McCormack posted a large patch porting functions to WineHQ's tree. Mike Hearn reported a problem:
Well, I'm spending my fun afternoon trying to get IE to install in Wine (it breaks in a new and interesting way every time I try this).
Before the patch, it didn't work, couldn't contact download sites. After the patch, it still doesn't work, and I get this fixme:
fixme:wininet:InternetReadFile This shouldn't be here! We don't support this kind of connection anymore. Must use NETCON functions, especially if using SSLWhich seems a bit of a bummer, if IE6 setup needs that type of connection I think we should still support it really......
David Hammerton, the original author of the code, explained a little bit about it and what might have caused the problem:
This would be related to the open-ssl thing I did...
Basically rather than rewriting a bunch of wininet code, I wrote a layer around the winsock stuff so that it can easily switch between ssl and non-ssl sockets..
Mike McCormack - is it possible this file (internet.c) didn't get merged properly?
Mike Hearn - check out the function 'InternetReadFile' at this URL and compare against your post-patched winehq version. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/wininet/internet.c?rev=1.3&content-type=text/vnd.viewcvs-markup
ok, so I checked out winehq cvs and applied the patch.. Mike McCormack - it looks like you merged the contents of InternetWriteFile into both InternetWriteFile and InternetReadFile.. I may be wrong (I just woke up)..
The FIXME in InternetWriteFile has no bad effect, things will still work (so long as you're not using HTTPS) - but in InternetReadFile, I have my doubts.
Robert Shearman then jumped in to mention he was doing some WinINet work
too,
Just thought I'd let people know (while we're on the WinInet topic) that I'm
working on the UrlCache functions there, leading to implementing the UrlMon
functions properly.
Mike Hearn submitted a patch that added a drive mapping for the
root directory. Mike's reasoning was,
The theory being that it'll reduce instances of people on IRC saying "It
says it can't find the program, but it's right there!"
Sylvain Petreolle objected first:
please dont add / to the default config. Some reasons no to do that:
- its insecure, since you can write everywhere you want and some filesystem corruption still exist today.
- it will cause recursion/drive change problems > example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:\
Mike hadn't run into any problems with the second point
and guessed the algorithm was able to deal with that. He also
didn't think it would be much of a security concern to map root.
Marcus Meissner was cautious, but also thought it would be okay,
I don't really see a problem, except a virus might go and scan
the whole UNIX system including NFS trees. But the risk is low, and benefits
are greater.
Dimi Paun also voiced his opinion of it,
Even though I know about the problem, I find it incredibly annoying and
stupid when Wine complains about that. I think we absolutely need the
Z drive for the 0.9 release, we might as well add it now.
Then the idea was proposed to just give Wine read-only access.
Lionel Ulmer pointed out another flaw with mapping root,
if they users get this error, it means that they did not configure
Wine properly... So that we are only hiding the problem anyway.
Thus far there doesn't seem to be a concensus on a solution and will probably rely on Alexandre to make the decision.
Alexandre has been on vacation for the past week and several
passed between CVS commits. Then on Wednesday he resurfaced and
made 55 CVS commits affecting 170 files. Johan Gill noticed and
commented,
It seems Alexandre is back or just got tired of the patch storm :) D3D-lovers
should update from CVS I'd say.
Raphael Junqueira commented on it too:
yes, I have seen this "d3d commit fury" in realtime :)
Alexandre, you have done a very impressive job :)
But you returned too early as we haven't sent all our patches (i was too bored to do the cleaning stuff last week).
But we'll thanks all D3D-lovers that can report games ok, or with graphics problems.
It's nice to see activity with Direct3D again. Years ago Wine was really useful for running games and lot of development focused on getting things like HalfLife and StarCraft to run. It brought a lot of new users to the Wine community and gave developers new and exciting ways to waste time. When TransGaming started commercial development of DirectX very little work was done with the WineHQ tree. Eventually developers got tired of waiting for the work to be submitted back to WineHQ and work began on duplicating TransGaming's efforts. An impressive amount of work has been done over the last few months and it's really beginning to pay off. Sylvain Petreolle reported a new success story:
Thanks to the D3D/ddraw workers, the last storm of patches makes Tomb Raider 3 able to start.
You must set ZBuffer to on to get all graphics, and we run into gray levels at the moment. Great Work guys.
PS : I submitted the app to AppDB.