This is the 104th 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).
We saw a report come out this week that Wine has succeeded in replicating even more Windows functionality - namely the ability to run viruses. The Sir Cam virus running under Wine is pretty innocuous though as a vnunet.com article points out. This does bring up an interesting point though. Wine has always strived for "bug for bug" compatibility and viruses are part of that legacy. But keep in mind that a Wine process running as a non-root user will have a neglible impact. By the way, does anyone else find it strange that the press always uses the term "computer virus" when they mean "Windows virus"?
Aric Stewart submitted a patch that fixed a function (wsprintfA)
that was slightly different than its cousin (wsprintf16). Andreas
Mohr asked,
Hmm, can't you add a small comment inside the code that actually
mentions this remarkable difference ?
I think we should make every effort possible to ensure that important
differences between architectures are being preserved as well as possible.
As Bill Medland describes it, Alexandre likes to keep the code "tidy". And this is not the first time this issue has come up. Alexandre did end up adding a comment noting the differences, but Jeremy White felt it was important to address more general cases:
Okay, so it's a slow news day, and I feel like stirring up trouble.
I would argue that it is, in fact, counterintuitive, to have this sort of comment solely in the change log. The only time I ever think to look at a diff (or even the change log) is when something has broken recently.
IMO, it is appropriate to comment in the code, whenever something useful about Wine/Windows behavior is learned, especially when the knowledge is something non intuitive like the fact that the 16 bit version and 32 bit version behave differently.
Bill Medland replied,
The change log and cvs diff should explain why a change was made (and in an
ideal world should refer to the supporting documentation e.g. bug numbers
etc.). In this particular case it should mention, as it does, that the
difference has been detected.
Alexandre noted:
Well, because *you* don't look at it doesn't mean it's not the right place, does it? <g> I look at the CVS history quite often, and I find that in many cases it's the best way to find out why things are done a certain way.
I don't see any reason to duplicate this info inside the code itself; since we are using a source control system we might as well take advantage of it. Plus it guarantees the info is stored permanently, unlike a comment that may get moved or lost next time the code is changed.
I'd like to add that browsing the CVS repository on the web can be a great way to see changes to code. For instance, in this case here's the diff between the changes Aric made and the previous version: http://cvs.winehq.com/cvsweb/wine/dlls/user/wsprintf.c.diff?r1=1.5&r2=1.6. Also what stands out is the CVS tag leading to it. While it's not always the quickest way to see revisions it does tend to make the differences jump out. You can even get good ol' unidiffs from it.
The latest InstallShield-based installers have been an on-going nightmare. People have suggested writing everything from basic interprocess communication to a full blown COM implementation. Ove Kåven has stepped up and worked on this and his latest report asks for help debugging:
Here are some kludgy patches (against the current WineHQ CVS) that's supposed to make InstallShield 6 with its stupid interprocess COM sort of work, but it doesn't for some reason, probably because of something else in Wine that's broken... and because of a lack of time, I think I really need some debugging assistance.
Most of these patches are too ugly to be submitted to the official wine as-is, I'll clean these parts up later, but probably not before InstallShield has been debugged and actually works with these hacks.
To make this run, you need to copy stdole32.tlb from a real windows and put into c:\windows\system. Then run your favorite InstallShield 6 setup.exe and wait for it to crash. --debugmsg +ole is recommended. It crashes for me after about 25 remote method calls. If you find out why, let me know. Please.
Click on the subject link above to get to the patch.
Nick Hudson asked,
Well i know ill get flamed for this but has anyone got IE 5.01
installed on wine? Everytime I try it gives me an error that "Some
programs hasnt finished and that I need to let it finish and restart
my computer" Then it closes. So any ideo on getting any version of
IE installed?
Uwe Bonnes suggested,
Delete the files mentioned in the wininit.ini file (in the windows
directory) and then remove wininit.ini.