All the news that fits, we print.
This is the 104th release of the Wine's kernel cousin publication. Its 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"?
|
This week, 63 posts consumed 238 K. There were 33 different contributors. 13 (39%) posted more than once. 24 (72%) posted last week too. The top 5 posters of the week were:
|
| To Document.. Or Not To Document | 09/20/2001 | Archive |
|---|---|---|
|
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.org/cvsweb/wine/dlls/user/wsprintf.c . 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. | ||
| InstallShield 6 | 09/24/2001 | Archive |
|---|---|---|
|
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. | ||
| Installing IE 5.01 | 09/14/2001 | Archive |
|---|---|---|
|
Nick Hudson asked, Well i know i'll get flamed for this but has anyone got IE 5.01 installed on wine? Everytime I try it gives me an error that "Some program hasn't finished and that I need to let it finish and restart my computer" Then it closes. So any idea 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. | ||
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.
