January 2002 - Wine-Devel - list.winehq.org

Re: DOSFS_ToFCBFormat Bug Fix

by ccrayne＠crayne.org

In <Pine.LNX.4.21.0201142000500.4461-100000(a)mizar.ping.uio.no>, on 01/14/02 at 08:28 PM, Ove Kaaven <ovehk(a)ping.uio.no> said: :Then again, perhaps DOS 7+ really do parse FCBs differently than e.g. DOS :3.x did. As it turns out, DOS 7 does parse FCBs the same way as DOS always has, and wine's implementation is indeed broken, but not in the way which I previously thought. However, before I get into that, thank you Ove, for forcing me into digging deeper into this issue. What actually happens is that most calls to "parse filename" are made with the parse options (al) set to 1, which means to scan off any leading separators, but otherwise to parse the file name as wine currently does. However, the DIR function of command.com wants "*" to be parsed as "*.*", so it formats the FCB name field to all question marks, and calls "parse filename" with the parse options set to 0eh, which means that the parse routine must not fill in defaults for the drive ID, the filename, or the filename extension. Unfortunately, DOSFS_ToDosFCBFormat is not even aware that the parse flags are part of the calling convention. Therefore, the correct fix is to modify DOSFS_ToDosFCBFormat to honor the flags. I am already aware that DOSFS_ToDosFCBFormat is also called by DOSFS_ReadDir, DOSFS_FindUnixName, and INT21_FindFirst, but I would like your thoughts on what other issues I need to consider. -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------

Jan. 15, 2002

Re: DOSFS_ToFCBFormat Bug Fix

by Ove Kaaven

On Mon, 14 Jan 2002, Francois Gouget wrote: > Strange because if I open a 'dos box' in Win95 or NT4, and I type > 'dir *' I get a list of all the files, including those that have an > extension like "autoexec.bat". Quite possible, as I think those DOS boxes may not use the old DOS FCB routines - they probably use the LFN routines, which might quite possibly handle wildcards differently than the original DOS routines did. (Also, I think command.com might parse dir arguments itself before passing them on to int21, and of course NT's cmd.exe does not use int21 at all) Then again, perhaps DOS 7+ really do parse FCBs differently than e.g. DOS 3.x did. The best way to know is probably to test (int21 ah=0x29 should do the trick).

Jan. 14, 2002

How to enable printing ? (doco problem)

by Sylvain Petreolle

Hi, Looking in the documentation, i'm told to add this switch (in wine.conf !! that 's pretty old ) : printer=on, at [wine] section. Wine then says : Line 81: Unrecognized input' printer=on' I have last cvs version (01/14/2002) and the doc output is in documentation/wine-doc/printing.html, generated by 'make documentation'. Could someone help ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

Jan. 14, 2002

Re: DOSFS_ToFCBFormat Bug Fix

by Francois Gouget

On Mon, 14 Jan 2002, Ove Kaaven wrote: > > On Sun, 13 Jan 2002 ccrayne(a)crayne.org wrote: > > > Change Log: > > files/dos_fs.c > > ccrayne(a)crayne.org > > Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead > > of as "*.*" > > This sounds like intended behaviour. Under real DOS, "*" really means > "*.". The user must type "*.*" to get all files. (This is the stuff that > used to confuse DOS users converting to Linux - "*.*" no longer meant all > files...) Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like "autoexec.bat". In fact I would rather say that "*.*" in Dos/Windows is equivalent to "*" in Unix. The reason is that Dos/Windows considers filenames to be split into two independent parts: - the name which was originally restricted to 8 characters - the extension which was originally restricted to 3 characters And note that one always says 8+3, not 8+1+3. So in Dos/Windows "*.*" really means "any name and any extension" which really means 'any complete filename' (i.e. "*" on Unix), rather than Unix's "*.*" which means 'any filename containing a dot'. So the change in DOSFS_ToFCBFormat looks like it is reasonable. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

Jan. 14, 2002

Re: dlls/ntdll/cdrom.c breaks portability

by Francois Gouget

Hi, I sent fixes for these errors yesterday. See an email called "FreeBSD: cdrom.c compilation fixes" in wine-patches. Most of these look like simple typos. I am hoping that you can confirm that: * CDIOPREVENT instead of CDIOCPREVENT (lots of CDIOCxxx everywhere else) * AUDIO_STATUS_IN_PAUSED instead of AUDIO_STATUS_PAUSED * CD_AS_PLAY_AUDIO_COMPLETED instead of CD_AS_PLAY_COMPLETED * and all the others are because the structure being used has a union named 'what' instead of it being nameless. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Jan. 14, 2002

Re: EnumWindows

by Tommy Schultz Lassen

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > >>>>> "Tommy" == Tommy Schultz Lassen <tlassen(a)tlassen.dk> writes: > > Tommy> Why does EnumWindows return FALSE if no windows exists. Should it > Tommy> not return TRUE instead. Her is a patch witch changes it. > > What are your indications that the present behaviour is wrong? > Api-Description or Miss-Behaviour of some application? > With out this patch Pool of Radians Ruins of Myth Drannore stops before it opens a window(on inspection of the trace it looks like it detects Pool of Radians Ruins of Myth Drannore running and stops). I think it is using EnumWindows to make sure that only one Pool of Radians Ruins of Myth Drannore is running. NB: With this patch Pool of Radians Ruins of Myth Drannore gets a window up and then exits.(With the dircetx from transgaming it plays the intro movies and gets almost into the game). Tommy.

Jan. 14, 2002

Re: A better calling interface for tests (and some bugfixes)

by Andriy Palamarchuk

--- Dan Kegel <dank(a)kegel.com> wrote: > The Linux kernel has a name for people who do > kernel maintenance: Kernel Janitors. Maybe people > who contribute test cases to Wine could be Windows > Washers? :-) Hey, this is a great idea! I was thinking myself about a good name for this project but you nailed it. I'm all for this name. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 14, 2002

Re: How about sponsoring from IBM?

by Roland

At 02:12 PM 1/12/02 -0500, David Elliott wrote: >hahahhahahahahaahahahahahahaha > >Sorry, ROTFLMAO, see below. Good to know you are having some fun right now! :)) Laughing is healthy! >Read up on your computer history a bit son. > >OS/2 ran Windows apps, and from about version 2 upwards ran all DOS and >Windows stuff perfectly (except for the Win32s stuff). I am sure IBM does >/not/ want to make the same mistake again. The question is, where the mistake was? The only similarity between OS/2 and WINE+LINUX is that both want to run M$ Windows software. You should ask some additional questions like: -would OS/2 have failed if it was for free like Linux+WINE? -would it fail if it had the ever growing acceptance that Linux is having. -would it fail if it where actually one of the most used OS on the server side? Even IBM is putting Linux on their big-iron. Ask yourself, why don't they use OS/2 for it? There are also other points to consider: -WINE is not an IBM project/product. So they can pull back from it anytime without losing their face. They couldn't do this with OS/2, so it costs them Billions for all the user support, etc...Thats where the real problem is! -Why should someone pay for OS/2 if they can have WINDOWS? Moving from one proprietary system to another is nonsense. But Linux+WINE are free, so it would make sense to move from WINDOWS to Linux. >Some people would argue that had IBM comitted to supporting Win32 stuff >that OS/2 would still be around. Of course the bottom line is that the >way they were doing this meant MS got the money for a copy of Windows >every time someone bought OS/2. Not good. Wine wouldn't And this also means that OS/2 will cost as much as WINDOWS at least, so there is no incentive to move. >As for IBM investing in Wine. I suppose there are a couple things they >could do. For one, they could somehow use the $10e6 you suggest but who >would they pay it to. What might be more helpful is if some of the guys >and gals that wrote OS/2 would help out with Wine. They Well, I think once they are willing to pay that money, I'm sure we would find out how to use it in a meaningfull way. There are at least two ways I can think about it. 1. Invest money in some company that already is on WINE developing like, Codeweavers and Transgaming. Actually I remember some guy of one of that companies saying it would contribute back some huge chunk of code they developed if they got the funding to pay for their costs from somewhere. 2. Pay some programmer(might be someone already developing WINE on their par-time) to become a full-time WINE developer. >Anyway, the bottom line is that IBM is not going to start throwing money >at stuff. They made that mistake with OS/2 and look where that got 'em. Once again I think this is no fair comparison. Investing on OS/2 meant a much BIGGER investment in money and, worse a company commitment to that product, which meant they couldn't simply pull back when they wanted, they had to support if for YEARS to come. With WINE things are totally different. They have to invest much less, in fact they can invest any arbitrarily value. I don't think 10 Million is much for them in comparison with what they invested(and still pay) on OS/2. >No, IBM spends money when and where it helps their bottom line. Taking >down MS does not help their bottom line. Building their own services does >help their bottom line. IBM could care less if everyone could run Windows >software on Linux. They are in the business of AFAIK, one of their bottom lines is promoting LINUX popularity, I don't want to quote one of their web-sites again(read my other mails). I think no one here will disagree if I say that WINE is THE cornerstone to promoting Linux popularity. >Note that IBM has already caught the eye of MS with IBMs ad campaign for >moving onto 390 systems running Linux. Some of those internal MS memos >recently released are really anti-IBM. Right now I think MS is at the >point where they have competitors. They can go Since IBM already caught the eye of MS it doesn't make a difference if they also invest on WINE. >waste their money on MS. When it breaks, let 'em waste more money on >moving it back to what worked. MS is going to shoot itself in the foot >soon enough, no need to bring out your own shotgun. If this was true, we wouldn't need Linux at all. The reality is different. We need to give the end-user a REAL alternative, and here is where WINE comes in... Roland

Jan. 14, 2002

Re: How about sponsoring from IBM?

by Christopher Morgan

Why stop at IBM? We should consider lobbying for support from any companies that serve to benefit from increased wine development. And on the IBM issue, how would we even present the case for wine to them or to any other company for that matter? Chris On Mon, 14 Jan 2002, Roland wrote: > At 02:12 PM 1/12/02 -0500, David Elliott wrote: > > >hahahhahahahahaahahahahahahaha > > > >Sorry, ROTFLMAO, see below. > > Good to know you are having some fun right now! :)) > Laughing is healthy! > > >Read up on your computer history a bit son. > > > >OS/2 ran Windows apps, and from about version 2 upwards ran all DOS and > >Windows stuff perfectly (except for the Win32s stuff). I am sure IBM does > >/not/ want to make the same mistake again. > > The question is, where the mistake was? The only similarity between OS/2 > and WINE+LINUX is that both want to run M$ Windows software. You should ask > some additional questions like: > -would OS/2 have failed if it was for free like Linux+WINE? > -would it fail if it had the ever growing acceptance that Linux is having. > -would it fail if it where actually one of the most used OS on the server side? > > Even IBM is putting Linux on their big-iron. Ask yourself, why don't they > use OS/2 for it? There are also other points to consider: > > -WINE is not an IBM project/product. So they can pull back from it anytime > without losing their face. They couldn't do this with OS/2, so it costs > them Billions for all the user support, etc...Thats where the real problem is! > -Why should someone pay for OS/2 if they can have WINDOWS? Moving from one > proprietary system to another is nonsense. But Linux+WINE are free, so it > would make sense to move from WINDOWS to Linux. > > > > >Some people would argue that had IBM comitted to supporting Win32 stuff > >that OS/2 would still be around. Of course the bottom line is that the > >way they were doing this meant MS got the money for a copy of Windows > >every time someone bought OS/2. Not good. Wine wouldn't > > And this also means that OS/2 will cost as much as WINDOWS at least, so > there is no incentive to move. > > >As for IBM investing in Wine. I suppose there are a couple things they > >could do. For one, they could somehow use the $10e6 you suggest but who > >would they pay it to. What might be more helpful is if some of the guys > >and gals that wrote OS/2 would help out with Wine. They > > Well, I think once they are willing to pay that money, I'm sure we would > find out how to use it in a meaningfull way. There are at least two ways I > can think about it. > 1. Invest money in some company that already is on WINE developing like, > Codeweavers and Transgaming. Actually I remember some guy of one of that > companies saying it would contribute back some huge chunk of code they > developed if they got the funding to pay for their costs from somewhere. > 2. Pay some programmer(might be someone already developing WINE on their > par-time) to become a full-time WINE developer. > > >Anyway, the bottom line is that IBM is not going to start throwing money > >at stuff. They made that mistake with OS/2 and look where that got 'em. > > Once again I think this is no fair comparison. Investing on OS/2 meant a > much BIGGER investment in money and, worse a company commitment to that > product, which meant they couldn't simply pull back when they wanted, they > had to support if for YEARS to come. With WINE things are totally > different. They have to invest much less, in fact they can invest any > arbitrarily value. I don't think 10 Million is much for them in comparison > with what they invested(and still pay) on OS/2. > > >No, IBM spends money when and where it helps their bottom line. Taking > >down MS does not help their bottom line. Building their own services does > >help their bottom line. IBM could care less if everyone could run Windows > >software on Linux. They are in the business of > > AFAIK, one of their bottom lines is promoting LINUX popularity, I don't > want to quote one of their web-sites again(read my other mails). I think no > one here will disagree if I say that WINE is THE cornerstone to promoting > Linux popularity. > > >Note that IBM has already caught the eye of MS with IBMs ad campaign for > >moving onto 390 systems running Linux. Some of those internal MS memos > >recently released are really anti-IBM. Right now I think MS is at the > >point where they have competitors. They can go > > Since IBM already caught the eye of MS it doesn't make a difference if they > also invest on WINE. > > >waste their money on MS. When it breaks, let 'em waste more money on > >moving it back to what worked. MS is going to shoot itself in the foot > >soon enough, no need to bring out your own shotgun. > > If this was true, we wouldn't need Linux at all. The reality is different. > We need to give the end-user a REAL alternative, and here is where WINE > comes in... > > Roland > > > >

Jan. 14, 2002

Listview Unicodification (take 2 try B :))

by Dimitrie O. Paun

Hi people, After a few more sleepless nights, I got the listview control close to something I'm willing to submit. The patch is here: http://www.cs.toronto.edu/~dimi/listview-unicode-2.diff Last night I've sent a message to the list (including the patch), but I think it didn't like it because of it's size. Oh well. Testing: the control seems to work fine in the File Chooser, and the Common Control Spy Samples (thanks Francois!). Unfortunately, I could not try Gerard's test cases, as I don't have VC++, and the little program from www.timex.com doesn't seem to wanna run on my box (it complains of an invalid date format in section [Intl] of win.ini even if I can see no date format in there). Gerard, can you try it out, if you don't mind? Comments, suggestions, and/or ideas are welcomed, as always. -- Dimi.

Jan. 14, 2002

Small test

by Dimitrie O. Paun

I've sent a message about the ListView control, and I can't see it in the list's archives, nor have I received a copy of it, so I'm afraid something happened to it, and hence this test message. My apologies, Dimi.

Jan. 14, 2002

Re: Regressions in Curse of Monkey Island again

by Ove Kaaven

On Mon, 14 Jan 2002, Johan Gill wrote: > Sound is pretty stuttering in the intro to Curse of Monkey Island. Which version of Wine do you use? Do you use CVS? Is the dsound mmap feature used? (If not, Eric's recent OSS patches may make a difference...) > At some occasions, these lines are quite frequent: > > trace:dsound:DSOUND_MixOne mixlen not worth it, deferring mixing > > Is that an issue? No. In fact, that message may be considered a good sign. It means that the premixing buffers are almost full (have enough data to play for a little while), so the mixing code decides to wait a bit before trying to prepare more data for the buffers. It's more productive to search for "underrun detected" messages, but these are only likely to occur in HAL mode (i.e. when the mmap feature is used). In HEL mode (i.e. without mmap), "physical" underruns are usually only seen by the wineoss audio driver (--debugmsg +wave), although dsound (in recent CVS) installs a wineoss callback which must be called often enough in order to avoid choppy sound (how often it must be called is adjustable with the #define DS_HEL_QUEUE/MARGIN at the top of dsound_main.c).

Jan. 14, 2002

dlls/ntdll/cdrom.c breaks portability

by Gerald Pfeifer

dlls/ntdll/cdrom.c revision 1.1 per date: 2002/01/13 01:44:00; author: julliard; state: Exp; Eric Pouech <eric.pouech(a)wanadoo.fr> Changed the Wine internal cdrom interface to the NT model. causes the following build failure on FreeBSD 4.4 (even though the code in question is embedded in "#elif defined(__FreeBSD__)"): /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o cdrom.o cdrom.c cdrom.c: In function `CDROM_ControlEjection': cdrom.c:172: `CDIOPREVENT' undeclared (first use in this function) cdrom.c:172: (Each undeclared identifier is reported only once cdrom.c:172: for each function it appears in.) cdrom.c: In function `CDROM_ReadQChannel': cdrom.c:414: structure has no member named `track_info' cdrom.c:438: `AUDIO_STATUS_IN_PAUSED' undeclared (first use in this function) cdrom.c:440: `CD_AS_PLAY_AUDIO_COMPLETED' undeclared (first use in this function) cdrom.c:453: structure has no member named `position' cdrom.c:454: structure has no member named `position' cdrom.c:455: structure has no member named `position' cdrom.c:456: structure has no member named `position' cdrom.c:457: structure has no member named `position' cdrom.c:460: structure has no member named `position' cdrom.c:461: structure has no member named `position' cdrom.c:462: structure has no member named `position' cdrom.c:464: structure has no member named `position' cdrom.c:465: structure has no member named `position' cdrom.c:466: structure has no member named `position' cdrom.c:471: structure has no member named `media_catalog' cdrom.c:472: structure has no member named `media_catalog' cdrom.c:473: structure has no member named `media_catalog' cdrom.c:477: structure has no member named `track_info' cdrom.c:478: structure has no member named `track_info' gmake[2]: *** [cdrom.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/ntdll' gmake[1]: *** [ntdll/libntdll.so] Error 2 Gerald

Jan. 14, 2002

Re: DOSFS_ToFCBFormat Bug Fix

by Ove Kaaven

On Sun, 13 Jan 2002 ccrayne(a)crayne.org wrote: > Change Log: > files/dos_fs.c > ccrayne(a)crayne.org > Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead > of as "*.*" This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff that used to confuse DOS users converting to Linux - "*.*" no longer meant all files...) Also, your mailer seems to mangle your patches. You may want to attach them instead of pasting them to avoid that.

Jan. 14, 2002

Regressions in Curse of Monkey Island again

by Johan Gill

Sound is pretty stuttering in the intro to Curse of Monkey Island. I've put the last 20000 lines of a dsound trace at ttp://www.lysator.liu.se/~johane/comi.txt. At some occasions, these lines are quite frequent: trace:dsound:DSOUND_MixOne mixlen not worth it, deferring mixing Is that an issue? Could someone tell if the error is in the underlying audio system or in DirectSound itself? /Johan Gill, johane(a)lysator.liu.se

Jan. 14, 2002

Re: EnumWindows

by Dan Kegel

Uwe Bonnes wrote: > > >>>>> "Tommy" == Tommy Schultz Lassen <tlassen(a)tlassen.dk> writes: > > Tommy> Why does EnumWindows return FALSE if no windows exists. Should it > Tommy> not return TRUE instead. Her is a patch witch changes it. > > What are your indications that the present behaviour is wrong? > Api-Description or Miss-Behaviour of some application? At some point soon, it'd be nice if patches like this were required to also contribute regression tests, and certify that the regression tests pass under real Windows. - Dan

Jan. 14, 2002

Re: first contribution

by Dan Kegel

James Juran wrote: > > Dan Kegel wrote: > > > > http://www.winehq.com/dev.shtml#sourcetree says... > > > > I think that page needs some improvment. Hmm, how about ... > > Thanks. I revised this a bit and added it to > http://www.winehq.com/dev.shtml. It should be get updated out of the > CVS repository soon. I left out the non-CVS patch generation > instructions to save space, since we want to encourage developers to use > CVS. Please let me know what you think. Looks good. I would also suggest: * add "Submitting Patches" to the table of contents, with a hyperlink, so I can link to it. * Spring cleaning: get rid of the "policies" heading and the "daily build and test" section, and set the "Submitting Patches" section apart with <hr>'s * Formatting: I'd suggest <blockquote> or <pre> around example code rather than <br>. Thanks for tidying that up! - Dan

Jan. 13, 2002

Re: EnumWindows

by Uwe Bonnes

>>>>> "Tommy" == Tommy Schultz Lassen <tlassen(a)tlassen.dk> writes: Tommy> Why does EnumWindows return FALSE if no windows exists. Should it Tommy> not return TRUE instead. Her is a patch witch changes it. What are your indications that the present behaviour is wrong? Api-Description or Miss-Behaviour of some application? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 13, 2002

Re: first contribution

by James Juran

Dan Kegel wrote: > > http://www.winehq.com/dev.shtml#sourcetree says: [...] > > I think that page needs some improvment. Hmm, how about this: [...] Thanks. I revised this a bit and added it to http://www.winehq.com/dev.shtml. It should be get updated out of the CVS repository soon. I left out the non-CVS patch generation instructions to save space, since we want to encourage developers to use CVS. Please let me know what you think. James -- James Juran jamesjuran(a)alumni.psu.edu

Jan. 13, 2002

Re: A better calling interface for tests (and some bugfixes)

by Dan Kegel

Patrik Stridvall wrote: > Well, I think it is better to just do say "use kernel 32;" > and have everything work than to have to do some awkward > defintion of each function. Better let and automatic script > spec2pm handle this. That sounds pretty cool. It sounds like the regression test framework(s) is (are) coming along nicely. I hope I have time to try writing some tests soon. I'm already pointing graduate students who ask for projects at this. Say, that brings up a point: it'd be real nice to have a web page I could point said grad students at. One of these days soon, once the framework settles down a bit, could somebody take the time to write a web page about how to get started writing and contributing regression tests? The Linux kernel has a name for people who do kernel maintenance: Kernel Janitors. Maybe people who contribute test cases to Wine could be Windows Washers? :-) - Dan

Jan. 13, 2002

Re: first contribution

by Dan Kegel

Shane Shields wrote: > > hi all, > > as my first contribution (implies that there is more to come ;-}) i have > found and fixed a (very) minor bug in updown.c but i am at a loss as to what > to do next. having read the documentation on cvs commit or cvs diff -u i am > still scratching my head in confusion. can somebody give me a newbie type > pointer as to what i can do? i have downloaded the latest cvs (todays date > 13/1/2002) using cvs update -PAd, altered updown.c, tested that it compiles > and am now waiting on fireproof instructions for the next steps (i burn > easily :-)). http://www.winehq.com/dev.shtml#sourcetree says: > Please submit patches to the Wine patches mailing list, > wine-patchesPlEaSeReMoVeme(a)winehq.com. (Note that if you're not > subscribed to the mailing list, the mailing list administrators > must first check your submission to make sure it's not spam > before they can let it through.) > > It's best to send small patches against the current tree. Update > your tree first, then generate the patch from the top wine > directory. cvs diff will always ignore newly added files, so > you'll need to do something like > diff -u /dev/null newfile.c >> patch.diff > to make a patch for newly added files. Include a comment for the logs. > Use > diff -Nu olddir/ newdir/ > in case of multiple files to add. I think that page needs some improvment. Hmm, how about this: -------- Please read through ten or twenty posts from the wine-patches mailing list to see what the prevailing style is. To fix a single file and submit a patch for it, follow this recipe (where $WINETOP stands for the top wine directory): # Back up the file you want to change cd $WINETOP/foo/bar cp blort.c blort.c.orig # Make your changes vi blort.c # cd to the top of the wine tree, e.g. cd $WINETOP # Create a unified diff diff -u foo/bar/file.c{.orig,} > my-blort.patch To make a fix that affects multiple files and perhaps adds new ones, follow these steps: # Save an untouched version of the whole wine # source tree in a directory named wine-yyyymmdd: cp -r wine wine-20020204 # Make your changes ... # cd to the top of the wine tree, e.g. cd $WINETOP/.. # Create a unified diff diff -Naur wine-20020204 wine > my-big.patch To submit a patch: Write a description of your patch, including changelog entry showing what you did to each file. For instance: > WaitForInputIdle is supposed to time out after a given time. But the > algorithm was: > > while ( dwTimeOut > GetTickCount() - cur_time ...) { > MsgWaitForMultipleObjects(...dwTimeOut...); > ... > } > > So if dwTimeOut is 60 seconds, and a message is received after 59 > seconds, then WaitForInputIdle would be stuck in > MsgWaitForMultipleObjects for an extra 60 seconds. Waiting 119 seconds > in all. > > With this patch this should not longer be the case. Other interesting > features: the unsigned int arithmetic, especially wrt. wrap-arounds. > It's a bit weird but should work. > > Changelog: > > François Gouget <fgouget(a)codeweavers.com> > > * windows/message.c > Better handling of the timeout in WaitForInputIdle > Use WAIT_FAILED rather than the corresponding literal Then email the description together with the patch to the wine-patches mailing list, using a descriptive subject line (e.g. "Prevent infinite wait in WaitForInputIdle"). (Be careful to not corrupt the patch; if you're using a gui mailer like Outlook, you may need to attach the patch file instead of simply inserting it in your message to avoid corruption.) ----------- How's that look? - Dan

Jan. 13, 2002

first contribution

by Shane Shields

hi all, as my first contribution (implies that there is more to come ;-}) i have found and fixed a (very) minor bug in updown.c but i am at a loss as to what to do next. having read the documentation on cvs commit or cvs diff -u i am still scratching my head in confusion. can somebody give me a newbie type pointer as to what i can do? i have downloaded the latest cvs (todays date 13/1/2002) using cvs update -PAd, altered updown.c, tested that it compiles and am now waiting on fireproof instructions for the next steps (i burn easily :-)). Shane Shields To be a *nix programmer or to be a windows progammer that is the question. The answer is simple...Be a WINE programmer and do both. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Jan. 13, 2002

Re: IBM, Notes, Wine and (necessary) version numbers for wine

by David Elliott

On 2002.01.12 09:20 rob(a)mediasolution.it wrote: > Hi there, > > > One of the better ways to show the potential to IBM would be to find > one > of > > their apps that *does* work under WINE and get it demoed to their > > management. Although it sounds like some of them are already > (internally) > > using Notes under Linux? > > Let me use your message to speak about a "feature" of the wine > developement model that's starting to "annoy" me: using "date-version" > instead of a proper version number for the snapshot. > I know I'm in no position to get annoyed by anything, since Iìve > contributed no code or useful hints so far :-), but I'd really like to > see > this change. > > > We all know Wine is evolving rather fast, and every 'n' months a major > subsystem gets rewritten to be able to implement it the "right" way, > windows speaking, or because the old implementation was only partially > complete. That's not a problem, since this way wine becomes better and > bettter. > > Where the problem is, however, is that I can't know when these changes, > that usually bring forth major breakages in some/many applications, are > done. I've been following wine-devel and wine-cvs and, back in June > (IIRC) > when the windows handling code was changed, I wasn't too surprised when > Lotus Notes stopped working (and it's still broken in many ways, window > repainting for example). > > Too bad SuSE people didn't follow the lists, and going from version 7.2 > to > version 7.3 of their distro, they "upgraded" their wine rpm package from > 20010326 to 20010731. With the new version, notes doesn't start at all... > > I ask: isn't it about time to use version numbers, like in the linux > kernel? I now you are working toward "1.0" release, but I guess some > 0.6.x > (stable) 0.7.x (unstable), 0.8.x (stable again) coudn't hurt, and this > kind of versioning give hints to people on where to go and what to > download if they want something stable or if they want the "newest". > Absolutely not. Check the archives, I think this has been discussed before. Wine is a relatively small developer community. No one here is interested in creating a code fork and doing only bug fixes in one branch to try to make a stable release while doing the major development in another tree. What we want to do is do major development on one tree, period. That is at least until we feel that Wine is even CLOSE to finished at which point we will work towards a 1.0 release. > I think it's important to let wine users understand if the package they > are about to install is a stable, well tested version, or an extremely > new, developemental and untested version. > > In my opinion, some snapshot (like the April 2001 one) are definitely > beta > quality, so I think it's useful to let people know this, especially at a > time like this when the Lindows people are saying "we fixed wine, going > from alfa to release!"... I'd really like to know from which snapshot > they > started... > Personally I would not consider a completely broken hacked together USER* that happens to work of beta quality. We would be wasting our time fixing bugs in the old versions. Let some company do that (i.e. Lindows). > > Ciao, > Roberto > Hmm, is that a blatant reference to the movie "The Waterboy" w/ Adam Sandler.. or just pure coincidence. > P.S. > I hope to be more useful in future, since I'm starting my own business > that will be based rather heavily on Linux, and this way I hope I'll be > able to search and destroy the most annoying bugs I find.. :-) > Good luck. -Dave

Jan. 12, 2002

Re: The most likely way to get IBM to sponsor WINE development

by David Elliott

On 2002.01.11 23:01 dschwarz(a)bellatlantic.net wrote: > > I've been following this discussion with some interest. I am a former > Iris/Lotus/IBM employee, and I now run the Winecentric pages > www.winecentric.com, basically a faq on how to run Lotus Notes and other > programs under WINE. > > I have had unofficial conversations with Lotus product development > managers; they have reacted to customer requests for the Lotus Notes > client > on Linux by doing their own testing, and they even publish an official > page > outlining how to run Lotus Notes with WINE. They don't offer customer > support (that would cost millions). > > The best way to get IBM to sponsor WINE development is to persuade them > to > port their flagship applications to Linux. IBM/Lotus have a long history > of > using API translators to port products across platforms, including Lotus > Notes and SmartSuite. > Hmm, I almost forgot about that in my other mail.. When IBM ported the Lotus stuff to OS/2 they /DID/ write Open32 to do this. However Open32 is not (and was never supposed to be) the full API. Thus why Odin exists. Originally designed to build on top of Open32 I think they gave up on that goal long ago and started borrowing code from Wine. In fact, lately one of the Odin developers mentioned he would be willing to release any part we of it we would like to the Wine project under the Wine license. Might be worth a look. > If they were persuaded to port, say, VisualAge for Java and SmartSuite, > using Winelib, we'd gain some new applications plus (hopefully) IBM would > contribute any Winelib enhancements back. > Yes, this is how they could probably best help the Wine project, their business, and Linux in general. Remember that IBM is all about providing the best experience for the customer (at least making it seem like they are :-). They also seem to be all about embracing (but not smothering) open standards. And furthermore above all they seem to be about interoperability. IBM had made numerous mistakes trying to lock people into IBM stuff but couldn't do it successfully (MS has really beaten them here, much to IBMs disappointment I am sure). OS/2 was basically nothing more than an attempt to lock everyone into IBM computers running IBMs OS. That follows on the heels of IBMs long history of locking people into IBM tech. I think the absolute failure of OS/2 was really the turning point for IBM. Now IBM seems more interested in not being a slave to anyone and not making anyone a slave to them. I think this is why Linux is so important to them. Ah well, it'll be interesting to look back at this mail in 5 years or so and see what has happened. Probably MS will have completely dominated everything except for the people who are using Linux because they like it and always have (i.e. the people on this list for the most part). Of course you know what they say... the bigger they are... the harder they fall. -Dave

Jan. 12, 2002

Re: How about sponsoring from IBM?

by David Elliott

On 2002.01.11 14:49 Roland wrote: > At 07:57 PM 1/11/02 +0100, Joerg Mayer wrote: > >> It looks like IBM spends its money on the products they themselvs use >> heavily, as well as training and making the name of Linux more popular >> (aka advertising/PR). > > Hmm, I think 10 Million on WINE would do more advertising on the long > run by attracting Windows Users and spreading the word, then the same > amount spent on ads. If you really want to make Linux popular, running > Windows software is the way, think about all the apps and games!!! > hahahhahahahahaahahahahahahaha Sorry, ROTFLMAO, see below. >> I may have missed it but I haven't seen IBM spend >> money on a Linux(related) project just to further the project. If they >> wanted to spend $10e7 just to improve programs/tools just for the "good" >> of it I would be sad to see this money spent on wine. I'd like to see >> it spent on the development/improvement of *native* Linux apps that >> fulfill the need of current Windows users. > > Well, you have two options: > > 1. Spend money on thousands of native Linux apps to capture the Windows > users. > 2. Spend money on ONE native Linux app(WINE) to make it run thousands of > Windows apps and attract the corresponding users. > > I think option 2 is the more intelligent and cheaper option. > Read up on your computer history a bit son. OS/2 ran Windows apps, and from about version 2 upwards ran all DOS and Windows stuff perfectly (except for the Win32s stuff). I am sure IBM does /not/ want to make the same mistake again. However WinOS/2 actually was running Windows 3.x. In fact, the technology was extremely similar to SCO Merge (which now has offspring-- Win4Lin). One nice thing it could do that win4lin could not was actually put toplevel windows onto the desktop directly (though they still had the win31 look). This would look similar to running Wine in non-desktop and non-managed mode, although the windows actually were managed by OS/2. Some people would argue that had IBM comitted to supporting Win32 stuff that OS/2 would still be around. Of course the bottom line is that the way they were doing this meant MS got the money for a copy of Windows every time someone bought OS/2. Not good. Wine wouldn't have that problem assuming it would be using all wine DLLs. As for IBM investing in Wine. I suppose there are a couple things they could do. For one, they could somehow use the $10e6 you suggest but who would they pay it to. What might be more helpful is if some of the guys and gals that wrote OS/2 would help out with Wine. They would probably be extremely familiar with Win32 seeing as how OS/2 was originally a joint MS/IBM project which MS got out of when they hacked Win3.0 to support virtual memory on a 386 and decided to make NT. Now while the NT kernel was developed by former VMS guys and gals from DEC, some of Win32 resembles OS/2 because some of those developers went on to work on NT. Which by the way no-one has confirmed that MS ever said it actually stood for New Technology.. more likely it stands for Nice Tits, but that's another story. Anyway, the bottom line is that IBM is not going to start throwing money at stuff. They made that mistake with OS/2 and look where that got 'em. No, IBM spends money when and where it helps their bottom line. Taking down MS does not help their bottom line. Building their own services does help their bottom line. IBM could care less if everyone could run Windows software on Linux. They are in the business of providing the totally integrated system. Running 3rd party stuff is usually not a top priority. Note that IBM has already caught the eye of MS with IBMs ad campaign for moving onto 390 systems running Linux. Some of those internal MS memos recently released are really anti-IBM. Right now I think MS is at the point where they have competitors. They can go after companies using Linux just like they have gone after companies in the past. They are also going after various IT admins who use Linux for certain tasks suggesting that MS software is better for everything. Of course anybody that tells you that one system is better than all others is full of shit, but hey, it sounds good to some managers who don't want to listen to the people they have working for them. Let 'em waste their money on MS. When it breaks, let 'em waste more money on moving it back to what worked. MS is going to shoot itself in the foot soon enough, no need to bring out your own shotgun. -Dave

Jan. 12, 2002