WWN Issue 173

This is the 173rd release of the Wine's kernel cousin publication. Its 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).

This week, 182 posts consumed 631 K. There were 68 different contributors. 35 (51%) posted more than once. 27 (39%) posted last week too.

The top 5 posters of the week were:

17 posts in 53K by Mike Hearn
11 posts in 26K by Dimitrie O. Paun
10 posts in 24K by Eric Pouech
9 posts in 22K by Shachar Shemesh
8 posts in 19K by Sylvain Petreolle

RedHat 9 RPM's Available	06/01/2003	Archive
Project Management 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 .

RedHat 9 RPM's Available

06/01/2003

Archive

Project Management

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 .

ReactOS Regedit Merge	06/05/2003	Archive
Utilities 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.

ReactOS Regedit Merge

06/05/2003

Archive

Utilities

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.

WinINet Work 06/02/2003 Archive

WinINet Work	06/02/2003	Archive
Patches 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 SSL` Which 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.

Patches

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 SSL

Which 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.

Adding a Root Drive Mapping	06/03/2003	Archive
Filesystems Configuration 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 don't 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 consensus on a solution and will probably rely on Alexandre to make the decision.

Adding a Root Drive Mapping

06/03/2003

Archive

Filesystems Configuration

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 don't 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 consensus on a solution and will probably rely on Alexandre to make the decision.

CVS Commits	06/05/2003	Archive
Project Management 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.

CVS Commits

06/05/2003

Archive

Project Management

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.

World Wine News