- wine-devel - winehq.org

RE: PATCH: Euro
by Patrik Stridvall 15 Jan '02

15 Jan '02

> On Sun, 6 Jan 2002, Patrik Stridvall wrote: > > > > This patch changes the NLS currency of all Euro countries to > > > use the "EUR" > > > as international currency and the euro-sign (iso-8859-15, > > > character 164). > > > > Hmm. While I'm do not doubt that some users of Wine might > find this useful, > > Wine is supposed to do what Windows does and if Windows > does something > > wrong Wine usually should as well. > > Wrong? Microsoft has released Euro updates for Windows, which > seems like > it's supposed to change the Windows NLS files to use the new > currency. It > should be available on the Windows Update site. I don't see > anything wrong > here. You are sure it changes the .NLS files (the default), not just the "copy" in registry? Does patches exists for all versions of Windows? Including Windows 3.1 and Windows 95? Anyway, I'm not worried primarily about this specific patch, but that any deviation from Windows no matter how "correct" it is in some meaning will make it harder to for example write a test suite for Wine. If no patch exist for say Windows 95 all Windows 95 users will have to make the change in the registry and the test suite on such a platform might not work correctly. Again this is not an argument for not having this patch including but rather a warning that we need to be careful when we have to do this type of changes. Obviously Wine must handle the Euro correctly, regardless what Windows do, otherwise we might get bad press and/or annoyed users.

2 1

(no subject)
by Mike McCormack 15 Jan '02

15 Jan '02

Hi Sam, This list is for discussing development of Wine, not Windows NT applications. If you have a Windows binary that you want to run in Linux, then get back to us. If you're writing a program to run in Linux, then use termios to solve your problem. If you're writing a program for Windows NT, then your talking to the wrong people. Mike > Hi, > > I am currently trying to write a program to implement a communication > protocol using WIN32 APIs on Windows NT 4.0. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Reading Line Status Register for Serial Communications on win32
by SAM . 15 Jan '02

15 Jan '02

Hi, I am currently trying to write a program to implement a communication protocol using WIN32 APIs on Windows NT 4.0. For this purpose it is required for me to read the parity bit of the Line Status Register when receiving data. The only way I could think of doing this was using by using IOCTL_SERIAL_LSRMST_INSERT code and enabling the LSRMST INSERT mode so that LSR information will be in the data stream read by ReadFile. Unfortunately for some reason this doesnt seem to work according to how it is documented. If anybody has used this function before can you please give me some tips as to what I might be doing wrong??? Also are there any other methods by which I can read the LSR on NT??? Thanks. Sam _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

1 0

How to enable printing ? (doco problem)
by Sylvain Petreolle 14 Jan '02

14 Jan '02

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

1 0

dlls/ntdll/cdrom.c breaks portability
by Gerald Pfeifer 14 Jan '02

14 Jan '02

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

2 1

EnumWindows
by Tommy Schultz Lassen 14 Jan '02

14 Jan '02

Why does EnumWindows return FALSE if no windows exists. Should it not return TRUE instead. Her is a patch witch changes it. Tommy.

3 3

Re: A better calling interface for tests (and some bugfixes)
by Dan Kegel 14 Jan '02

14 Jan '02

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

2 1

Re: How about sponsoring from IBM?
by Roland 14 Jan '02

14 Jan '02

Just to add a fact to my statements: http://news.cnet.com/news/0-1003-201-4656230-0.html quote:" IBM CEO Lou Gerstner announced IBM's $1 billion Linux commitment last month." (this was january 2001)

9 12

Listview Unicodification (take 2 try B :))
by Dimitrie O. Paun 14 Jan '02

14 Jan '02

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.

1 0

Small test
by Dimitrie O. Paun 14 Jan '02

14 Jan '02

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.

1 0

Regressions in Curse of Monkey Island again
by Johan Gill 14 Jan '02

14 Jan '02

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

2 1

first contribution
by Shane Shields 13 Jan '02

13 Jan '02

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

3 3

IBM, Notes, Wine and (necessary) version numbers for wine
by rob＠mediasolution.it 12 Jan '02

12 Jan '02

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". 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... Ciao, Roberto 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.. :-)

2 1

Re: The most likely way to get IBM to sponsor WINE development
by dschwarz＠bellatlantic.net 12 Jan '02

12 Jan '02

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. 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. Just my 2 cents... Dan Schwarz help(a)winecentric.com

2 1

Bad File Creation
by Guy L. Albertelli 12 Jan '02

12 Jan '02

In attempting to play with Outlook Express 5 under Wine, I find that the files created by OE are bad/damaged. The attachments are as follows: hoho.gif - view under Linux shows Folders.dbx as 75,204 hoho-win.gif - view under Windows shows Folders.dbx as 74K (pretty good). scandisk.gif - error message from scandisk under windows. hoho-win-after.gif - view under Windows shows Folders.dbx as 60K after repair. hoho.txt - selected pieces of the trace from Wine during the creation of Folders.dbx. Revisiting it under Linux shows the size is now 61,440. The Linux is RH 6.1 and the kernel is 2.2.12-20. This is the only file that this problem occurs on (not true, it also occurs on Inbox.dbx in the same folder). No other file that I create under Linux is damaged. I suspect that this may be due to Wine implementation of the call sequence of: GetFileSize(..) SetFilePointer(..) SetEndOfFile(..) Any comments or suggestions? Guy Albertelli <<galberte(a)neo.lrun.com>> Bathed in his currents of liquid helium, self-contained, immobile, vastly well informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuts a pulse which carries the cybernetic equivalent of the phrase, "Christ, what an imagination I've got. " - Stand on Zanzibar by John Brunner

1 0

Re: How about sponsoring from IBM?
by David.Goodenough＠DGA.co.uk 11 Jan '02

11 Jan '02

I would suggest that one of the things that would help would be for IBM development labs which are developing Windows code, such as the Lotus labs, to test their code under WINE as well as Windows, and if it does not work to report any problems they find with APIs to the WINE community, perhaps even with fixes as they can see what WINE is doing with their requests. Without the source code and the understanding of what they expect to happen it is difficult for WINE developers to work out why any app does not work (although the tracing gives many clues). This way WINE users get apps that work and the developers get good feedback. Roland <roland@netquant. To: Paul Clarke <pacman(a)us.ibm.com>, wine-devel(a)winehq.com com.br> cc: Sent by: Subject: Re: How about sponsoring from IBM? wine-devel-admin@ winehq.com 01/11/02 05:47 PM At 08:35 AM 1/11/02 -0600, Paul Clarke wrote: >My attempt to convince you otherwise: > >http://oss.software.ibm.com/developer/opensource/linux >http://www.ibm.com/linux > >Paul Clarke, IBM Good, so it really seems that IBM is commited to Linux. Now my question is, would it be too much to ask IBM to spend 1% of that 1 billion for Linux on WINE? Of course we are assuming that a full-featured WINE would DRASTICALLY increase the success of Linux. This would be in accordance with: "...with a shared vision of making Linux succeed." quote from http://www-124.ibm.com/developer/opensource/linux/ If the assumption is true I think those 10 Million would be the best spent part of that 1 Billion. Paul, do you know the people in charge of the Linux sponsoring? How about talking to them about this idea? It would be interesting to hear what they say. Maybe they even don't know about the WINE project... Just my 0.000 000 001$ Roland

2 1

Re: WinSpool Ordinal Addition
by Alexandre Julliard 11 Jan '02

11 Jan '02

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > In Windows 2000 (and I presume later), winspool.drv has some new functions. > The one this application is looking for turns out to be GetDefaultPrinter() > (ASCII version is ordinal 201, Unicode is 203). I've added the ASCII and > Unicode implementations of that function to winspool in the attached patch. > The ASCII version has been tested; I'd appreciate it if you could take a > glance at the Unicode version and see if I got the conversions correct. > > The application will now open the 'printer setup' dialog, instead of > returning an error. Exactly what error did you get before? And are you sure this is really an ordinal import? This seems the kind of things that Win95 does, but not so much Win2000. -- Alexandre Julliard julliard(a)winehq.com

3 6

ADPCM and Wine
by David D. Hagood 11 Jan '02

11 Jan '02

Is anybody working on support for playing ADPCM wave files under Wine? If not, I'd like to take a crack at it. I have an app that I use (Delorme's AAA MapNGo 4.0) that uses ADPCM wave files to contain spoken information on attractions. I know that Wine can access my sound system to play normal PCM wave files, as MN4 also has speech synthesis that does work. However, any attempt to play a ADPCM file results in the program pausing for a length of time, then continuing. I infer that this is because the lower levels of Wine don't know how to handle ADPCM. ADPCM isn't rocket science - several programs, including sox, understand the protocol. So, is anybody working on this (outside of TG and Lindows)? Any (non-null) pointers to useful information on how Wine has put together the sound subsystem? I'm not a Windows programmer, I'm an embedded systems and DSP person, but if I can find a block of code to hook into I can make this happen.

3 2

Re: async_private + ReadFile() etc. immediate completion
by Mike McCormack 11 Jan '02

11 Jan '02

Hi Martin, I haven't tried the patch yet, but from Lawson's trace it looks like the completion routine for ReadFileEx is not being called. Some notes: * the 16bit Comm code expects ReadFileEx to be unconditionally overlapped, and always call the completion function when the operation completes. * the completion function starts another ReadFileEx, and sends a WM_COMMNOTIFY message to the 16bit app. i had a look at you patch, but i haven't applied it yet, so it's difficult for me to see any problems... i'll have a go later today. Mike Original message from: lawson_whitney(a)juno.com > >On Thu, 10 Jan 2002, Martin Wilck wrote: .. >> I cannot test the serial comm code and must kindly ask somebody else >> to try that. >> >> Martin >> >> >It doesn't bother my 32 bit app, but the 16 bit app is unable to >initialize the modem. +comm,+file trace attached. > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

RE: ADPCM and Wine
by Patrik Stridvall 11 Jan '02

11 Jan '02

> On Fri, Jan 11, 2002 at 07:16:30AM -0600, David D. Hagood wrote: > > I have an app that I use (Delorme's AAA MapNGo 4.0) that > uses ADPCM wave > > files to contain spoken information on attractions. I know > that Wine can > > access my sound system to play normal PCM wave files, as > MN4 also has > > speech synthesis that does work. However, any attempt to > play a ADPCM > > file results in the program pausing for a length of time, then > > continuing. I infer that this is because the lower levels > of Wine don't > > know how to handle ADPCM. [snip] > Try --debugmsg > +driver,+mmsys,+mci,+mmio,+mmtime,+mciwave,+msacm,+wave,+midi,+ > mmaux,+relay (they're all inside dlls/winmm/*). > > That should help a lot in finding what's missing. Well, the ADPCM codec is not implemented in MSACM32 so it really can't work, can it? Anyway seeing the debug output can't hurt either.

1 0

RE: ADPCM and Wine
by Patrik Stridvall 11 Jan '02

11 Jan '02

> Is anybody working on support for playing ADPCM wave files > under Wine? Not that I know of. > If not, I'd like to take a crack at it. By all means. > I have an app that I use (Delorme's AAA MapNGo 4.0) that uses > ADPCM wave > files to contain spoken information on attractions. I know > that Wine can > access my sound system to play normal PCM wave files, as MN4 also has > speech synthesis that does work. However, any attempt to play a ADPCM > file results in the program pausing for a length of time, then > continuing. I infer that this is because the lower levels of > Wine don't > know how to handle ADPCM. That most likely correct. > ADPCM isn't rocket science - several programs, including sox, > understand > the protocol. OK. > So, is anybody working on this (outside of TG and Lindows)? Any > (non-null) pointers to useful information on how Wine has put > together > the sound subsystem? I'm not a Windows programmer, I'm an embedded > systems and DSP person, but if I can find a block of code to > hook into I > can make this happen. I suggest you talk to Eric Pouech <eric.pouech(a)wanadoo.fr>. He was active on the patch list yesterday so I suppose he will see this and reply. In the mean time I can tell you that the PCM support is in wine/dlls/mcacm and ADPCM support should be there as well. There is a file pcmconverter.c that implements PCM support so I suppose that there should be a adpcmconverter.c file to plug in the ADPCM support. There will probably need to be a few changes in other files as well. Anyway Eric understands this better than I do. Let's wait and see what he has to say.

1 0

Re: async_private + ReadFile() etc. immediate completion
by lawson_whitney＠juno.com 11 Jan '02

11 Jan '02

On Thu, 10 Jan 2002, Martin Wilck wrote: > > Hi, > > The patch below is a reworked version of the one posted yesterday > to wine-devel. > > I received only one rather positive comment from Mike, so I assume > everybody is d'accord :-) > > The patch is still long but actually adds only 50 lines. I find it very > hard to split it into seperate smaller ones. > > There were a few bugs, but now the patch runs fine with my regular file > IO test code. The code tests ReadFileEx() (always asynchronous) > ReadFile() (synchronous if possible, i.e. always synchronous on regular > files), and CancelIo(). > > In particular, the GetOverlappedResult() call in ReadFile() seems to work > as expected. > > I cannot test the serial comm code and must kindly ask somebody else > to try that. > > Martin > > It doesn't bother my 32 bit app, but the 16 bit app is unable to initialize the modem. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Handle quotes in command lines
by Francois Gouget 11 Jan '02

11 Jan '02

On Thu, 10 Jan 2002, Uwe Bonnes wrote: > Hallo, > > some application builds a commandline with arguments enclosed by quotes '"', > starts a daughter process with this commandline and relies on the quotes > being intact in the daughter process. Wine happily removed the quotes and so > the daughter process failed. > Appended patch keeps quotes intact, tested via CreateProcess and calling a > programm from the shell. When invoking wine from the shell, quotes need to > be escaped, like any other special characters. No. Your patch mishandles quotes. Normal behavior: $ ./createp Type the command to execute: main a\"b "c\"d\\" e CreateProcess returned: 1 error=0 GetCommandLine=[main a\"b c\"d\ e] main -> argc=4 0 [main] 1 [a"b] 2 [c"d\] 3 [e] With your patch: main a\"b "c\"d\\" e CreateProcess returned: 1 error=0 GetCommandLine=[main "a\b "c\d\\"" e] main -> argc=3 0 [main] 1 [a\b "c\d\"] 2 [e] main -> __argc=3 0 [main] 1 [a\b "c\d\"] 2 [e] With your patch we: * change the command line from what was specified, just as before * add quotes where there are none * misinterpret quotes * don't split arguments properly anymore The existing quote handling is perfect! I tested and retested it. The problem you are having is that we cannot garantee that the child process will get the exact same commandline because of the cmdline -> argv -> cmdline conversion. The fix for your problem is to pass the command line to the child process via a wineserver call or something. Guess which is the first test I am going to write with the new testing framework!!! (and I would much prefer to print the contents of argv to file than to try and hard-code all the checks in the child, plus how am I going to know which was the command line that was given to me anyway!) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

3 3

Re: Changes regarding wnaspi32 layer ?
by ma.hoff＠t-online.de 11 Jan '02

11 Jan '02

Mhhh, must have been an issue with a not properly installed Wine on my machine ! As you told me i ran some tests: First with the working 20010731 build ! Then i decided to switch to cvs from 20011226 and did ./tools/wineinstall ! Guess what, it was not reproducable :-/ With the fresh compiled cvs from 20011226 it works, too ... So, i can only imagine that last time i installed a newer version i must have mixed up anything (or had a bad rpm - this time i compiled my own !) Thank you anyway ! For me it's solved... (being happy) Martin Am Montag, 7. Januar 2002 09:28 schrieben Sie: > >>>>> "Martin" == Martin Hoffmann <ma.hoff(a)t-online.de> writes: > > Martin> Hi, i have some problems with the winaspi implementation (scsi > ... > > Martin> Guess what: --winver nt40 / win31 didn't change anything :-) > > Martin> So it seems that its not implemented, but with older versions > it Martin> worked ! > > Run a test with --debugmsg +relay,+snoop,+aspi and look what happens before > the message about the VXD happens. Quote what you feel important ( and a > little more) to the list if you don't find anything. > > Bye

2 1

Lindows screenshots
by Hetz Ben Hamo 11 Jan '02

11 Jan '02

Hi, I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots Now, IF they did use wine (and thats a big if - from the screenshots they're running either Office 2K or office XP, Internet Explorer, the fonts looks like MS TTF fonts, and I think those screenshots are modified a bit - look at the 2nd screenshots, behind the start menu - look at the "file/edit/view" menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today. Hetz

9 11

How about sponsoring from IBM?
by Roland 10 Jan '02

10 Jan '02

Hello, it seems that IBM is becoming a major Linux advocate. What would be the possibilities of having it sponsor the WINE project? I mean 1 Million dollars is not much for IBM, but it certainly would mean a lot to the development of WINE. IBM would also profit of this. Since Linux runs on their supercomputers, it would be nice if you could run all Windows programs there(you need another Pentium emulator then, but that would not be a big problem, would it?). Just thinking about this... Roland

3 2

RE: Debugger set breakpoint with full filename
by Medland, Bill 10 Jan '02

10 Jan '02

> -----Original Message----- > From: eric [mailto:eric.pouech@wanadoo.fr] > Sent: Thursday, January 10, 2002 12:49 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Debugger set breakpoint with full filename > > > > Unfortunately not. > it should (under the name EntryPoint) > try MyDLL.EntryPoint, it should work Ah! Thanks p.s. you DO need the .DLL (at least I do) (break MyDll.DLL.EntryPoint) Bill

2 1

RE: Debugger set breakpoint with full filename
by Medland, Bill 10 Jan '02

10 Jan '02

> -----Original Message----- > From: eric [mailto:eric.pouech@wanadoo.fr] > Sent: Thursday, January 10, 2002 11:45 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Debugger set breakpoint with full filename > > > Bill Medland a écrit : > > > > I've spent time looking for the answer and trying the (to > me) obvious > > options and now I give in. > > > > How, in the debugger, do I specify "Set a break point at DllMain of > > E:\BIN.50A\..MYDLL.DLL" > > without the debugger complaining about syntax etc.? > hmmm debugger isn't ready to handle DLL names which contain '.' Woops. I meant an ellipsis. > > another solution is to ask the debugger to break on each DLL loading. > set $BreakOnDllLoad = 1 > then, you would be able to add a breakpoint on DllMain > (which, I assume > would be exported from the DLL, meaning its symbol will be > known to the > debugger) Unfortunately not. Thanks for the help anyway. Bill

2 1

Babystep: Testing framework
by Jeremy White 10 Jan '02

10 Jan '02

The attached revision to Alexandres patch modifies the Wine makefiles such that a Linux developer can: make test (to confirm all regression tests) make clean-test (to clear the tests and try again) It also creates three sample tests in programs/winetest/samples which hopefully demonstrate to a test author how to write a test. (The *.test files are human readable). It has provisions for Perl and Winelib/C tests, as well as allowing for the arbitrary execution of any other command (which should allow any other test tools to be plugged in). It has many flaws, but is intended as a possible jumpstart to get this process rolling. Flaws: 1. It has no provision for use on Windows. IMO the right way to fix this is to go through the effort of making Wine's ./configure script be intelligent enough to build 'Winelib' programs, so that in Windows a 'make test' should just work. 2. I really don't like that a C/Winelib test requires its own directory (see samples/sample3). However, AFAICT, that was the only way to create a simple and clean build environment for the Winelib app. 3. No doco. Thoughts? Comments? Jer diff --exclude=CVS -rNu oldwine/programs/winetest/Makefile.in wine/programs/winetest/Makefile.in --- oldwine/programs/winetest/Makefile.in Sat Nov 24 11:07:14 2001 +++ wine/programs/winetest/Makefile.in Wed Jan 9 09:20:50 2002 @@ -12,6 +12,8 @@ EXTRA_OBJS = wine.o +SUBDIRS = samples + @MAKE_PROG_RULES@ diff --exclude=CVS -rNu oldwine/programs/winetest/runtest wine/programs/winetest/runtest --- oldwine/programs/winetest/runtest Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/runtest Wed Jan 9 10:22:42 2002 @@ -0,0 +1,70 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# runtest <wine dir> <test name> <output file name> +# Run a regression test +# +# This script sources a '.test' file which must set one of the following: +# test_invoke (a command to invoke) +# test_perl_script (a Perl test script to be run with winetest) +# and can set one of the following: +# test_reference=<name of reference file with required diff> +# test_pattern=<pattern required in output> +#---------------------------------------------------------------------------- +topobjdir="$1" +shift +perldir="$topobjdir/programs/winetest" +LD_LIBRARY_PATH="$topobjdir/dlls:$topobjdir:$LD_LIBRARY_PATH" +export LD_LIBRARY_PATH +WINESERVER="$topobjdir/server/wineserver" +export WINESERVER + +testfile="$1" +testfiledir=`dirname $testfile` +shift + +outfile="$1" + + +export test_invoke= +export test_perl_script= +export test_reference= +export test_pattern= + +source $testfile + + +if [ "$test_perl_script" ] ; then + $perldir/winetest -debugmsg -all -- -I $perldir $testfiledir/"$test_perl_script" >$outfile +elif [ "$test_invoke" ] ; then + $testfiledir/$test_invoke >$outfile +else + echo "Error - neither test_invoke nor test_perl_script set in .test file" + rm -f $outfile + exit 1 +fi +return_status=$? + +if [ $return_status -ne 0 ] ; then + echo "Test $@ failed - return status $return_status" + rm -f $outfile + exit $return_status +fi + +if [ "$test_reference" ] ; then + diff -q $outfile $testfiledir/"$test_reference" >/dev/null 2>&1 + if [ $? -ne 0 ] ; then + echo "Test $@ failed - output failed to match reference" + rm -f $outfile + exit $? + fi +fi + +if [ "$test_pattern" ] ; then + grep -q "$test_pattern" $outfile + if [ $? -ne 0 ] ; then + echo "Test $@ failed - pattern $test_pattern not found" + rm -f $outfile + exit $? + fi +fi + diff --exclude=CVS -rNu oldwine/programs/winetest/samples/Makefile.in wine/programs/winetest/samples/Makefile.in --- oldwine/programs/winetest/samples/Makefile.in Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/Makefile.in Wed Jan 9 10:23:08 2002 @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = samples + +SUBDIRS = sample3 + +TESTS = sample1.test \ + sample2.test \ + sample3.test + +@MAKE_RULES@ + diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.ref wine/programs/winetest/samples/sample1.ref --- oldwine/programs/winetest/samples/sample1.ref Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.ref Tue Jan 8 22:51:51 2002 @@ -0,0 +1 @@ +Sample Test 1 Output diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.sh wine/programs/winetest/samples/sample1.sh --- oldwine/programs/winetest/samples/sample1.sh Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.sh Tue Jan 8 22:51:32 2002 @@ -0,0 +1,2 @@ +#!/bin/bash +echo Sample Test 1 Output diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.test wine/programs/winetest/samples/sample1.test --- oldwine/programs/winetest/samples/sample1.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.test Tue Jan 8 23:29:30 2002 @@ -0,0 +1,15 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample1 +# +# Test Purpose: +# To show how to write a simple test that runs a shell script +# +#---------------------------------------------------------------------------- +#test_perl_script=<name of Perl script to be used> +test_invoke=sample1.sh +test_reference=sample1.ref +test_pattern='Sample Test' diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample2.pl wine/programs/winetest/samples/sample2.pl --- oldwine/programs/winetest/samples/sample2.pl Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample2.pl Tue Jan 8 22:59:07 2002 @@ -0,0 +1,28 @@ +# +# Test script for the winetest program +# + +use wine; + +$wine::debug = 0; + +################################################################ +# Declarations for functions we use in this script + +wine::declare( "kernel32", + GetCurrentProcessId => "int" +); + +################################################################ +# Test some simple function calls + +# Test string arguments +$pid = GetCurrentProcessId(); +print "pid is *$pid\n"; + +if ($pid == 0) +{ + exit 1 +}; + +exit 0; diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample2.test wine/programs/winetest/samples/sample2.test --- oldwine/programs/winetest/samples/sample2.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample2.test Tue Jan 8 22:54:53 2002 @@ -0,0 +1,16 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample2 +# +# Test Purpose: +# Show how to use the Perl winetest prgoram to invoke a simple +# Windows API and check results +# +#---------------------------------------------------------------------------- +test_perl_script=sample2.pl +#test_invoke=<cmd to invoke> +#test_reference= +#test_pattern= diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/Makefile.in wine/programs/winetest/samples/sample3/Makefile.in --- oldwine/programs/winetest/samples/sample3/Makefile.in Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/Makefile.in Wed Jan 9 10:21:36 2002 @@ -0,0 +1,12 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = sample3 + +C_SRCS = \ + sample3.c + +@MAKE_PROG_RULES@ + +### Dependencies: diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/sample3.c wine/programs/winetest/samples/sample3/sample3.c --- oldwine/programs/winetest/samples/sample3/sample3.c Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/sample3.c Wed Jan 9 09:14:36 2002 @@ -0,0 +1,16 @@ +#include <windows.h> + + +void main(void) +{ + HANDLE pid; + + pid = GetCurrentProcessId(); + + printf("pid is 0x%x\n", pid); + + if (pid) + exit(0); + + exit(1); +} diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/sample3.spec wine/programs/winetest/samples/sample3/sample3.spec --- oldwine/programs/winetest/samples/sample3/sample3.spec Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/sample3.spec Wed Jan 9 09:15:25 2002 @@ -0,0 +1,16 @@ +name sample3 +type win32 +mode cuiexe +init main + +import advapi32.dll +import comdlg32.dll +import gdi32.dll +import kernel32.dll +import ntdll.dll +import odbc32.dll +import ole32.dll +import oleaut32.dll +import shell32.dll +import user32.dll +import winspool.drv diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3.test wine/programs/winetest/samples/sample3.test --- oldwine/programs/winetest/samples/sample3.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3.test Wed Jan 9 10:20:24 2002 @@ -0,0 +1,16 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample3 +# +# Test Purpose: +# Show how to use a C Winelib to invoke a simple +# Windows API and check results +# +#---------------------------------------------------------------------------- +#test_perl_script=<perl script> +test_invoke=sample3/sample3 +#test_reference= +#test_pattern= --- oldwine/Make.rules.in Fri Dec 14 17:14:22 2001 +++ wine/Make.rules.in Wed Jan 9 09:10:16 2002 @@ -58,6 +58,8 @@ ALLLINTFLAGS = $(LINTFLAGS) $(DEFS) $(OPTIONS) $(DIVINCL) WINAPI_CHECK = $(TOPSRCDIR)/tools/winapi_check/winapi_check WINEBUILD = $(TOPOBJDIR)/tools/winebuild/winebuild +WINETEST = $(TOPOBJDIR)/programs/winetest/winetest +RUNTEST = $(TOPOBJDIR)/programs/winetest/runtest MAKEDEP = $(TOPOBJDIR)/tools/makedep WRC = $(TOPOBJDIR)/tools/wrc/wrc WMC = $(TOPOBJDIR)/tools/wmc/wmc @@ -95,7 +97,7 @@ # Implicit rules -.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c +.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c .test .test.out .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $< @@ -121,6 +123,9 @@ .c.ln: $(LINT) -c $(ALLLINTFLAGS) $< || ( $(RM) $@ && exit 1 ) +.test.test.out: + $(RUNTEST) $(TOPOBJDIR) $< $@ + .PHONY: all install uninstall clean distclean depend dummy # 'all' target first in case the enclosing Makefile didn't define any target @@ -216,7 +221,7 @@ -cd `dirname $@` && $(RM) $(CLEAN_FILES) clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) - $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(PROGRAMS) + $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(TESTS:%=%.out) $(PROGRAMS) # Rules for installing @@ -226,6 +231,22 @@ $(SUBDIRS:%=%/__uninstall__): dummy cd `dirname $@` && $(MAKE) uninstall +# Rules for testing + +$(SUBDIRS:%=%/__clean-test__): dummy + @cd `dirname $@` && $(MAKE) clean-test + +$(SUBDIRS:%=%/__test__): dummy + @cd `dirname $@` && $(MAKE) test + +test:: $(SUBDIRS:%=%/__test__) $(WINETEST) $(TESTS:%=%.out) + +clean-test:: $(SUBDIRS:%=%/__clean-test__) + $(RM) $(TESTS:%=%.out) + +$(WINETEST): + cd $(TOPOBJDIR)/programs/winetest && $(MAKE) winetest + # Misc. rules $(SPEC_SRCS:.spec=.spec.c): $(WINEBUILD) --- oldwine/Makefile.in Sun Jan 6 12:38:45 2002 +++ wine/Makefile.in Wed Jan 9 09:10:16 2002 @@ -130,6 +130,9 @@ @cd dlls && $(MAKE) checklink @cd debugger && $(MAKE) checklink +test:: + @cd dlls && $(MAKE) test + TAGS etags: etags `find $(TOPSRCDIR) -name '*.[chS]' -print | grep -v dbgmain` --- oldwine/configure Mon Jan 7 15:00:27 2002 +++ wine/configure Wed Jan 9 10:20:42 2002 @@ -6250,16 +6250,15 @@ #line 6251 "configure" #include "confdefs.h" #include <stdio.h> -#include <sys/types.h> -main() +int main() { FILE *f=fopen("conftestval", "w"); - if (!f) exit(1); + if (!f) return(1); fprintf(f, "%d\n", sizeof(long long)); - exit(0); + return(0); } EOF -if { (eval echo configure:6263: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:6262: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sizeof_long_long=`cat conftestval` else @@ -6280,12 +6279,12 @@ echo $ac_n "checking whether linux/input.h is for real""... $ac_c" 1>&6 -echo "configure:6284: checking whether linux/input.h is for real" >&5 +echo "configure:6283: checking whether linux/input.h is for real" >&5 if eval "test \"`echo '$''{'wine_cv_linux_input_h'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6289 "configure" +#line 6288 "configure" #include "confdefs.h" #include <linux/input.h> @@ -6298,7 +6297,7 @@ ; return 0; } EOF -if { (eval echo configure:6302: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6301: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_input_h=yes else @@ -6322,12 +6321,12 @@ echo $ac_n "checking whether we can use re-entrant gethostbyname_r Linux style""... $ac_c" 1>&6 -echo "configure:6326: checking whether we can use re-entrant gethostbyname_r Linux style" >&5 +echo "configure:6325: checking whether we can use re-entrant gethostbyname_r Linux style" >&5 if eval "test \"`echo '$''{'wine_cv_linux_gethostbyname_r_6'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6331 "configure" +#line 6330 "configure" #include "confdefs.h" #include <netdb.h> @@ -6348,7 +6347,7 @@ ; return 0; } EOF -if { (eval echo configure:6352: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6351: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_gethostbyname_r_6=yes else @@ -6374,12 +6373,12 @@ if test "$ac_cv_header_linux_joystick_h" = "yes" then echo $ac_n "checking whether linux/joystick.h uses the Linux 2.2+ API""... $ac_c" 1>&6 -echo "configure:6378: checking whether linux/joystick.h uses the Linux 2.2+ API" >&5 +echo "configure:6377: checking whether linux/joystick.h uses the Linux 2.2+ API" >&5 if eval "test \"`echo '$''{'wine_cv_linux_joystick_22_api'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6383 "configure" +#line 6382 "configure" #include "confdefs.h" #include <sys/ioctl.h> @@ -6394,7 +6393,7 @@ /*empty*/ ; return 0; } EOF -if { (eval echo configure:6398: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6397: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_joystick_22_api=yes else @@ -6421,12 +6420,12 @@ if test "$ac_cv_header_sys_vfs_h" = "yes" then echo $ac_n "checking whether sys/vfs.h defines statfs""... $ac_c" 1>&6 -echo "configure:6425: checking whether sys/vfs.h defines statfs" >&5 +echo "configure:6424: checking whether sys/vfs.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_vfs_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6430 "configure" +#line 6429 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6443,7 +6442,7 @@ ; return 0; } EOF -if { (eval echo configure:6447: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6446: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_vfs_has_statfs=yes else @@ -6470,12 +6469,12 @@ if test "$ac_cv_header_sys_statfs_h" = "yes" then echo $ac_n "checking whether sys/statfs.h defines statfs""... $ac_c" 1>&6 -echo "configure:6474: checking whether sys/statfs.h defines statfs" >&5 +echo "configure:6473: checking whether sys/statfs.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_statfs_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6479 "configure" +#line 6478 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6490,7 +6489,7 @@ ; return 0; } EOF -if { (eval echo configure:6494: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6493: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_statfs_has_statfs=yes else @@ -6517,12 +6516,12 @@ if test "$ac_cv_header_sys_mount_h" = "yes" then echo $ac_n "checking whether sys/mount.h defines statfs""... $ac_c" 1>&6 -echo "configure:6521: checking whether sys/mount.h defines statfs" >&5 +echo "configure:6520: checking whether sys/mount.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_mount_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6526 "configure" +#line 6525 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6537,7 +6536,7 @@ ; return 0; } EOF -if { (eval echo configure:6541: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6540: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_mount_has_statfs=yes else @@ -6563,7 +6562,7 @@ echo $ac_n "checking for statfs.f_bfree""... $ac_c" 1>&6 -echo "configure:6567: checking for statfs.f_bfree" >&5 +echo "configure:6566: checking for statfs.f_bfree" >&5 if eval "test \"`echo '$''{'wine_cv_statfs_bfree'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -6572,7 +6571,7 @@ wine_cv_statfs_bfree=no else cat > conftest.$ac_ext <<EOF -#line 6576 "configure" +#line 6575 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6599,7 +6598,7 @@ ; return 0; } EOF -if { (eval echo configure:6603: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6602: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_statfs_bfree=yes else @@ -6623,7 +6622,7 @@ fi echo $ac_n "checking for statfs.f_bavail""... $ac_c" 1>&6 -echo "configure:6627: checking for statfs.f_bavail" >&5 +echo "configure:6626: checking for statfs.f_bavail" >&5 if eval "test \"`echo '$''{'wine_cv_statfs_bavail'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -6632,7 +6631,7 @@ wine_cv_statfs_bavail=no else cat > conftest.$ac_ext <<EOF -#line 6636 "configure" +#line 6635 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6659,7 +6658,7 @@ ; return 0; } EOF -if { (eval echo configure:6663: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6662: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_statfs_bavail=yes else @@ -6684,12 +6683,12 @@ echo $ac_n "checking for msg_accrights in struct msghdr""... $ac_c" 1>&6 -echo "configure:6688: checking for msg_accrights in struct msghdr" >&5 +echo "configure:6687: checking for msg_accrights in struct msghdr" >&5 if eval "test \"`echo '$''{'ac_cv_c_msg_accrights'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6693 "configure" +#line 6692 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6697,7 +6696,7 @@ struct msghdr hdr; hdr.msg_accrights=0 ; return 0; } EOF -if { (eval echo configure:6701: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6700: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_msg_accrights="yes" else @@ -6720,12 +6719,12 @@ echo $ac_n "checking for sa_len in struct sockaddr""... $ac_c" 1>&6 -echo "configure:6724: checking for sa_len in struct sockaddr" >&5 +echo "configure:6723: checking for sa_len in struct sockaddr" >&5 if eval "test \"`echo '$''{'ac_cv_c_sockaddr_sa_len'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6729 "configure" +#line 6728 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6734,7 +6733,7 @@ static struct sockaddr addr; addr.sa_len = 1 ; return 0; } EOF -if { (eval echo configure:6738: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6737: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_sockaddr_sa_len="yes" else @@ -6757,12 +6756,12 @@ echo $ac_n "checking for sun_len in struct sockaddr_un""... $ac_c" 1>&6 -echo "configure:6761: checking for sun_len in struct sockaddr_un" >&5 +echo "configure:6760: checking for sun_len in struct sockaddr_un" >&5 if eval "test \"`echo '$''{'ac_cv_c_sockaddr_sun_len'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6766 "configure" +#line 6765 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6771,7 +6770,7 @@ static struct sockaddr_un addr; addr.sun_len = 1 ; return 0; } EOF -if { (eval echo configure:6775: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6774: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_sockaddr_sun_len="yes" else @@ -6794,12 +6793,12 @@ echo $ac_n "checking whether we need to define __i386__""... $ac_c" 1>&6 -echo "configure:6798: checking whether we need to define __i386__" >&5 +echo "configure:6797: checking whether we need to define __i386__" >&5 if eval "test \"`echo '$''{'ac_cv_cpp_def_i386'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6803 "configure" +#line 6802 "configure" #include "confdefs.h" #if (defined(i386) || defined(__i386)) && !defined(__i386__) yes @@ -7075,6 +7074,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile @@ -7338,6 +7339,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile --- oldwine/configure.in Mon Jan 7 15:00:27 2002 +++ wine/configure.in Wed Jan 9 10:20:39 2002 @@ -1328,6 +1328,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile --- oldwine/dlls/Makedll.rules.in Mon Sep 17 15:09:08 2001 +++ wine/dlls/Makedll.rules.in Wed Jan 9 09:10:16 2002 @@ -36,6 +36,10 @@ checklink:: lib$(MODULE).$(LIBEXT) $(CC) -o checklink $(TOPSRCDIR)/library/checklink.c -L. -l$(MODULE) $(ALL_LIBS) && $(RM) checklink +# Rules for testing + +$(TESTS:%=tests/%.out): lib$(MODULE).$(LIBEXT) + # Rules for debug channels debug_channels: dummy

4 16

Debugger set breakpoint with full filename
by Bill Medland 10 Jan '02

10 Jan '02

I've spent time looking for the answer and trying the (to me) obvious options and now I give in. How, in the debugger, do I specify "Set a break point at DllMain of E:\BIN.50A\..MYDLL.DLL" without the debugger complaining about syntax etc.? If someone answers then I am prepared to add the info to debugger.sgml Bill

2 3

Re: crypto patch
by Travis Michielsen 10 Jan '02

10 Jan '02

Hmm, forgot this part of the part of the patch. - Travis On Wednesday, January 09, 2002 5:27 pm, you wrote: > Hi, > > This patch implements the cryptographic API functions existing in > advapi32.dll. However, there are still issues with some of the M$ > providers and the pstores.exe service, so I'm not sure how functional this > will be until something can be done about this service. > > Changelog: > Travis Michielsen <tjmichielsen(a)yahoo.com> > Implement advapi32 portion of the CryptoAPI.

1 0

Re: Immediate IO in ReadFile / WriteFile
by Mike McCormack 10 Jan '02

10 Jan '02

Hey Martin, As Lawson said, some programs use WaitForComm event to wait for data, then GetCommError to check how many bytes arrived, then ReadFile to read it. They then expect ReadFile to return TRUE. One such program is VBTerm, the visual basic terminal program, or at least the VBX in it. Testing applications that use serial ports is difficult, and debugging often must be done remotely. (eg. send me a trace like this, apply this patch and send me another trace, etc.) After making a change, i usually get a terminal program (such as KoalaTerm) and send a couple of "AT" commands to it... :-) Mike Original message from: lawson_whitney(a)juno.com > >On Wed, 9 Jan 2002, Martin Wilck wrote: >.... >> How do you check if data is ready in Windows? I didn't find a select() >> equivalent, nor is it possible to wait on file handles. >> >GetCommError and some other functions, I think, returns lpStat->cbInQue, >which is in effect the number of characters immediately available to be >read. > >> Martin >> >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

int $3 and pstores service
by Travis Michielsen 10 Jan '02

10 Jan '02

Hello, I have been tracing into pstores.exe the protected storage sevice provider in windows (win98). This service may be necessary to get the cryptographic API to function using native dlls (no wine providers currently exist). I noticed that the service was being started using the following calls: 1) The program calls CryptAcquireContext. 2) CryptAcquireContext calls CPAcquireContext of the apropriate service provider 3) Any MS provider I tested would call PStoreCreateInstance in pstorec.dll 4) pstore.exe would be started by a call to CreateProcessA Immediately after the call to CreateProcessA, a call to interrupt 3 seems to be made but doesn't appear to return. Anyone know what this interupt does or sopposed to do? Is there any support for it in wine? A few other notes: -pstores appears to execute fine when started directly under wine. -when started from above it seems to crash (randomly?) depending on the provider? usually tries to execute the instruction at 0x00000000. -some other calls in the API appear to rely on this service I *think* through psbase.dll (but maybe pstores.exe somehow). I haven't verified this yet though. Anyone have some suggestions? - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Is W really UTF-16?
by Bill Medland 09 Jan '02

09 Jan '02

Sorry to resurrect an old subject, and please excuse my ignorance; I am only just getting started on this "character encoding" stuff. While I was working on the DrawText functions over the past many months I started wondering about when it would fail. (I'm pedantic and such things fascinate me!). The main concern I have is how to walk a W string correctly. For example while "ellipsifying" text we will need to "move the pointer to the previous character" which is currently done by decrementing the pointer by 1. But from what I currently understand that won't work if there are surrogate pairs. I see that MSDN these days keeps talking about surrogate pairs and the fact that strings of WCHARS might include them and I started to get the impression that the inputs to the W functions were truly UTF-16. I have just been looking at the discussions from April 2000 on this subject and I get the impression that we believe it too. My understanding of UTF-16 is that a surrogate pair is quite obvious and doesn't require any context information; if you come across a 16 bit value in 0xDC00 to 0xDFFF then it must be the low surrogate and there must be a high surrogate just before it. So I presumed that CharNextW must be the function that correctly walks a W string and I tried to find out what its behaviour was for the error cases (e.g. high surrogate with no low surrogate). On finding that CharNextW didn't do anything clever, it just incremented by 1, I tested and found that CharNextW always incremented by 1. So now I am confused. 1. Does anyone know under what circumstances CharNextW isn't +1 (apart from when pointing at the terminating 0) 2. Is e.g. XP really using UTF-16 or is it actually still UCS2? 3 Have we thought about how we should handle walking along a W string (in a fashion that doesn't reduced the speed to a crawl). I guess that in the short term I am expecting some sort of macro or inline. Bill Medland

2 2

Re: Immediate IO in ReadFile / WriteFile
by Mike McCormack 09 Jan '02

09 Jan '02

Hey Martin, Another day, another problem. :-) You can't unconditionally use overlapped operations... the code used to do that exactly, and it caused all sorts of breakages. eg. some (braindead) programs check that there is data is ready to read, then do an overlapped read, but expect it *not* to go overlapped. I don't think WaitForMultipleObjectsEx(0,NULL,FALSE,0,TRUE) then read, is the right way... I think the best solution is to let the server decide. Something like this: BOOL ReadFile_overlapped () { ovp = new async_private; while(1) { ovp->func = FILE_AsyncReadService; wine_server_call(register_async); switch(GetLastError()) { case STATUS_SUCCESS: ovp->func(ovp); break; case STATUS_PENDING: return FALSE; case STATUS_TIMEOUT: goto finish_it; default: delete ovp; return FALSE; } if(count >= bytes_to_read) break; } finish_it: delete ovp; *bytes_read = count; } This is the kind of structure i was trying to describe to you in a previous private mail... i was trying to address a different problem but it should address the one you mention too. In fact, WaitCommEvent also needs to work in this way. (Somebody on wine-users has a program that needs that behaviour now.) There's a minefield of special cases... but the essence is that the wine server instructs the client to do one of the following things: * perform the action (read/write/etc) * return from the call with success * return from the call with ERROR_PENDING * wait for an event flag (ie. not return yet) Does that make sense to you? Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi Mike, > >I just had the following thought on the immediate IO in ReadFile() / >WriteFile() that you implemented: > >Consider the following situation: > >1. There is no data available for reading on some fd (serial port, pipe, > socket). >2. An application calls ReadFile() in overlapped mode. > since no data is there, an overlapped request is scheduled. >3. Data becomes available before the app issues a wait request of any > kind. >4. The application starts another ReadFile() request. > Now data is there, and will be read immediately. > No async request is scheduled. >5. Eventually, more data will become available, and the async request > first scheduled will also return. > >However, this basically destroys the order of the requests. >I am unsure how Windows would behave in such a case, and it is certainly >difficult to provide a test case for this situation. It can occur, though, >and my guess is this is the wrong behaviour. > >Thus, probably before doing the immediate read it should be checked >if there are asynchronous requests already scheduled for reading, >and if yes, ReadFile() should _not_ try to read immediately but go >pending. Of course, this check would require a server call. > >The same reasoning applies for writing, of course. > >Things become even more confusing if you think of several threads >reading from the same file. > >A very simple workaround would be to go pending unconditonally for >overlapped requests. Although not optimal, this would be certain >not to corrupt data. > >What do you think? > >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 2

A new async patch - feedback, please :-)
by Martin Wilck 09 Jan '02

09 Jan '02

Hi Mike, all, Unfortunately this patch has become big, because i came across so many problems today and I just needed to go forward. I am sorry for this, but it has become very late tonight, and I want people to see this stuff to stop me before it's too late (if I'm on the wrong track). It compiles without warnings, but I have not tested it - may crash wine right away, I don't know. However it should illustrate my ideas well: * Full separation of async handling and file io-specific stuff. * Do not rely on LPOVERLAPPED for status data in generic code, it may be NULL. File IO code may rely on it, here it is required to be non-NULL. * Use GetOverlappedResult() to check for immediate completion (UNTESTED!) Please give me comments telling me which parts you don't like, so that I can adjust for further development. Mike, can you tell me about those apps that were causing trouble in the past ? Where can I obtain them? Do they need special hardware (modem, mouse) for test runs ? Cheers, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy ChangeLog: server/protocol.def: cancel_async(): Define new reqest type. server/async.c: cancel_async(): Implement new reqest type. include/file.h: struct async_ops: 4 methods for async_private: get_status, set_status, get_count, call_completion. struct async_private: contains only those elements which are absolutely necessary for queueing and server interaction struct async_fileio: contains all other fields. scheduler/synchro.c: register_async(): replacement for FILE_StartAsync(). Uses STATUS_USER_APC as (pseudo-) indicator to queue a new request. Hooks new requests in NtCurrentTeb()->pending_list (formerly done in calling functions). Not used by CancelIo() anymore. Finishes requests that are not in PENDING state after scheduling. finish_async(): Assume status is already set correctly. Queue call_completion unconditionally (No completion_func check needed) check_async(): Use register_async() for rescheduling. files/file.c: GetOverlappedResult(): Return ERROR_IO_INCOMPLETE if IO still pending (MSDN docs) FILE_StartAsync(): -> scheduler/synchro.c: register_async CancelIo(): Use new cancel_async server request (I felt former StartAsync() was too overloaded). Skip requests with wrong handle. fileio_call_completion_func(): Now called unconditionally, check if completion_func is non-NULL. FILE_AsyncReadService(): type adjustments according to new API FILE_AsyncWriteService(): dito FILE_ReadFileEx(): use new async API. Call GetOverlappedResult() to check for immediate completion. FILE_WriteFileEx(): dito. Now exactly equivalent to FILE_ReadFileEx() kernel/comm.c: COMM_WaitCommEventService(): Use new async API. diff -ruX diffignore CVS/wine/dlls/kernel/comm.c MW/wine/dlls/kernel/comm.c --- CVS/wine/dlls/kernel/comm.c Tue Jan 8 18:53:41 2002 +++ MW/wine/dlls/kernel/comm.c Wed Jan 9 21:20:37 2002 @@ -1514,12 +1514,13 @@ */ static void COMM_WaitCommEventService(async_private *ovp) { - LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_fileio *fileio = (async_fileio*) ovp; + LPOVERLAPPED lpOverlapped = fileio->lpOverlapped; TRACE("overlapped %p\n",lpOverlapped); /* FIXME: detect other events */ - *ovp->buffer = EV_RXCHAR; + *fileio->buffer = EV_RXCHAR; lpOverlapped->Internal = STATUS_SUCCESS; } @@ -1536,7 +1537,7 @@ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { int fd,ret; - async_private *ovp; + async_fileio *ovp; if(!lpOverlapped) { @@ -1547,52 +1548,35 @@ if(NtResetEvent(lpOverlapped->hEvent,NULL)) return FALSE; - lpOverlapped->Internal = STATUS_PENDING; - lpOverlapped->InternalHigh = 0; - lpOverlapped->Offset = 0; - lpOverlapped->OffsetHigh = 0; - fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); if(fd<0) return FALSE; - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { close(fd); return FALSE; } + + ovp->async.ops = &fileio_async_ops; + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_WAIT; + ovp->async.func = COMM_WaitCommEventService; + ovp->lpOverlapped = lpOverlapped; - ovp->func = COMM_WaitCommEventService; ovp->buffer = (char *)lpdwEvents; - ovp->fd = fd; ovp->count = 0; ovp->completion_func = 0; - ovp->type = ASYNC_TYPE_WAIT; - ovp->handle = hFile; - - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev=ovp; - NtCurrentTeb()->pending_list = ovp; - /* start an ASYNCHRONOUS WaitCommEvent */ - SERVER_START_REQ( register_async ) - { - req->handle = hFile; - req->overlapped = lpOverlapped; - req->type = ASYNC_TYPE_WAIT; - req->count = 0; - req->func = check_async_list; - req->status = STATUS_PENDING; - - ret=wine_server_call_err(req); - } - SERVER_END_REQ; + lpOverlapped->Internal = STATUS_USER_APC; + lpOverlapped->InternalHigh = 0; + lpOverlapped->Offset = 0; + lpOverlapped->OffsetHigh = 0; - if (!ret) - SetLastError(ERROR_IO_PENDING); + if (register_async (&ovp->async)) + SetLastError(ERROR_IO_PENDING); return FALSE; } diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Tue Jan 8 18:57:47 2002 +++ MW/wine/files/file.c Wed Jan 9 20:55:09 2002 @@ -60,6 +60,20 @@ static HANDLE dos_handles[DOS_TABLE_SIZE]; +/* Async operations struct (see file.h) */ + +static DWORD fileio_get_async_status (async_private *ovp); +static DWORD fileio_get_async_count (async_private *ovp); +static void fileio_set_async_status (async_private *ovp, DWORD status); +static void CALLBACK fileio_call_completion_func (ULONG_PTR data); + +async_ops fileio_async_ops = +{ + fileio_get_async_status, /* get_status */ + fileio_set_async_status, /* set_status */ + fileio_get_async_count, /* get_count */ + fileio_call_completion_func /* call_completion */ +}; /*********************************************************************** * FILE_ConvertOFMode @@ -1244,35 +1258,13 @@ if(lpTransferred) *lpTransferred = lpOverlapped->InternalHigh; - SetLastError(lpOverlapped->Internal); + /* This is what the function should return accirding to MSDN specs */ + if ( lpOverlapped->Internal == STATUS_PENDING ) + SetLastError (ERROR_IO_INCOMPLETE); return (r==WAIT_OBJECT_0); } - -/*********************************************************************** - * FILE_StartAsync (INTERNAL) - * - * type==ASYNC_TYPE_NONE means cancel the indicated overlapped operation - * lpOverlapped==NULL means all overlappeds match - */ -BOOL FILE_StartAsync(HANDLE hFile, LPOVERLAPPED lpOverlapped, DWORD type, DWORD count, DWORD status) -{ - BOOL ret; - SERVER_START_REQ(register_async) - { - req->handle = hFile; - req->overlapped = lpOverlapped; - req->type = type; - req->count = count; - req->func = check_async_list; - req->status = status; - ret = wine_server_call( req ); - } - SERVER_END_REQ; - return !ret; -} - /*********************************************************************** * CancelIo (KERNEL32.@) */ @@ -1282,21 +1274,60 @@ TRACE("handle = %x\n",handle); - ovp = NtCurrentTeb()->pending_list; - while(ovp) + + for (ovp = NtCurrentTeb()->pending_list; ovp; ovp = t) { t = ovp->next; - if(FILE_StartAsync(handle, ovp->lpOverlapped, ovp->type, 0, STATUS_CANCELLED)) + if (ovp->handle != handle) continue; + + SERVER_START_REQ ( cancel_async ) { - TRACE("overlapped = %p\n",ovp->lpOverlapped); - finish_async(ovp, STATUS_CANCELLED); + req->handle = handle; + req->type = ovp->type; + req->overlapped = ovp; + wine_server_call ( req ); + if (reply->cancelled) + { + TRACE ("cancelling request: %p\n", ovp); + ovp->ops->set_status ( ovp, STATUS_CANCELLED ); + finish_async (ovp); + } } - ovp = t; + SERVER_END_REQ; } WaitForMultipleObjectsEx(0,NULL,FALSE,1,TRUE); return TRUE; } +static DWORD fileio_get_async_status (async_private *ovp) +{ + return ((async_fileio*) ovp)->lpOverlapped->Internal; +} + +static void fileio_set_async_status (async_private *ovp, DWORD status) +{ + ((async_fileio*) ovp)->lpOverlapped->Internal = status; +} + +static DWORD fileio_get_async_count (async_private *ovp) +{ + async_fileio *fileio = (async_fileio*) ovp; + DWORD ret = fileio->count - fileio->lpOverlapped->InternalHigh; + return (ret < 0 ? 0 : ret); +} + +static void CALLBACK fileio_call_completion_func (ULONG_PTR data) +{ + async_fileio *ovp = (async_fileio*) data; + TRACE ("data: %p\n", ovp); + + if (ovp->completion_func) + ovp->completion_func(ovp->lpOverlapped->Internal, + ovp->lpOverlapped->InternalHigh, + ovp->lpOverlapped); + HeapFree(GetProcessHeap(), 0, ovp); +} + /*********************************************************************** * FILE_AsyncReadService (INTERNAL) * @@ -1305,18 +1336,19 @@ */ static void FILE_AsyncReadService(async_private *ovp) { - LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_fileio *fileio = (async_fileio*) ovp; + LPOVERLAPPED lpOverlapped = fileio->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("%p %p\n", lpOverlapped, ovp->buffer ); + TRACE("%p %p\n", lpOverlapped, fileio->buffer ); /* check to see if the data is ready (non-blocking) */ - result = pread (ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pread (ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); + result = read (ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1334,9 +1366,9 @@ } lpOverlapped->InternalHigh += result; - TRACE("read %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); + TRACE("read %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,fileio->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1352,7 +1384,7 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; int fd; TRACE("file %d to buf %p num %ld %p func %p\n", @@ -1369,10 +1401,11 @@ if(fd<0) { TRACE("Couldn't get FD\n"); + SetLastError( ERROR_INVALID_HANDLE ); return FALSE; } - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); @@ -1380,30 +1413,23 @@ close(fd); return FALSE; } + + ovp->async.ops = &fileio_async_ops; + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_READ; + ovp->async.func = FILE_AsyncReadService; + ovp->lpOverlapped = overlapped; - ovp->count = bytesToRead; ovp->completion_func = lpCompletionRoutine; - ovp->func = FILE_AsyncReadService; ovp->buffer = buffer; - ovp->fd = fd; - ovp->type = ASYNC_TYPE_READ; - ovp->handle = hFile; - - /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->count = bytesToRead; - if ( !FILE_StartAsync(hFile, overlapped, ASYNC_TYPE_READ, bytesToRead, STATUS_PENDING) ) - { - /* FIXME: remove async_private and release memory */ - ERR("FILE_StartAsync failed\n"); - return FALSE; - } + /* Tell register_async that this is a new request */ + overlapped->Internal = STATUS_USER_APC; - return TRUE; + /* The request is hooked into the pending list by register_async() */ + return register_async (&ovp->async); } /*********************************************************************** @@ -1413,7 +1439,6 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = 0; return FILE_ReadFileEx(hFile,buffer,bytesToRead,overlapped,lpCompletionRoutine); } @@ -1470,41 +1495,21 @@ return FALSE; } - /* see if we can read some data already (this shouldn't block) */ - result = pread( unix_handle, buffer, bytesToRead, OVERLAPPED_OFFSET(overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = read( unix_handle, buffer, bytesToRead ); close(unix_handle); - - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadWritePtr( buffer, bytesToRead )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } + overlapped->InternalHigh = 0; - /* if we read enough to keep the app happy, then return now */ - if(result>=bytesToRead) - { - *bytesRead = result; - return TRUE; - } + if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, FILE_OverlappedComplete)) + return FALSE; - /* at last resort, do an overlapped read */ - overlapped->Internal = STATUS_PENDING; - overlapped->InternalHigh = result; - if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, FILE_OverlappedComplete)) + if ( !GetOverlappedResult (hFile, overlapped, bytesRead, FALSE) ) + { + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); return FALSE; + } - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; + return TRUE; } else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) @@ -1554,18 +1559,19 @@ */ static void FILE_AsyncWriteService(struct async_private *ovp) { - LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_fileio *fileio = (async_fileio *) ovp; + LPOVERLAPPED lpOverlapped = fileio->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); + TRACE("(%p %p)\n",lpOverlapped,fileio->buffer); /* write some data (non-blocking) */ - result = pwrite(ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pwrite(ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = write(ovp->fd, &ovp->buffer[already], ovp->count - already); + result = write(ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1582,9 +1588,9 @@ lpOverlapped->InternalHigh += result; - TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); + TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,fileio->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1600,7 +1606,8 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; + int fd; TRACE("file %d to buf %p num %ld %p func %p stub\n", hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine); @@ -1611,45 +1618,39 @@ return FALSE; } - overlapped->Internal = STATUS_PENDING; - overlapped->InternalHigh = 0; - - if (!FILE_StartAsync(hFile, overlapped, ASYNC_TYPE_WRITE, bytesToWrite, STATUS_PENDING )) + fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); + if(fd<0) { - TRACE("FILE_StartAsync failed\n"); + TRACE("Couldn't get FD\n"); + SetLastError( ERROR_INVALID_HANDLE ); return FALSE; } - ovp = (async_private*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); SetLastError(ERROR_NOT_ENOUGH_MEMORY); + close(fd); return FALSE; } + + ovp->async.ops = &fileio_async_ops; + ovp->async.handle = hFile; + ovp->async.fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); + ovp->async.type = ASYNC_TYPE_WRITE; + ovp->async.func = FILE_AsyncWriteService; + ovp->lpOverlapped = overlapped; - ovp->func = FILE_AsyncWriteService; ovp->buffer = (LPVOID) buffer; - ovp->count = bytesToWrite; ovp->completion_func = lpCompletionRoutine; - ovp->fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); - ovp->type = ASYNC_TYPE_WRITE; - ovp->handle = hFile; - - if(ovp->fd <0) - { - HeapFree(GetProcessHeap(), 0, ovp); - return FALSE; - } + ovp->count = bytesToWrite; - /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + /* Tell register_async that this is a new request */ + overlapped->Internal = STATUS_USER_APC; - return TRUE; + /* The request is hooked into the pending list by register_async() */ + return register_async (&ovp->async); } /*********************************************************************** @@ -1659,7 +1660,6 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = 0; return FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine); @@ -1693,44 +1693,20 @@ return FALSE; } - /* see if we can write some data already (this shouldn't block) */ - - result = pwrite( unix_handle, buffer, bytesToWrite, OVERLAPPED_OFFSET (overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = write( unix_handle, buffer, bytesToWrite ); - close(unix_handle); - - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadReadPtr( buffer, bytesToWrite )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } - - /* if we wrote enough to keep the app happy, then return now */ - if(result>=bytesToWrite) - { - *bytesWritten = result; - return TRUE; - } - - /* at last resort, do an overlapped read */ - overlapped->Internal = STATUS_PENDING; - overlapped->InternalHigh = result; + overlapped->InternalHigh = 0; - if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, FILE_OverlappedComplete)) + if (!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, FILE_OverlappedComplete)) return FALSE; + + if ( !GetOverlappedResult (hFile, overlapped, bytesWritten, FALSE) ) + { + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); + return FALSE; + } - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; - + return TRUE; } else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) diff -ruX diffignore CVS/wine/include/file.h MW/wine/include/file.h --- CVS/wine/include/file.h Wed Jan 9 21:27:50 2002 +++ MW/wine/include/file.h Wed Jan 9 20:25:05 2002 @@ -33,23 +33,46 @@ /* overlapped private structure */ struct async_private; -typedef void (*async_handler)(struct async_private *ovp); + +typedef void (*async_handler) (struct async_private *ovp); +typedef void CALLBACK (*async_call_completion_func) (ULONG_PTR data); +typedef DWORD (*async_get_status) (struct async_private *ovp); +typedef DWORD (*async_get_count) (struct async_private *ovp); +typedef void (*async_set_status) (struct async_private *ovp, DWORD status); + +typedef struct async_ops +{ + async_get_status get_status; + async_set_status set_status; + async_get_count get_count; + async_call_completion_func call_completion; +} async_ops; + +extern async_ops fileio_async_ops; + typedef struct async_private { - LPOVERLAPPED lpOverlapped; - HANDLE handle; - int fd; - char *buffer; - async_handler func; - int count; - int type; - LPOVERLAPPED_COMPLETION_ROUTINE completion_func; - struct async_private *next; - struct async_private *prev; + async_ops *ops; + HANDLE handle; + int fd; + int type; + async_handler func; + struct async_private *next; + struct async_private *prev; } async_private; -extern void WINAPI check_async_list(LPOVERLAPPED ov, DWORD status); -extern void finish_async(struct async_private *ovp, DWORD status); +typedef struct async_fileio +{ + async_private async; + LPOVERLAPPED lpOverlapped; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + char *buffer; + int count; +} async_fileio; + +extern BOOL register_async (async_private *ovp); +extern void WINAPI check_async_list(async_private *ovp, DWORD status); +extern void finish_async(async_private *ovp); /* locale-independent case conversion */ inline static char FILE_tolower( char c ) @@ -83,7 +106,6 @@ DWORD attributes, HANDLE template, BOOL fail_read_only, UINT drive_type ); extern HANDLE FILE_CreateDevice( int client_id, DWORD access, LPSECURITY_ATTRIBUTES sa ); -extern BOOL FILE_StartAsync(HANDLE handle, LPOVERLAPPED lpOverlapped, DWORD type, DWORD count, DWORD status); extern LONG WINAPI WIN16_hread(HFILE16,SEGPTR,LONG); diff -ruX diffignore CVS/wine/scheduler/synchro.c MW/wine/scheduler/synchro.c --- CVS/wine/scheduler/synchro.c Tue Jan 8 18:53:41 2002 +++ MW/wine/scheduler/synchro.c Wed Jan 9 20:27:16 2002 @@ -36,27 +36,60 @@ } } -static void CALLBACK call_completion_routine(ULONG_PTR data) +/*********************************************************************** + * register_async (INTERNAL) + * + * Manipulate async request queues. + */ +BOOL register_async (async_private *ovp) { - async_private* ovp = (async_private*)data; + BOOL ret; + DWORD status = ovp->ops->get_status (ovp); - ovp->completion_func(ovp->lpOverlapped->Internal, - ovp->lpOverlapped->InternalHigh, - ovp->lpOverlapped); - ovp->completion_func=NULL; - HeapFree(GetProcessHeap(), 0, ovp); -} + /* STATUS_USER_APC means this is a new request */ + /* STATUS_PENDING means this request is rescheduled (IO incomplete) */ -void finish_async(async_private *ovp, DWORD status) -{ - ovp->lpOverlapped->Internal=status; + if (status == STATUS_USER_APC) + { + status = STATUS_PENDING; + ovp->ops->set_status (ovp, status); + + /* hook this overlap into the pending async operation list */ + ovp->next = NtCurrentTeb()->pending_list; + ovp->prev = NULL; + if (ovp->next) ovp->next->prev = ovp; + NtCurrentTeb()->pending_list = ovp; + } - /* call ReadFileEx/WriteFileEx's overlapped completion function */ - if(ovp->completion_func) + /* The server call will destroy all except PENDING requests */ + SERVER_START_REQ(register_async) { - QueueUserAPC(call_completion_routine,GetCurrentThread(),(ULONG_PTR)ovp); + req->handle = ovp->handle; + req->overlapped = ovp; + req->type = ovp->type; + req->count = ovp->ops->get_count (ovp); + req->func = check_async_list; + req->status = status; + ret = wine_server_call( req ); } + SERVER_END_REQ; + + if (ret) ovp->ops->set_status ( ovp, GetLastError() ); + + if ( ovp->ops->get_status (ovp) != STATUS_PENDING ) + finish_async (ovp); + return !ret; +} + +/*********************************************************************** + * finish_async (INTERNAL) + * + * Called after completion or cancellation of an async request. + * Note: The completion status must be set already. + */ +void finish_async(async_private *ovp) +{ /* remove it from the active list */ if(ovp->prev) ovp->prev->next = ovp->next; @@ -70,7 +103,9 @@ ovp->prev=NULL; close(ovp->fd); - if(!ovp->completion_func) HeapFree(GetProcessHeap(), 0, ovp); + + /* Queue completion function unconditionally */ + QueueUserAPC(ovp->ops->call_completion, GetCurrentThread(), (ULONG_PTR)ovp); } /*********************************************************************** @@ -78,30 +113,33 @@ * * Process a status event from the server. */ -void WINAPI check_async_list(LPOVERLAPPED overlapped, DWORD status) +void WINAPI check_async_list(async_private *asp, DWORD status) { - async_private *ovp; + async_private *ovp = NULL; + DWORD ovp_status; /* fprintf(stderr,"overlapped %p status %x\n",overlapped,status); */ - for(ovp = NtCurrentTeb()->pending_list; ovp; ovp = ovp->next) - if(ovp->lpOverlapped == overlapped) - break; + for( ovp = NtCurrentTeb()->pending_list; ovp && ovp != asp; ovp = ovp->next ); - if(!ovp) - return; + if(!ovp) return; if(status != STATUS_ALERTED) - ovp->lpOverlapped->Internal = status; + { + ovp_status = status; + ovp->ops->set_status (ovp, status); + } + else ovp_status = ovp->ops->get_status (ovp); - if(ovp->lpOverlapped->Internal==STATUS_PENDING) - { + if( ovp_status == STATUS_PENDING) + { ovp->func(ovp); - FILE_StartAsync(ovp->handle, ovp->lpOverlapped, ovp->type, 0, ovp->lpOverlapped->Internal); - } + register_async (ovp); + ovp_status = ovp->ops->get_status (ovp); + } - if(ovp->lpOverlapped->Internal!=STATUS_PENDING) - finish_async(ovp,ovp->lpOverlapped->Internal); + if( ovp_status != STATUS_PENDING ) + finish_async(ovp); } diff -ruX diffignore CVS/wine/server/async.c MW/wine/server/async.c --- CVS/wine/server/async.c Wed Jan 2 12:50:04 2002 +++ MW/wine/server/async.c Wed Jan 9 20:04:53 2002 @@ -177,3 +177,28 @@ release_object(obj); } +DECL_HANDLER(cancel_async) +{ + struct object *obj; + + if (!(obj = get_handle_obj( current->process, req->handle, 0, NULL)) ) + return; + + if(obj->ops->queue_async) + { + struct async_queue *q = obj->ops->queue_async(obj, NULL, req->type, 0); + struct async *async; + + async = find_async(q, current, req->overlapped); + if (async) + { + destroy_async(async); + reply->cancelled = 1; + set_select_events(obj,obj->ops->get_poll_events(obj)); + } + else reply->cancelled = 0; + } + + release_object(obj); +} + diff -ruX diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Tue Jan 8 18:58:28 2002 +++ MW/wine/server/protocol.def Wed Jan 9 19:52:33 2002 @@ -1535,7 +1535,7 @@ #define SERIALINFO_SET_ERROR 0x04 -/* Create/Destroy an async I/O */ +/* Create / reschedule an async I/O */ @REQ(register_async) handle_t handle; /* handle to comm port, socket or file */ void* func; @@ -1549,6 +1549,14 @@ #define ASYNC_TYPE_WRITE 0x02 #define ASYNC_TYPE_WAIT 0x03 +/* Cancel an async I/O */ +@REQ(cancel_async) + handle_t handle; + int type; + void* overlapped; +@REPLY + int cancelled; +@END /* Create a named pipe */ @REQ(create_named_pipe)

1 0

Re: We *really* need a development model change !
by Andriy Palamarchuk 09 Jan '02

09 Jan '02

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > But I think implementing it now would actually make > your life easier. > This way you wouldn't have to require some magic > call to detect you > are running on Wine, you could simply rely on the > Wine makefiles to > pass you the right option. I don't see any value in information about the first TODO check in a test script. I, personally, prefer using "magic call". One more plus of autodetection - I can run the same Windows test binary on Windows and on Wine without any troubles. But I'd like to use your idea in other place. I feel uncomfortable when test does not show anything. It is not clear whether it runs any checks, whether my last changes were executed. I suggest to have switch which turns off output. By default the test will print some statistics on successful run - number of tests running, number of TODO tests, time of execution - anything else? Make script can run test with output turned off. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

1 0

Re: We *really* need a development model change !
by Andriy Palamarchuk 09 Jan '02

09 Jan '02

Alexandre Julliard wrote: > I don't really care about the output. My point is that this output is > not necessary, a simple "assertion foo failed at line xx" on failure > and no output at all on success would work just as well. I've nothing > against such an output either, but I don't think it justifies > introducing the complexity of reusing the Test stuff. I already created small library with api like in Test::Simple - functions ok, TODO, SKIP. The implementation can be easy changed to the behaviour you described. I also suggest for library to fail on successful TODO test. TODO tests will be conditional - they are TODO only under Wine, not on Windows. Careful usage SKIP sections can easy cover differences between Windows platforms, using TODO - between different non-Microsoft Win32 implementations. On other hand, SKIP sections were important for Test::Harness, which needed to control number of tests. For your goals conditional execution of the tests is sufficient. Which approaches can you suggest to reach goals I believe are important: 1) bundling - are we going to have separate distributions - Wine with tests, tests only, Wine only? There are a lot of cases where only one of them is required. 2) development of the unit tests under Windows. Obviously, we don't need to have Wine itself when we work with unit tests on Windows. Plus, we need to create development environment, usable by Windows developers. 3) Organization of the unit tests in such way, so they can be used by other Win32 implementation projects. Conditional TODOs I suggested above will help to manage different TODO lists for different projects. 4) besides narrow-scope regression testing you suggested we need to run all the tests from time to time, even if it takes more than 1 hour to run the whole suite. The reasons for this are: a) we need to run the tests on all Windows platforms to make sure the tests correctly document their behaviour b) Wine should be reguraly tested by the whole testing suite. Some regressions will be caught in unit tests of the modules other than changed. In other cases changed module may not have tests at all, but will brake modules, dependent on it. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 5

Listview ctrl
by Dimitrie O. Paun 09 Jan '02

09 Jan '02

Hi folks, While I looking for something _small_ to do, I discovered that listview.c had two of those HEAP_strdupXXX calls that Alexandre hates so much. I figured that's got to be a 2 minute job, but I was wrong -- it turns out that the listview control needed to get Unicode enabled. So, after much work and no testing, here is a first try at doing that. The good news is that it seems it compiles. The bad news is that I have no idea how to test it. So any suggestions on how to test the listview control, or any help with the testing is greatly appreciated, as well as any comments on the patch itself. Alexandre, why is it that you want so badly to get rid of the HEAP_strdup functions? I mean, in certain cases they are not needed, and they rather signal that the code needs fixing, but in other places they _are_ needed and they convey a heck of a lot better what we're trying to do then the strange WideCharXXX function calls. -- Dimi

3 10

Re: lpOverlapped = NULL
by Mike McCormack 09 Jan '02

09 Jan '02

Hi Martin, Sure, feel free to change it. I used the lpOverlapped to identify the async operation, but any pointer will do. The only reason for not using async_private* was to have some way to verify that the pointer was valid... Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Mike, > >I should have been aware of this before :-/ > >As mentioned in my other mail, >** Winsock allows NULL pointers for lpOverlapped. ** > >AFAICS, Mike, your server-side code uses the overlapped field >only for identifying a certain request. This will obviously >break if the overlapped field may be NULL. > >Question: Would it hurt to use the async_private pointer of a >request rather than the overlapped pointer to pass to the >server? If no, I guess that would be the way to go, because >the async_private structs are allocated by us and therefore necessarily >different and non-NULL. > >Wrt to the status and "bytes read", I already have a pretty elegant >solution which keeps the overlapped struct outside the generic code >(scheduler and server). > >Please comment, >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

lpOverlapped = NULL
by Martin Wilck 09 Jan '02

09 Jan '02

Mike, I should have been aware of this before :-/ As mentioned in my other mail, ** Winsock allows NULL pointers for lpOverlapped. ** AFAICS, Mike, your server-side code uses the overlapped field only for identifying a certain request. This will obviously break if the overlapped field may be NULL. Question: Would it hurt to use the async_private pointer of a request rather than the overlapped pointer to pass to the server? If no, I guess that would be the way to go, because the async_private structs are allocated by us and therefore necessarily different and non-NULL. Wrt to the status and "bytes read", I already have a pretty elegant solution which keeps the overlapped struct outside the generic code (scheduler and server). Please comment, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

struct async_private needs generalization for Winsock
by Martin Wilck 09 Jan '02

09 Jan '02

Hi Mike, all, as I pointed out before, we must change the async_private type such that it accomodates the different needs of normal (e.g. ReadFileEx()) and Winsock (e.g. WSARecv()) async requests. The "generic" functions in scheduler/synchro.c must be able to handle these structures without knowing what type of async_private structure they have been passed. I try to summarize the differences between the two request types here: 1. Winsock async requests have a WSAOVERLAPPED struct rather than OVERLAPPED. Unlike File I/O, the routines complete if any positive number of bytes is read (there's no such thing as BytesToRead). 2. Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any way, except for the hEvent field. The other fields do not carry useful information and are, according to the Winsock2 specs, reserved to service providers, i.e. we are not allowed to write to them. 3. Winsock functions take a scatter/gather array of type WSABUF* instead of a single buffer, and a number of WSABUFs instead of the number of bytes to read. 4. The completion routine takes an additional DWORD argument. 5. In the case of WSARecvFrom()/WSASendTo(), the socket address and length parameters passed by the user must be stored and filled in at completion. [These are the differences I've come across so far, there may be more.] I'd therefore recommend the following, similar to the treatment of "struct object" and derived types in the server code: struct async_private; typedef void (*async_handler)(struct async_private *ovp); struct async_private { unsigned int type; /* file/socket, read/write/... */ HANDLE handle; int fd; struct async_private *prev; struct async_private *next; async_handler func; } struct async_fileio { struct async_private async; char *buffer; int count; LPOVERLAPPED lpOverlapped; LPOVERLAPPED_COMPLETION_ROUTINE completion_func; } struct async_winsock { struct async_private async; LPWSABUF wsabuf; int n_wsabufs; LPWSAOVERLAPPED overlapped; LPWSAOVERLAPPED_COMPLETION_ROUTINE completion_func; struct WS_sockaddr* addr; /* User-specified pointers */ int *addrlen; int flags; /* Return values */ int NumberOfBytesRead; int status; /* cannot be stored in overlapped */ } To my knowledge, there are only these two types of Asynchronous requests. Thus, using a "struct async_ops" like "struct object_ops" in the server code would probably be too much; the type field could instead be used for distinction between the two request types and the "generic" code in scheduler/synchro.c could incorporate respective case distinctions. To my experience this runs faster than code with function pointers if we have only two cases. Actually, we might even do without the "async_handler" field and decide which function to call only according to the "type" field, but that's a cosmetic issue. Unless anybody objects, I'll soon submit a patch incorporating this approach. Comments welcome, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

4 7

Re: We *really* need a development model change !
by Gerard Patel 09 Jan '02

09 Jan '02

At 04:44 PM 08/01/2002 -0500, you wrote: <snip> >(Another Pythoner, cool :) ) This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine. >From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool. Gerard

4 4

Immediate IO in ReadFile / WriteFile
by Martin Wilck 09 Jan '02

09 Jan '02

Hi Mike, I just had the following thought on the immediate IO in ReadFile() / WriteFile() that you implemented: Consider the following situation: 1. There is no data available for reading on some fd (serial port, pipe, socket). 2. An application calls ReadFile() in overlapped mode. since no data is there, an overlapped request is scheduled. 3. Data becomes available before the app issues a wait request of any kind. 4. The application starts another ReadFile() request. Now data is there, and will be read immediately. No async request is scheduled. 5. Eventually, more data will become available, and the async request first scheduled will also return. However, this basically destroys the order of the requests. I am unsure how Windows would behave in such a case, and it is certainly difficult to provide a test case for this situation. It can occur, though, and my guess is this is the wrong behaviour. Thus, probably before doing the immediate read it should be checked if there are asynchronous requests already scheduled for reading, and if yes, ReadFile() should _not_ try to read immediately but go pending. Of course, this check would require a server call. The same reasoning applies for writing, of course. Things become even more confusing if you think of several threads reading from the same file. A very simple workaround would be to go pending unconditonally for overlapped requests. Although not optimal, this would be certain not to corrupt data. What do you think? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 1

Re: wine/ files/file.c server/file.c
by Martin Wilck 09 Jan '02

09 Jan '02

On 8 Jan 2002, Alexandre Julliard wrote: > I'm not sure 002 is a good idea. It seems to encourage doing > distinctions between file types where we should instead try to handle > them in a common way. The whole point of the FD_TYPE_XYZ distinction, as it currently is, is that at some places (actually, only in WriteFile() and ReadFile()), a distinction according to fd type _must_ be made. I am not sure if Windows allows overlapped IO on the console, for example, but if yes, this patch would be a prerequisite to implement that. I just wanted to make this distinction more logical. I think it is necessary to separate fd types and flags. The distinction between regular files, pipes, sockets, ... that the patch introduces is currently not needed, but doesn't hurt IMO. If you wish, I can strip the patch down to its essential part (have separate flags for overlapped and timeout flags). I guess I could also proceed entirely without this patch, if you seriously reject it as a whole, but I fear this will bring trouble sooner or later. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

Re: We *really* need a development model change !
by Andriy Palamarchuk 09 Jan '02

09 Jan '02

Spent a couple of days trying to port my test to C unit testing framework "Check". Simple tests work fine. Problems start when I try to use multithreaded Wine tests. In one case the framework stucks on reading from pipe. Other code layouts have other issues. The cause may be in incorrect pipes handling, multi-process tests handling or interaction with Wine thread implementation. I remember I also had some problems with Perl multithreaded tests... I attached my unit test example, almost identical to the one I published before for Perl framework. There is also a whole working directory. If you want to play with the it, just unpack it to wine/programs directory. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

5 14

Re: Listview ctrl
by Gerard Patel 09 Jan '02

09 Jan '02

At 09:31 AM 08/01/2002 -0500, you wrote: <snip> >So, after much work and no testing, here is a first try at doing that. The >good news is that it seems it compiles. The bad news is that I have no >idea how to test it. So any suggestions on how to test the listview >control, or any help with the testing is greatly appreciated, as well as >any comments on the patch itself. > I have tested it with some of my test apps and I see a few regressions. With rowlist.exe that comes with Vc++, using 'large icons' and 'full details' only the first character of the text is displayed. The little program found at www.timex.com (IIRC it installs correctly under Wine) displays another problem (maybe related) : columns other than the first can be not displayed in some cases. Gerard

1 0

Wine & non X86 processors
by Hetz Ben Hamo 09 Jan '02

09 Jan '02

Hi, A friend of mine who uses sparc machine wants to write a pentium emulator & use wine with it to run some apps... His question is - are there any special notes about wine in big endian? does he need to make lots of changes? if so, in whats parts in general? Thanks, Hetz

3 2

Linux Today - Tonight Live: New Directions for a New Year. We talk about WINE >> on The Linux Show
by Jeremy White 08 Jan '02

08 Jan '02

FYI, they're apparently going to be talking about Wine tonight. Jer <http://linuxtoday.com/news_story.php3?ltsn=2002-01-08-024-20-OP-CY>

1 0

RFC: NamedPipes emulation API
by Luke Kenneth Casson Leighton 08 Jan '02

08 Jan '02

this is an RFC document describing an API that may be used to provide Windows NT Style "NamedPipe" functionality. it will be of interest to samba, wine, freedce and win32 developers wishing to port applications to unix (via the wine win32 implementation of NamedPipes). the functionality described in this document is equivalent to, if you have access to the MSDN, the following (incomplete list of) Win32 functions: - CreateNamedPipe (returns a file handle) - TransactNamedPipe - a read operation on the named pipe file handle, above - a write operation on the named pipe file handle, above - a close operation on the named pipe file handle, above - WaitNamedPipe there follows a list of function declarations. these are samba-specific functions that are only of use to SAMBA 3 developers. int named_pipe_create( connection_struct *connection, /* contains all info needed, e.g. user security context */ const char *pipe_name, /* e.g. \\server\PIPE\pipe_name or \\.\PIPE\pipe_name */ ); this function returns -1 on failure or an SMB file index (fnum) on success. it is called when an SMBopenX or NTcreateX is received. from memory, the access point is api_pipe_open(), in pipe.c or reply.c. STATUS named_pipe_transact(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length, /* zero or more bytes */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. if there is more data to be received, then the function must return ERROR_MORE_DATA. NT_STATUS_OK is returned on success. from memory, the access point is api_pipe_readwrite() or reply_trans2(), or maybe reply_pipe_trans(). i don't recall which. again, it'll be in pipe.c or reply.c. STATUS named_pipe_read(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_read() (api_pipe_read()?) STATUS named_pipe_write(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_write() (api_pipe_write()?) the use of this API is quite simple, and provides a clean "cut-off" point between samba and all NamedPipe transactions. lkcl

1 0

RFC: new async_private implementation
by Martin Wilck 08 Jan '02

08 Jan '02

The patch below implements my ideas from the "struct async_private needs generalization for Winsock" thread. It's a patch against CVS 2002-01-08. The Winsock stuff is still missing, that's the next step. This is only a trivial recoding of the File IO (compiles, successfully tested with my async file IO test code), whith the "generic" fields in async_private and the "fileio-specific" fields in the rest of the async_fileio structure. Note: Since it seems agreeable to use the lpOverlapped in Winsock the same way as for file IO, I made lpOverlapped a "generic" field. Mike (or other people interested), if you can test this against your serial port code I'd be grateful. Martin Patch file: async_private.diff Purpose: New winsock-friendly async_private implementation Created: 2002-01-08 Applies: CVS 2002-01-08 ChangeLog: wine/include/file.h: struct async_private: - remove buffer, count, completion_func fields. - add call_completion field (callback function that calls the completion function). struct async_fileio: - "Derived" from async_private, contains. remove buffer, count, completion_func fields. wine/scheduler/synchro.c: call_completion_routine(): function removed. finish_async(): use ovp->completion_func instead of call_completion_routine. check_async_list(): Initialize ovp. wine/files/file.c: fileio_call_completion_func(): New function, FileIO-specific callback. FILE_AsyncReadService(): - use struct async_fileio for specific fields. FILE_AsyncWriteService(): - dito. FILE_ReadFileEx(): - use async_fileio struct for overlapped initialization. - initialize ovp->call_completion field. FILE_WriteFileEx(): - dito. dlls/kernel/comm.c: COMM_WaitCommEventService(): - use struct async_fileio for "buffer" field. COMM_WaitCommEvent(): - see FILE_ReadFileEx(). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/dlls/kernel/comm.c MW/wine/dlls/kernel/comm.c --- CVS/wine/dlls/kernel/comm.c Tue Jan 8 17:43:25 2002 +++ MW/wine/dlls/kernel/comm.c Tue Jan 8 17:47:41 2002 @@ -1515,11 +1515,12 @@ static void COMM_WaitCommEventService(async_private *ovp) { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_fileio *fileio = (async_fileio*) ovp; TRACE("overlapped %p\n",lpOverlapped); /* FIXME: detect other events */ - *ovp->buffer = EV_RXCHAR; + *fileio->buffer = EV_RXCHAR; lpOverlapped->Internal = STATUS_SUCCESS; } @@ -1536,7 +1537,7 @@ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { int fd,ret; - async_private *ovp; + async_fileio *ovp; if(!lpOverlapped) { @@ -1556,26 +1557,27 @@ if(fd<0) return FALSE; - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { close(fd); return FALSE; } - ovp->lpOverlapped = lpOverlapped; - ovp->func = COMM_WaitCommEventService; + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_WAIT; + ovp->async.lpOverlapped = lpOverlapped; + ovp->async.func = COMM_WaitCommEventService; + ovp->async.call_completion = NULL; ovp->buffer = (char *)lpdwEvents; - ovp->fd = fd; ovp->count = 0; ovp->completion_func = 0; - ovp->type = ASYNC_TYPE_WAIT; - ovp->handle = hFile; - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev=ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev=&ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; /* start an ASYNCHRONOUS WaitCommEvent */ SERVER_START_REQ( register_async ) diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Tue Jan 8 17:43:51 2002 +++ MW/wine/files/file.c Tue Jan 8 17:47:41 2002 @@ -1298,6 +1298,21 @@ } /*********************************************************************** + * fileio_call_completion_func (INTERNAL) + */ +void CALLBACK fileio_call_completion_func (ULONG_PTR data) +{ + async_fileio *ovp = (async_fileio*) data; + TRACE ("data: %p\n", ovp); + + ovp->completion_func(ovp->async.lpOverlapped->Internal, + ovp->async.lpOverlapped->InternalHigh, + ovp->async.lpOverlapped); + ovp->completion_func=NULL; + HeapFree(GetProcessHeap(), 0, ovp); +} + +/*********************************************************************** * FILE_AsyncReadService (INTERNAL) * * This function is called while the client is waiting on the @@ -1305,18 +1320,19 @@ */ static void FILE_AsyncReadService(async_private *ovp) { + async_fileio *fileio = (async_fileio*) ovp; LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("%p %p\n", lpOverlapped, ovp->buffer ); + TRACE("%p %p\n", lpOverlapped, fileio->buffer ); /* check to see if the data is ready (non-blocking) */ - result = pread (ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pread (ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); + result = read (ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1336,7 +1352,7 @@ lpOverlapped->InternalHigh += result; TRACE("read %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1352,7 +1368,7 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; int fd; TRACE("file %d to buf %p num %ld %p func %p\n", @@ -1372,7 +1388,7 @@ return FALSE; } - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); @@ -1380,21 +1396,23 @@ close(fd); return FALSE; } - ovp->lpOverlapped = overlapped; - ovp->count = bytesToRead; + + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_READ; + ovp->async.lpOverlapped = overlapped; + ovp->async.func = FILE_AsyncReadService; + ovp->async.call_completion = (lpCompletionRoutine ? fileio_call_completion_func : NULL); ovp->completion_func = lpCompletionRoutine; - ovp->func = FILE_AsyncReadService; ovp->buffer = buffer; - ovp->fd = fd; - ovp->type = ASYNC_TYPE_READ; - ovp->handle = hFile; + ovp->count = bytesToRead; /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev = &ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; if ( !FILE_StartAsync(hFile, overlapped, ASYNC_TYPE_READ, bytesToRead, STATUS_PENDING) ) { @@ -1550,18 +1568,19 @@ */ static void FILE_AsyncWriteService(struct async_private *ovp) { + async_fileio *fileio = (async_fileio *) ovp; LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); + TRACE("(%p %p)\n",lpOverlapped,fileio->buffer); /* write some data (non-blocking) */ - result = pwrite(ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pwrite(ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = write(ovp->fd, &ovp->buffer[already], ovp->count - already); + result = write(ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1578,9 +1597,9 @@ lpOverlapped->InternalHigh += result; - TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); + TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,fileio->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1596,7 +1615,7 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; TRACE("file %d to buf %p num %ld %p func %p stub\n", hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine); @@ -1616,34 +1635,35 @@ return FALSE; } - ovp = (async_private*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); SetLastError(ERROR_NOT_ENOUGH_MEMORY); return FALSE; } - ovp->lpOverlapped = overlapped; - ovp->func = FILE_AsyncWriteService; + ovp->async.handle = hFile; + ovp->async.fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); + ovp->async.type = ASYNC_TYPE_WRITE; + ovp->async.lpOverlapped = overlapped; + ovp->async.func = FILE_AsyncWriteService; + ovp->async.call_completion = (lpCompletionRoutine ? fileio_call_completion_func : NULL); ovp->buffer = (LPVOID) buffer; ovp->count = bytesToWrite; ovp->completion_func = lpCompletionRoutine; - ovp->fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); - ovp->type = ASYNC_TYPE_WRITE; - ovp->handle = hFile; - if(ovp->fd <0) + if(ovp->async.fd <0) { HeapFree(GetProcessHeap(), 0, ovp); return FALSE; } /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev = &ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; return TRUE; } diff -ruX diffignore CVS/wine/include/file.h MW/wine/include/file.h --- CVS/wine/include/file.h Tue Jan 8 17:43:45 2002 +++ MW/wine/include/file.h Tue Jan 8 17:47:41 2002 @@ -33,20 +33,31 @@ /* overlapped private structure */ struct async_private; -typedef void (*async_handler)(struct async_private *ovp); + +typedef void (*async_handler) (struct async_private *ovp); +typedef void CALLBACK (*async_call_completion_func) (ULONG_PTR data); + +extern void CALLBACK fileio_call_completion_func (ULONG_PTR data); + typedef struct async_private { - LPOVERLAPPED lpOverlapped; - HANDLE handle; - int fd; - char *buffer; - async_handler func; - int count; - int type; - LPOVERLAPPED_COMPLETION_ROUTINE completion_func; - struct async_private *next; - struct async_private *prev; + HANDLE handle; + int fd; + int type; + LPOVERLAPPED lpOverlapped; + async_handler func; + async_call_completion_func call_completion; + struct async_private *next; + struct async_private *prev; } async_private; + +typedef struct async_fileio +{ + async_private async; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + char *buffer; + int count; +} async_fileio; extern void WINAPI check_async_list(LPOVERLAPPED ov, DWORD status); extern void finish_async(struct async_private *ovp, DWORD status); diff -ruX diffignore CVS/wine/scheduler/synchro.c MW/wine/scheduler/synchro.c --- CVS/wine/scheduler/synchro.c Tue Jan 8 17:43:37 2002 +++ MW/wine/scheduler/synchro.c Tue Jan 8 17:47:41 2002 @@ -36,25 +36,14 @@ } } -static void CALLBACK call_completion_routine(ULONG_PTR data) -{ - async_private* ovp = (async_private*)data; - - ovp->completion_func(ovp->lpOverlapped->Internal, - ovp->lpOverlapped->InternalHigh, - ovp->lpOverlapped); - ovp->completion_func=NULL; - HeapFree(GetProcessHeap(), 0, ovp); -} - void finish_async(async_private *ovp, DWORD status) { ovp->lpOverlapped->Internal=status; - /* call ReadFileEx/WriteFileEx's overlapped completion function */ - if(ovp->completion_func) + /* call overlapped completion function */ + if(ovp->call_completion) { - QueueUserAPC(call_completion_routine,GetCurrentThread(),(ULONG_PTR)ovp); + QueueUserAPC(ovp->call_completion,GetCurrentThread(),(ULONG_PTR)ovp); } /* remove it from the active list */ @@ -70,7 +59,7 @@ ovp->prev=NULL; close(ovp->fd); - if(!ovp->completion_func) HeapFree(GetProcessHeap(), 0, ovp); + if(!ovp->call_completion) HeapFree(GetProcessHeap(), 0, ovp); } /*********************************************************************** @@ -80,7 +69,7 @@ */ void WINAPI check_async_list(LPOVERLAPPED overlapped, DWORD status) { - async_private *ovp; + async_private *ovp = NULL; /* fprintf(stderr,"overlapped %p status %x\n",overlapped,status); */

1 0

Patch: BUG in thread_queue_apc()
by Martin Wilck 08 Jan '02

08 Jan '02

The patch below fixes a bug in server/thread.c that causes APCs to be "forgotten". The patch is against today's CVS (2002-01-08). I came across this by testing async file I/O. When submitting several async IO requests, the IO completion routine was called only once for the first submitted request. I cannot oversee if this can break anything elsewhere, but I strongly believe the behaviour with this patch is more sane than without. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: server/thread.c =================================================================== RCS file: /home/wine/wine/server/thread.c,v retrieving revision 1.72 diff -u -r1.72 thread.c --- server/thread.c 2001/12/20 00:07:09 1.72 +++ server/thread.c 2002/01/08 13:35:17 @@ -562,6 +562,8 @@ queue->head = apc; wake_thread( thread ); } + else apc->prev->next = apc; + return 1; }

1 0

Re: struct async_private needs generalization for Winsock
by Mike McCormack 08 Jan '02

08 Jan '02

Hi Martin, That's pretty quick and thorough work! >I try to summarize the differences between the two request types here: > >1. Winsock async requests have a WSAOVERLAPPED struct rather than > OVERLAPPED. Unlike File I/O, the routines complete if any > positive number of bytes is read (there's no such thing as > BytesToRead). That case is similar to serial I/O when timeouts are (interval=-1,const=0,total=0), isn't it? The file I/O code doesn't really handle it properly yet either, as it just falls into a busy loop in the original ReadFile... hmmm. >2. Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any Looks like you sorted this out in the other thread. i'd suggest you use the WSAOVERLAPPED fields in the same way as OVERLAPPED where ever possible, or not use them at all. i think you need the completion status in the Internal member... HasOverlappedCompleted is a macro that checks there. >[These are the differences I've come across so far, there may be more.] The way i've done the serial overlapped code so far is to implement what i *think* should be done, then wait for people to complain about their programs not working. You won't have to wait too long... >I'd therefore recommend the following, similar to the treatment of >"struct object" and derived types in the server code: > >struct async_private; >typedef void (*async_handler)(struct async_private *ovp); .. That looks OK to me. i'm not going to complain about it too much if i'm not doing the work to implement it ;-) Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

RE: Debugger on Solaris
by Patrik Stridvall 07 Jan '02

07 Jan '02

[I'm not sure what you are doing but...] > Robert Lunnon <bobNoSpaM(a)yarrabee.net.au> writes: > > > Here is what the Sun man page says about Ptrace, with > apologies to sun, you > > can find this page at docs.sun.com. Not the comment for > call 0 (TRACEME) and > > ESRCH in the error section > > But there has to be some way to attach to a running process. Yes, ptrace(PTRACE_ATTACH, ...) should work I believe. Haven't tried though. > What > happens when you do an attach in gdb? Does it do a ptrace? I'm not sure. Here is a trace of gdb trying to attach to a bash process (pid 11664).

2 1

Re: Debugger on Solaris
by Robert Lunnon 07 Jan '02

07 Jan '02

> On Fri, 4 Jan 2002 10:49, Alexandre Julliard wrote: > > Robert Lunnon <bobNoSpaM(a)yarrabee.net.au> writes: > > > Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though > > > the process exists which causes the wineserver to assume the process is > > > defunct and delete the app, apparently causing the deadlock (This > > > deadlock will have to be fixed too !). > > > > Are you sure this is not rather an issue of process id vs. thread id? > > I would be surprised if Solaris required TRACEME in this case, since > > this would mean you couldn't attach a debugger to a running process. > >it seems something is missing from your mail <grin> > >-- >Alexandre Julliard >julliard(a)winehq.com Some strange behaviour of my mail client is removing edits from replies Sorry all. Here is what the Sun man page says about Ptrace, with apologies to sun, you can find this page at docs.sun.com. Not the comment for call 0 (TRACEME) and ESRCH in the error section System Calls ptrace(2) NAME ptrace - allows a parent process to control the execution of a child process SYNOPSIS #include <unistd.h> #include <sys/types.h> int ptrace(int request, pid_t pid, int addr, int data); DESCRIPTION The ptrace() function allows a parent process to control the execution of a child process. Its primary use is for the implementation of breakpoint debugging. The child process behaves normally until it encounters a signal (see signal(3HEAD)), at which time it enters a stopped state and its parent is notified via the wait(2) function. When the child is in the stopped state, its parent can examine and modify its "core image" using ptrace(). Also, the parent can cause the child either to terminate or continue, with the possibility of ignoring the signal that caused it to stop. The request argument determines the action to be taken by ptrace() and is one of the following: 0 This request must be issued by the child process if it is to be traced by its parent. It turns on the child's trace flag that stipulates that the child should be left in a stopped state on receipt of a signal rather than the state specified by func (see signal(3C)). The pid, addr, and data arguments are ignored, and a return value is not defined for this request. Peculiar results ensue if the parent does not expect to trace the child. The remainder of the requests can only be used by the parent process. For each, pid is the process ID of the child. The child must be in a stopped state before these requests are made. 1, 2 With these requests, the word at location addr in the address space of the child is returned to the parent process. If instruction and data space are separated, request 1 returns a word from instruction space, and request 2 returns a word from data space. If instruc- tion and data space are not separated, either request 1 or request 2 may be used with equal results. The data argument is ignored. These two requests fail if addr is not the start address of a word, in which case -1 is returned to the parent process and the parent's errno is set to EIO. SunOS 5.8 Last change: 5 Jul 1990 1 System Calls ptrace(2) 3 With this request, the word at location addr in the child's user area in the system's address space (see <sys/user.h>) is returned to the parent process. The data argument is ignored. This request fails if addr is not the start address of a word or is outside the user area, in which case -1 is returned to the parent process and the parent's errno is set to EIO. 4, 5 With these requests, the value given by the data argu- ment is written into the address space of the child at location addr. If instruction and data space are separated, request 4 writes a word into instruction space, and request 5 writes a word into data space. If instruction and data space are not separated, either request 4 or request 5 may be used with equal results. On success, the value written into the address space of the child is returned to the parent. These two requests fail if addr is not the start address of a word. On failure -1 is returned to the parent process and the parent's errno is set to EIO. 6 With this request, a few entries in the child's user area can be written. data gives the value that is to be written and addr is the location of the entry. The few entries that can be written are the general regis- ters and the condition codes of the Processor Status Word. 7 This request causes the child to resume execution. If the data argument is 0, all pending signals including the one that caused the child to stop are canceled before it resumes execution. If the data argument is a valid signal number, the child resumes execution as if it had incurred that signal, and any other pending signals are canceled. The addr argument must be equal to 1 for this request. On success, the value of data is returned to the parent. This request fails if data is not 0 or a valid signal number, in which case -1 is returned to the parent process and the parent's errno is set to EIO. 8 This request causes the child to terminate with the same consequences as exit(2). 9 This request sets the trace bit in the Processor Status Word of the child and then executes the same steps as listed above for request 7. The trace bit causes an interrupt on completion of one machine instruction. This effectively allows single stepping of the child. SunOS 5.8 Last change: 5 Jul 1990 2 System Calls ptrace(2) To forestall possible fraud, ptrace() inhibits the set- user-ID facility on subsequent calls to one of the exec fam- ily of functions (see exec(2)). If a traced process calls one of the exec functions, it stops before executing the first instruction of the new image showing signal SIGTRAP. ERRORS The ptrace() function will fail if: EIO The request argument is an illegal number. EPERM The effective user of the calling process is not super-user. ESRCH The pid argument identifies a child that does not exist or has not executed a ptrace() call with request 0. SEE ALSO exec(2), exit(2), wait(2), signal(3C), signal(3HEAD)

2 1

Re: cups printing quicken
by Marcus Meissner 07 Jan '02

07 Jan '02

On Sun, Jan 06, 2002 at 08:06:33AM +0000, Alex Newman wrote: > Hello wine people, this is my first posting here. I am using the gimp > printing ppd,cups and lpr on a hpdj842c. Wine release 20011226. On Debian > woody with 2.4.17. Everything rocks so far except whenever i try to print > in quicken either 2002 or version 6 which seem to printing with the same > program. wine freaks out and dies. > > wine --debugmsg +winspool .wine/fake_windows/Program\ Files/QUICKENW/QW.EXE > was sent to > http://www.wuli.nu/users/dolemite/winedebugmsg > my .wine/config is at > http://www.wuli.nu/users/dolemite/wineconfig > > I have printed with other progs in wine and normally and it works fine. Difficult. Try running it within winedbg, so it triggers at the time the exception appears and we can see the backtrace. (Just replace 'wine' by 'winedbg' in the commandline, type 'cont' to start the program.) Ciao, Marcus

1 0

Changes regarding wnaspi32 layer ?
by ma.hoff＠t-online.de 07 Jan '02

07 Jan '02

Hi, i have some problems with the winaspi implementation (scsi cd-writer) of the current version of Wine (tried cvs one or two weeks ago ...) With the version 20010731 which is included in my SuSE 7.3 distribution it works fine (except for some graphic glitches in the application - but thats another story). I try to run Aheads Nero Burning Rom 5.0 , which refuses to detect the cd-writer with the newer versions of wine ! I heard of someone running a cvs snapshot from october 2001 which is working, too - but all later version of wine refuse to work with nero ! The error message is the following: fixme:win32:DEVICE_Open Unknown/unsupported VxD nerocd95. Try --winver nt40 or win31 ! fixme:win32:DEVICE_Open Unknown/unsupported VxD BsUDF.VXD. Try --winver nt40 or win31 ! Guess what: --winver nt40 / win31 didn't change anything :-) So it seems that its not implemented, but with older versions it worked ! Is this a known bug - or do i have to change something else when using the newer version of wine ? Or is it just broken ? Thanks in advance for any help ! Martin

2 1

implement Cancelio (updated), WriteFile update, comm16 update
by l_whitney＠juno.com 07 Jan '02

07 Jan '02

Good day! If you get this, these three patches fix a regression in 16 bit serial comms as practiced by Juno 1.49 that was intrduced by: Changes by: julliard@wine2. 01/12/31 20:11:33 Modified files: files : file.c scheduler : synchro.c Log message: Mike McCormack <mike_mccormack(a)start.com.au>R Set an overlapped's hEvent for ReadFile/WriteFile in an overlapped completion function, not in ReadFileEx or WriteFileEx. Patch: http://cvs.winehq.com/patch.py?id=1009847493736738936509937 So I'm in favor of committing them. Regards, Lawson

1 0

Patch: 005-recv.diff
by Martin Wilck 07 Jan '02

07 Jan '02

#5 in series Patch file: 005-recv.diff Purpose: Move recv() functionality to WS2_32 code Created: 2002-01-07 Applies: CVS 2002-01-07 (with 004-socket.diff applied) This patch moves the recv() functionality to WS2_32 functions that provide a superset of the functionality of their WS counterparts. For the recv() family of functions, WSARecvFrom() becomes the "work horse". All other functions (WSARecv(), recv(), recvfrom()) are only wrappers around WSARecvFrom(). To provide the scatter/gather functionality of WSARecv() / WSARecvFrom(), the (only) unix function called is recvmsg(). This means some overhead for simple recv() calls, but allows for a single general "work" code. dlls/winsock/socket.c: WS_recv(): Is now a wrapper around WSARecv(). WS_recvfrom(): Is now a wrapper around WSARecvFrom(). WSARecv(): Is now a wrapper around WSARecvFrom(). WSARecvFrom(): Holds all "real" recv() functionality (formerly in WS_recv() / WS_recvfrom()). Calls recvmsg() to provide for scatter/gather functionality. dlls/winsock/ws2_32.spec: Add stdcall entry for WSARecv(). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Mon Jan 7 12:55:24 2002 +++ MW/wine/dlls/winsock/socket.c Mon Jan 7 12:55:37 2002 @@ -1815,34 +1815,16 @@ */ int WINAPI WS_recv(SOCKET s, char *buf, int len, int flags) { - int fd = _get_sock_fd(s); + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; TRACE("socket %04x, buf %8x, len %d, flags %d\n", s, (unsigned)buf, len, flags); - if (fd != -1) - { - INT length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds? */ - do_block(fd, 1); - } - if ((length = recv(fd, buf, len, flags)) >= 0) - { - TRACE(" -> %i bytes\n", length); - - close(fd); - _enable_event(s, FD_READ, 0, 0); - return length; - } - SetLastError(wsaErrno()); - close(fd); - } - else SetLastError(WSAENOTSOCK); - WARN(" -> ERROR\n"); - return SOCKET_ERROR; + if ( WSARecv (s, &wsabuf, 1, &n, &dwFlags, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; + else + return n; } /*********************************************************************** @@ -1860,60 +1842,14 @@ int WINAPI WS_recvfrom(SOCKET s, char *buf, INT len, int flags, struct WS_sockaddr *from, int *fromlen) { - int fd = _get_sock_fd(s); - int res; - - TRACE("socket %04x, ptr %08x, len %d, flags %d\n", s, (unsigned)buf, len, flags); -#if DEBUG_SOCKADDR - if (from) - dump_sockaddr(from); - else - DPRINTF("from = NULL\n"); -#endif - - res=SOCKET_ERROR; - if (fd != -1) - { - struct sockaddr* uaddr; - int uaddrlen; - int length; + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds */ - do_block(fd, 1); - } - - uaddr=ws_sockaddr_alloc(from,fromlen,&uaddrlen); - length=recvfrom(fd, buf, len, flags, uaddr, &uaddrlen); - if (length < 0) - { - SetLastError(wsaErrno()); - WARN(" -> ERROR\n"); - } - else if (ws_sockaddr_u2ws(uaddr,uaddrlen,from,fromlen) != 0) - { - /* The from buffer was too small, but we read the data - * anyway. Is that really bad? - */ - SetLastError(WSAEFAULT); - WARN(" -> WSAEFAULT\n"); - } - else - { - TRACE(" -> %i bytes\n", length); - _enable_event(s, FD_READ, 0, 0); - res=length; - } - close(fd); - } + if ( WSARecvFrom (s, &wsabuf, 1, &n, &dwFlags, from, fromlen, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; else - { - SetLastError(WSAENOTSOCK); - WARN(" -> WSAENOTSOCK\n"); - } - return res; + return n; } /*********************************************************************** @@ -3404,34 +3340,132 @@ /*********************************************************************** + * WSARecv (WS2_32.67) + */ +int WINAPI WSARecv (SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, + LPDWORD NumberOfBytesReceived, LPDWORD lpFlags, + LPWSAOVERLAPPED lpOverlapped, + LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + + return WSARecvFrom (s, lpBuffers, dwBufferCount, NumberOfBytesReceived, lpFlags, + NULL, NULL, lpOverlapped, lpCompletionRoutine); + +} + +/*********************************************************************** * WSARecvFrom (WS2_32.69) */ INT WINAPI WSARecvFrom( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, struct WS_sockaddr *lpFrom, LPINT lpFromlen, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) + { - DWORD dwCount; - INT rc; + /* Uses recvmsg() in order to provide scatter-gather I/O */ + + struct iovec* iovec; + struct msghdr msghdr; + int fd, i, length, err = WSAENOTSOCK; + + TRACE("socket %04x, wsabuf %p, nbufs %ld, flags %ld, from %p, fromlen %ld, ovl %p, func %p\n", + s, lpBuffers, dwBufferCount, *lpFlags, lpFrom, + (lpFromlen ? *lpFromlen : -1L), + lpOverlapped, lpCompletionRoutine); - FIXME( "(%i,%p,%lu,%p,%p,%p,%p,%p,%p: stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, - lpFrom, lpFromlen, lpOverlapped, lpCompletionRoutine ); + fd = _get_sock_fd(s); - for( dwCount = 0, rc = 0; dwCount < dwBufferCount; dwCount++ ) - { + if (fd == -1) + { + err = WSAENOTSOCK; + goto error; + } - if( ( rc = WS_recvfrom(s, lpBuffers[ dwCount ].buf, (INT)lpBuffers[ dwCount ].len, - (INT)*lpFlags, lpFrom, lpFromlen ) ) != 0 ) + /* FIXME: should this be HeapAlloc() or WS_ALLOC ? */ + iovec = WS_ALLOC ( dwBufferCount * sizeof (struct iovec) ); + if ( !iovec ) { - break; + err = WSAENOBUFS; + goto err_close; } - } + for (i = 0; i < dwBufferCount; i++) + { + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; + } - return rc; -} + msghdr.msg_name = NULL; + if ( lpFrom ) + { +#if DEBUG_SOCKADDR + dump_sockaddr (lpFrom); +#endif + + msghdr.msg_namelen = *lpFromlen; + msghdr.msg_name = ws_sockaddr_alloc (lpFrom, lpFromlen, &msghdr.msg_namelen); + } + else + msghdr.msg_namelen = 0; + + msghdr.msg_iov = iovec; + msghdr.msg_iovlen = dwBufferCount; + msghdr.msg_control = NULL; + msghdr.msg_controllen = 0; + msghdr.msg_flags = 0; + + /* FIXME: Treat overlapped IO here */ + + if (_is_blocking(s)) + { + /* block here */ + /* FIXME: OOB and exceptfds? */ + do_block(fd, 1); + } + + /* FIXME: can we support MSG_PARTIAL ? + How does it relate to recvmsg()'s msg_flags ? */ + + if ((length = recvmsg (fd, &msghdr, *lpFlags)) == -1) + { + err = wsaErrno(); + goto err_free; + } + + TRACE(" -> %i bytes\n", length); + + if ( lpFrom && ws_sockaddr_u2ws (msghdr.msg_name, msghdr.msg_namelen, lpFrom, lpFromlen) != 0 ) + { + /* The from buffer was too small, but we read the data + * anyway. Is that really bad? + */ + SetLastError ( WSAEFAULT ); + WARN ( " -> Address buffer too small\n" ); + } + + + *lpNumberOfBytesRecvd = length; + + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + close(fd); + _enable_event(s, FD_READ, 0, 0); + + return 0; + +err_free: + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + +err_close: + close (fd); + +error: + WARN(" -> ERROR %d\n", err); + SetLastError ( err ); + return SOCKET_ERROR; +} /*********************************************************************** * WSCInstallProvider (WS2_32.88) diff -ru -X diffignore CVS/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- CVS/wine/dlls/winsock/ws2_32.spec Mon Jan 7 12:42:08 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Mon Jan 7 12:55:37 2002 @@ -79,7 +79,7 @@ 64 stub WSANtohl 65 stub WSANtohs 66 stub WSAProviderConfigChange -67 stub WSARecv +67 stdcall WSARecv(long ptr long ptr ptr ptr ptr) WSARecv 68 stub WSARecvDisconnect 69 stdcall WSARecvFrom(long ptr long ptr ptr ptr ptr ptr ptr ) WSARecvFrom 70 stub WSARemoveServiceClass

1 0

Patch: 004-socket.diff
by Martin Wilck 07 Jan '02

07 Jan '02

#4 in series (incremental) Patch file: 004-socket.diff Purpose: Move socket() functionality to WS2_32 code Created: 2002-01-07 Applies: CVS 2002-01-07 (with 003-sock_basic.diff applied) This patch moves the functionality of WS_socket() to WSASocketA(). WSASocketA() accounts for WSA_FLAG_OVERLAPPED. dlls/winsock/socket.c: WS_socket(): Is now a wrapper around WSASocketA(). WSA_FLAG_OVERLAPPED is set according to the SO_OPENTYPE value. WSASocketA(): Has the functionality formerly in WS_socket(). Honours WSA_FLAG_OVERLAPPED. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Mon Jan 7 12:45:56 2002 +++ MW/wine/dlls/winsock/socket.c Mon Jan 7 12:51:27 2002 @@ -2329,81 +2329,14 @@ */ SOCKET WINAPI WS_socket(int af, int type, int protocol) { - SOCKET ret; - TRACE("af=%d type=%d protocol=%d\n", af, type, protocol); - /* check the socket family */ - switch(af) - { -#ifdef HAVE_IPX - case WS_AF_IPX: af = AF_IPX; -#endif - case AF_INET: - case AF_UNSPEC: break; - default: SetLastError(WSAEAFNOSUPPORT); - return INVALID_SOCKET; - } - - /* check the socket type */ - switch(type) - { - case WS_SOCK_STREAM: - type=SOCK_STREAM; - break; - case WS_SOCK_DGRAM: - type=SOCK_DGRAM; - break; - case WS_SOCK_RAW: - type=SOCK_RAW; - break; - default: SetLastError(WSAESOCKTNOSUPPORT); - return INVALID_SOCKET; - } - - /* check the protocol type */ - if ( protocol < 0 ) /* don't support negative values */ - { SetLastError(WSAEPROTONOSUPPORT); return INVALID_SOCKET; } - - if ( af == AF_UNSPEC) /* did they not specify the address family? */ - switch(protocol) - { - case IPPROTO_TCP: - if (type == SOCK_STREAM) { af = AF_INET; break; } - case IPPROTO_UDP: - if (type == SOCK_DGRAM) { af = AF_INET; break; } - default: SetLastError(WSAEPROTOTYPE); return INVALID_SOCKET; - } - - SERVER_START_REQ( create_socket ) - { - req->family = af; - req->type = type; - req->protocol = protocol; - req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; - req->flags = 0U; - req->inherit = TRUE; - set_error( wine_server_call( req ) ); - ret = (SOCKET)reply->handle; - } - SERVER_END_REQ; - if (ret) - { - TRACE("\tcreated %04x\n", ret ); - return ret; - } - - if (GetLastError() == WSAEACCES) /* raw socket denied */ - { - if (type == SOCK_RAW) - MESSAGE("WARNING: Trying to create a socket of type SOCK_RAW, will fail unless running as root\n"); - else - MESSAGE("WS_SOCKET: not enough privileges to create socket, try running as root\n"); - SetLastError(WSAESOCKTNOSUPPORT); - } + /* The Winsock2 specification states that socket() always opens sockets + in overlapped mode. + FIXME: is the SO_OPENTYPE behaviour correct? */ - WARN("\t\tfailed!\n"); - return INVALID_SOCKET; + return WSASocketA ( af, type, protocol, NULL, 0, + (opentype ? 0 : WSA_FLAG_OVERLAPPED) ); } /*********************************************************************** @@ -2974,17 +2907,88 @@ LPWSAPROTOCOL_INFOA lpProtocolInfo, GROUP g, DWORD dwFlags) { + SOCKET ret; + /* FIXME: The "advanced" parameters of WSASocketA (lpProtocolInfo, - g, dwFlags) are ignored. + g, dwFlags except WSA_FLAG_OVERLAPPED) are ignored. */ TRACE("af=%d type=%d protocol=%d protocol_info=%p group=%d flags=0x%lx\n", af, type, protocol, lpProtocolInfo, g, dwFlags ); - return ( WS_socket (af, type, protocol) ); -} + /* check the socket family */ + switch(af) + { +#ifdef HAVE_IPX + case WS_AF_IPX: af = AF_IPX; +#endif + case AF_INET: + case AF_UNSPEC: break; + default: SetLastError(WSAEAFNOSUPPORT); + return INVALID_SOCKET; + } + + /* check the socket type */ + switch(type) + { + case WS_SOCK_STREAM: + type=SOCK_STREAM; + break; + case WS_SOCK_DGRAM: + type=SOCK_DGRAM; + break; + case WS_SOCK_RAW: + type=SOCK_RAW; + break; + default: SetLastError(WSAESOCKTNOSUPPORT); + return INVALID_SOCKET; + } + + /* check the protocol type */ + if ( protocol < 0 ) /* don't support negative values */ + { SetLastError(WSAEPROTONOSUPPORT); return INVALID_SOCKET; } + + if ( af == AF_UNSPEC) /* did they not specify the address family? */ + switch(protocol) + { + case IPPROTO_TCP: + if (type == SOCK_STREAM) { af = AF_INET; break; } + case IPPROTO_UDP: + if (type == SOCK_DGRAM) { af = AF_INET; break; } + default: SetLastError(WSAEPROTOTYPE); return INVALID_SOCKET; + } + + SERVER_START_REQ( create_socket ) + { + req->family = af; + req->type = type; + req->protocol = protocol; + req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; + req->flags = dwFlags; + req->inherit = TRUE; + set_error( wine_server_call( req ) ); + ret = (SOCKET)reply->handle; + } + SERVER_END_REQ; + if (ret) + { + TRACE("\tcreated %04x\n", ret ); + return ret; + } + + if (GetLastError() == WSAEACCES) /* raw socket denied */ + { + if (type == SOCK_RAW) + MESSAGE("WARNING: Trying to create a socket of type SOCK_RAW, will fail unless running as root\n"); + else + MESSAGE("WS_SOCKET: not enough privileges to create socket, try running as root\n"); + SetLastError(WSAESOCKTNOSUPPORT); + } + WARN("\t\tfailed!\n"); + return INVALID_SOCKET; +} /*********************************************************************** * __WSAFDIsSet (WINSOCK.151)

1 0

Patch: 003-sock_basic.diff
by Martin Wilck 07 Jan '02

07 Jan '02

#3 in series (incremental) Patch file: 003-sock_basic.diff Purpose: Basic implementation of socket flags. Created: 2002-01-07 Applies: CVS 2002-01-07 (with 002-fd_type.diff applied) This patch adds socket flags to the server data structure for sockets, and adds means to set these flags when creating sockets. It also provides basic server functionality to allow async I/O on sockets. ** NOTE ON BUILDING: tools/make_requests must be run ** ** after applying this patch ** server/protocol.def: create_socket request: add flags parameter. server/sock.c: struct socket: add flags field. add struct async_queue fields for async IO operations. sock_get_info(): Account for WSA_FLAG_OVERLAPPED. create_socket(): Additional parameter (unsigned int flags) Initialize async queues for overlapped sockets. create_socket_req(): Pass flags parameter to create_socket(). sock_destroy(): Destroy async queues for overlapped sockets. dlls/winsock/socket.c: WS_socket(): Initialize socket flags parameter (currently 0). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Wed Jan 2 12:50:02 2002 +++ MW/wine/dlls/winsock/socket.c Fri Jan 4 11:13:03 2002 @@ -2381,6 +2381,7 @@ req->type = type; req->protocol = protocol; req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; + req->flags = 0U; req->inherit = TRUE; set_error( wine_server_call( req ) ); ret = (SOCKET)reply->handle; diff -ru -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Fri Jan 4 11:07:45 2002 +++ MW/wine/server/file.c Thu Jan 3 15:21:50 2002 @@ -342,7 +342,7 @@ reply->serial = 0; /* FIXME */ } - if (file->flags & FILE_FLAG_OVERLAPPED) + if ( file->flags & FILE_FLAG_OVERLAPPED ) fd_type |= FD_TYPE_FLAG_OVERLAPPED; return fd_type; diff -ru -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Fri Jan 4 11:07:45 2002 +++ MW/wine/server/protocol.def Fri Jan 4 10:20:53 2002 @@ -646,6 +646,7 @@ int family; /* family, see socket manpage */ int type; /* type, see socket manpage */ int protocol; /* protocol, see socket manpage */ + unsigned int flags; /* socket flags */ @REPLY handle_t handle; /* handle to the new socket */ @END diff -ru -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Fri Jan 4 11:07:45 2002 +++ MW/wine/server/sock.c Fri Jan 4 11:10:45 2002 @@ -36,6 +36,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" /* To avoid conflicts with the Unix socket headers. Plus we only need a few * macros anyway. @@ -50,8 +51,11 @@ unsigned int mask; /* event mask */ unsigned int hmask; /* held (blocked) events */ unsigned int pmask; /* pending events */ + unsigned int flags; /* socket flags */ struct event *event; /* event object */ int errors[FD_MAX_EVENTS]; /* event errors */ + struct async_queue read_q; /* Queue for asynchronous reads */ + struct async_queue write_q; /* Queue for asynchronous writes */ }; static void sock_dump( struct object *obj, int verbose ); @@ -275,6 +279,9 @@ static int sock_get_info( struct object *obj, struct get_file_info_reply *reply ) { + struct sock *sock = (struct sock*) obj; + assert ( obj->ops == &sock_ops ); + if (reply) { reply->type = FILE_TYPE_PIPE; @@ -288,6 +295,10 @@ reply->index_low = 0; reply->serial = 0; } + + if ( sock->flags & WSA_FLAG_OVERLAPPED ) + return FD_TYPE_SOCKET | FD_TYPE_FLAG_OVERLAPPED; + return FD_TYPE_SOCKET; } @@ -297,6 +308,13 @@ assert( obj->ops == &sock_ops ); /* FIXME: special socket shutdown stuff? */ + + if ( sock->flags & WSA_FLAG_OVERLAPPED ) + { + destroy_async_queue ( &sock->read_q ); + destroy_async_queue ( &sock->write_q ); + } + if (sock->event) { /* if the service thread was waiting for the event object, @@ -310,7 +328,7 @@ } /* create a new and unconnected socket */ -static struct object *create_socket( int family, int type, int protocol ) +static struct object *create_socket( int family, int type, int protocol, unsigned int flags ) { struct sock *sock; int sockfd; @@ -329,9 +347,15 @@ sock->mask = 0; sock->hmask = 0; sock->pmask = 0; + sock->flags = flags; sock->event = NULL; sock_reselect( sock ); clear_error(); + if (sock->flags & WSA_FLAG_OVERLAPPED) + { + init_async_queue (&sock->read_q); + init_async_queue (&sock->write_q); + } return &sock->obj; } @@ -377,6 +401,12 @@ acceptsock->event = NULL; if (sock->event && !(sock->mask & FD_WINE_SERVEVENT)) acceptsock->event = (struct event *)grab_object( sock->event ); + acceptsock->flags = sock->flags; + if ( acceptsock->flags & WSA_FLAG_OVERLAPPED ) + { + init_async_queue ( &acceptsock->read_q ); + init_async_queue ( &acceptsock->write_q ); + } sock_reselect( acceptsock ); clear_error(); @@ -463,7 +493,7 @@ struct object *obj; reply->handle = 0; - if ((obj = create_socket( req->family, req->type, req->protocol )) != NULL) + if ((obj = create_socket( req->family, req->type, req->protocol, req->flags )) != NULL) { reply->handle = alloc_handle( current->process, obj, req->access, req->inherit ); release_object( obj );

1 0

Patch: 002-fd_type.diff
by Martin Wilck 07 Jan '02

07 Jan '02

Patch 2 in the series, a repost of my patch to wine-devel of 2002-01-03, Now incremental to the previous patch (i.e., also relies on Mike's patches being applied). Patch file: 002-fd_type.diff Purpose: More general approach to file descriptor types and flags. Created: 2002-01-07 Applies: CVS 2002-01-07 (with 001-file_overlapped.diff applied) If overlapped IO is to be allowed / implemented for several different types of file descriptors (regular files, serial ports, pipes, sockets, ...), a more general scheme must be found to obtain file descriptor types and flags or capabilities. The current scheme treats FD_TYPE_OVERLAPPED as a special type, making it impossible to distinguish between e.g. overlapped files and overlapped sockets. This patch fixes this behaviour by modifying the meaning of return value of the get_file_info() function. ** NOTE ON BUILDING: tools/make_requests must be run ** ** after applying this patch ** server/protocol.def: The lowest byte of the type value is reserved for the type itself (macro FD_TYPE (type)the rest is available for miscellaneous flags. New FD types: FD_TYPE_DEVICE, FD_TYPE_NAMED_PIPE, FD_TYPE_PIPE, FD_TYPE_SERIAL, FD_TYPE_SOCKET. New FD flags (were formerly FD types): FD_TYPE_FLAG_OVERLAPPED: The fd uses overlapped I/O. FD_TYPE_FLAG_TIMEOUT: The fd applies a timeout on its I/O operations New test macros: FD_TYPE_IS_OVERLAPPED (type), FD_TYPE_HAS_TIMEOUT (type) server/device.c: device_get_info(): return FD_TYPE_DEVICE. server/file.c: file_get_info(): set FD_TYPE_FLAG_OVERLAPPED on overlapped files. server/named_pipe.c: named_pipe_get_info(): return FD_TYPE_NAMED_PIPE. server/pipe.c: named_pipe_get_info(): return FD_TYPE_PIPE. server/serial.c: serial_get_info(): return FD_TYPE_SERIAL, account for OVERLAPPED and TIMEOUT flags. server/serial.c: sock_get_info(): return FD_TYPE_SOCKET. files/file.c: ReadFile(): Replace FD_TYPE_XYZ dependent switch statement with an equivalent if/elseif construct which will allow a morte fine-grained destinction of fd types and flags in the future. WriteFile(): dito. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Jan 7 16:04:31 2002 +++ MW/wine/files/file.c Mon Jan 7 16:00:33 2002 @@ -1467,9 +1467,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_READ, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1512,15 +1511,21 @@ /* fail on return, with ERROR_IO_PENDING */ SetLastError(ERROR_IO_PENDING); return FALSE; + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { return ReadConsoleA(hFile, buffer, bytesToRead, bytesRead, NULL); + } - case FD_TYPE_TIMEOUT: + else if ( FD_TYPE_HAS_TIMEOUT (type) ) + { close(unix_handle); return FILE_TimeoutRead(hFile, buffer, bytesToRead, bytesRead); + } - default: + else + { /* normal unix files */ if (unix_handle == -1) return FALSE; @@ -1530,7 +1535,6 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - break; } /* code for synchronous reads */ @@ -1689,9 +1693,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_WRITE, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1741,11 +1744,17 @@ SetLastError(ERROR_IO_PENDING); return FALSE; - case FD_TYPE_CONSOLE: + } + + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { TRACE("%d %s %ld %p %p\n", hFile, debugstr_an(buffer, bytesToWrite), bytesToWrite, bytesWritten, overlapped ); return WriteConsoleA(hFile, buffer, bytesToWrite, bytesWritten, NULL); - default: + } + + else + { if (unix_handle == -1) return FALSE; } diff -ruX diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/device.c Mon Jan 7 16:00:33 2002 @@ -83,7 +83,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_DEVICE; } /* create a device */ diff -ruX diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Jan 7 15:58:22 2002 +++ MW/wine/server/file.c Mon Jan 7 16:00:33 2002 @@ -308,6 +308,7 @@ { struct stat st; struct file *file = (struct file *)obj; + int fd_type = FD_TYPE_DEFAULT; assert( obj->ops == &file_ops ); if (reply) @@ -342,9 +343,10 @@ } if (file->flags & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; + + return fd_type; - return FD_TYPE_DEFAULT; } static struct async_queue *file_queue_async(struct object *obj, struct async *async, int type, int count) diff -ruX diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/named_pipe.c Mon Jan 7 16:00:33 2002 @@ -197,7 +197,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_NAMED_PIPE; } static struct named_pipe *create_named_pipe( const WCHAR *name, size_t len ) diff -ruX diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/pipe.c Mon Jan 7 16:00:33 2002 @@ -140,7 +140,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_PIPE; } static void pipe_destroy( struct object *obj ) diff -ruX diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Mon Jan 7 15:45:26 2002 +++ MW/wine/server/protocol.def Mon Jan 7 16:00:33 2002 @@ -544,12 +544,22 @@ int fd; /* file descriptor */ int type; /* the type of file */ @END +#define FD_TYPE(x) ((x) & 0xff) + #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1 #define FD_TYPE_CONSOLE 2 -#define FD_TYPE_OVERLAPPED 3 -#define FD_TYPE_TIMEOUT 4 +#define FD_TYPE_DEVICE 3 +#define FD_TYPE_NAMED_PIPE 4 +#define FD_TYPE_PIPE 5 +#define FD_TYPE_SERIAL 6 +#define FD_TYPE_SOCKET 7 + +#define FD_TYPE_FLAG_OVERLAPPED 0x100 +#define FD_TYPE_FLAG_TIMEOUT 0x200 +#define FD_TYPE_IS_OVERLAPPED(x) ((x) & FD_TYPE_FLAG_OVERLAPPED) +#define FD_TYPE_HAS_TIMEOUT(x) ((x) & FD_TYPE_FLAG_TIMEOUT) /* Set a file current position */ @REQ(set_file_pointer) diff -ruX diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/serial.c Mon Jan 7 16:00:33 2002 @@ -192,6 +192,7 @@ static int serial_get_info( struct object *obj, struct get_file_info_reply *reply ) { struct serial *serial = (struct serial *) obj; + int fd_type = FD_TYPE_SERIAL; assert( obj->ops == &serial_ops ); if (reply) @@ -209,13 +210,13 @@ } if(serial->attrib & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; - if( (serial->readinterval == MAXDWORD) && - (serial->readmult == 0) && (serial->readconst == 0) ) - return FD_TYPE_DEFAULT; + else if( !((serial->readinterval == MAXDWORD) && + (serial->readmult == 0) && (serial->readconst == 0)) ) + fd_type |= FD_TYPE_FLAG_TIMEOUT; - return FD_TYPE_TIMEOUT; + return fd_type; } static void serial_poll_event(struct object *obj, int event) diff -ruX diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/sock.c Mon Jan 7 16:00:33 2002 @@ -288,7 +288,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_SOCKET; } static void sock_destroy( struct object *obj )

1 0

Patch: 001-file_overlapped.diff
by Martin Wilck 07 Jan '02

07 Jan '02

This patch is a repost of my patch of 2002-01-03, now against the current CVS version including Mike McCormack's latest patches (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff as of 2002-01-06). It is the first in a series of patches that constitute intermediate steps towards async socket IO. I consider them pretty clean and have done basic testing. My testing possibilities are limited, though - I'd be grateful to anybody who could run tests especially with 16-bit network-oriented windows applications. Bugs in my code should show up immediately as regressions. Patch file: 001-file_overlapped.diff Purpose: This patch fixes overlapped I/O on regular files. Created: 2002-01-07 Applies: CVS 2002-01-07 with Mike McCorkack's patches of 2002-01-06 applied (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff) Add server side support for async IO on files. FILE_Async[Read|Write]Service and WriteFile() use pread() / pwrite() rather than read() / write () for fd's on which lseek()ing is possible to honour the fact that lpOverlapped->Offset and lpOverlapped->OffsetHigh contain the offset from which the file is to be read. files/file.c: OVERLAPPED_OFFSET: Macro to calculate file offset from OVERLAPPED struct. FILE_AsyncReadService(): Use pread() on fd's that allow lseek(). FILE_AsyncWriteService(): Use pwrite() on fd's that allow lseek(). WriteFile(): dito. server/file.c: struct file: Add two struct async_queue fields (for async read/write). file_ops: file specific poll_event() method accounts for overlapped IO. define queue_async() method. create_file_for_fd(): call init_async_queue() on overlapped files. file_poll_event(): call default_poll_event() only after checking for queued async requests. file_get_info(): return FD_TYPE_OVERLAPPED if FILE_FLAG_OVERLAPPED is set. file_queue_async(): implement queue_async() method for files. file_destroy(): destroy async queues on overlapped files. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/files/file.c Mon Jan 7 15:55:36 2002 @@ -9,6 +9,9 @@ * Right now, they simply call the CopyFile method. */ +/* This is needed to avoid compile-time warnings about pread / pwrite */ +#define _GNU_SOURCE +#define _XOPEN_SOURCE 500 #include "config.h" #include "wine/port.h" @@ -55,6 +58,9 @@ /* Size of per-process table of DOS handles */ #define DOS_TABLE_SIZE 256 +/* Macro to derive file offset from OVERLAPPED struct */ +#define OVERLAPPED_OFFSET(overlapped) ((off_t) (overlapped)->Offset + ((off_t) (overlapped)->OffsetHigh << 32)) + static HANDLE dos_handles[DOS_TABLE_SIZE]; @@ -1304,12 +1310,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("%p %p\n", lpOverlapped, ovp->buffer ); /* check to see if the data is ready (non-blocking) */ - result = read(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count - lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pread (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1543,12 +1558,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); /* write some data (non-blocking) */ - result = write(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count-lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pwrite (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = write (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1678,7 +1702,13 @@ } /* see if we can write some data already (this shouldn't block) */ - result = write( unix_handle, buffer, bytesToWrite ); + + if ( lseek(unix_handle, 0, SEEK_CUR) != (off_t) -1 ) + result = pwrite( unix_handle, buffer, bytesToWrite, + OVERLAPPED_OFFSET (overlapped) ); + else + result = write( unix_handle, buffer, bytesToWrite ); + close(unix_handle); if(result<0) @@ -1693,7 +1723,7 @@ result = 0; } - /* if we read enough to keep the app happy, then return now */ + /* if we wrote enough to keep the app happy, then return now */ if(result>=bytesToWrite) { *bytesWritten = result; diff -ruX diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/server/file.c Mon Jan 7 15:55:28 2002 @@ -29,6 +29,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" struct file { @@ -39,6 +40,9 @@ unsigned int flags; /* flags (FILE_FLAG_*) */ unsigned int sharing; /* file sharing mode */ int drive_type; /* type of drive the file is on */ + + struct async_queue read_q; + struct async_queue write_q; }; #define NAME_HASH_SIZE 37 @@ -47,10 +51,12 @@ static void file_dump( struct object *obj, int verbose ); static int file_get_poll_events( struct object *obj ); +static void file_poll_event( struct object *obj, int event ); static int file_get_fd( struct object *obj ); static int file_flush( struct object *obj ); static int file_get_info( struct object *obj, struct get_file_info_reply *reply ); static void file_destroy( struct object *obj ); +static struct async_queue * file_queue_async(struct object *obj, struct async* async, int type, int count); static const struct object_ops file_ops = { @@ -61,11 +67,11 @@ default_poll_signaled, /* signaled */ no_satisfied, /* satisfied */ file_get_poll_events, /* get_poll_events */ - default_poll_event, /* poll_event */ + file_poll_event, /* poll_event */ file_get_fd, /* get_fd */ file_flush, /* flush */ file_get_info, /* get_file_info */ - NULL, /* queue_async */ + file_queue_async, /* queue_async */ file_destroy /* destroy */ }; @@ -116,6 +122,11 @@ file->flags = attrs; file->sharing = sharing; file->drive_type = drive_type; + if (file->flags & FILE_FLAG_OVERLAPPED) + { + init_async_queue (&file->read_q); + init_async_queue (&file->write_q); + } } return file; } @@ -253,6 +264,27 @@ return events; } +static void file_poll_event( struct object *obj, int event ) +{ + struct file *file = (struct file *)obj; + assert( obj->ops == &file_ops ); + if ( file->flags & FILE_FLAG_OVERLAPPED ) + { + if( IS_READY(file->read_q) && (POLLIN & event) ) + { + async_notify(file->read_q.head, STATUS_ALERTED); + return; + } + if( IS_READY(file->write_q) && (POLLIN & event) ) + { + async_notify(file->write_q.head, STATUS_ALERTED); + return; + } + } + default_poll_event( obj, event ); +} + + static int file_get_fd( struct object *obj ) { struct file *file = (struct file *)obj; @@ -308,9 +340,45 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } + + if (file->flags & FILE_FLAG_OVERLAPPED) + return FD_TYPE_OVERLAPPED; + return FD_TYPE_DEFAULT; } +static struct async_queue *file_queue_async(struct object *obj, struct async *async, int type, int count) +{ + struct file *file = (struct file *)obj; + struct async_queue *q; + + assert( obj->ops == &file_ops ); + + if ( !(file->flags & FILE_FLAG_OVERLAPPED) ) + { + set_error ( STATUS_INVALID_HANDLE ); + return NULL; + } + + switch(type) + { + case ASYNC_TYPE_READ: + q = &file->read_q; + break; + case ASYNC_TYPE_WRITE: + q = &file->write_q; + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return NULL; + } + + if(async && !async->q) + async_insert(q, async); + + return q; +} + static void file_destroy( struct object *obj ) { struct file *file = (struct file *)obj; @@ -325,6 +393,11 @@ *pptr = (*pptr)->next; if (file->flags & FILE_FLAG_DELETE_ON_CLOSE) unlink( file->name ); free( file->name ); + } + if (file->flags & FILE_FLAG_OVERLAPPED) + { + destroy_async_queue (&file->read_q); + destroy_async_queue (&file->write_q); } }

1 0

mvcrt patch
by Waldek Hebisch 07 Jan '02

07 Jan '02

Enclosed is a patch (diff to 2001.12.26 snapshot) which impements stdio buffering in msvcrt. Since I cannot make Visual C binaries could anybady with Visual C++ test it? I have testet it with mingw32 and I incude my test program (iotst.c). The program prints a line indicating which test it is making and then complains about failures. Comment 1: current builtin msvcrt fails test1 (and few other as a consequence). Some native versions of msvcrt fail test 8. Comment 2: I wrote the test the way naive programmer would wrote it (IMHO). Now I think that for a testing framework we need an assert-like macro to make checking and printing code shorter and to have uniform printouts. I ommited some tests that require multiple processes (expandig file while it is read, checking that stdio buffers got flushed at exit) - I guess that doing such test in portable way is quite tricky. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

cutting teeth
by Shane Shields 06 Jan '02

06 Jan '02

hello everybody, just want to let everyone know that i (shane shields) have joined the mailing list and downloaded the latest cvs. what i want to know now is what can i do i have some c experience but mostly dos (and some windows), vb (but i dont think its relevent) and i know the windows os quite well. as i converted to linux 8 months ago and totally removed windows i would like to help with wine development with the aim of not having to use any proprietry dlls at all (to do with the core os that is). i have looked at the 20011226 version and noticed that the ole functionality is virtually nonexistant. is anyone working on that? or is there a better way to cut my teeth with wine programming. suggestions, directions and flames welcome. just remember that i am relatively new to linux programming. looking forward to joining the community Shane Shields _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: WinSpool Ordinal Addition
by Alexandre Julliard 06 Jan '02

06 Jan '02

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > I came across a program which imports a function from winspool.drv via > ordinal instead of via name. Now back in February, a patch from Huw Davies > was committed which removed all the ordinals from the spec file for winspool > (see http://www.winehq.com/hypermail/wine-cvs/2001/02/0016.html). I don't > know what the reason was (maybe some were wrong?), so I've attached a patch > which re-adds the ordinal for the one function this program requires. What app is that? None of the winspool.drv I checked have PrinterProperties at ordinal 201, so I don't see how this could work. Or does it just want to have something there? does it work if you put a stub at 201 instead of PrinterProperties? -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: PATCH: Euro
by Patrik Stridvall 06 Jan '02

06 Jan '02

> This patch changes the NLS currency of all Euro countries to > use the "EUR" > as international currency and the euro-sign (iso-8859-15, > character 164). Hmm. While I'm do not doubt that some users of Wine might find this useful, Wine is supposed to do what Windows does and if Windows does something wrong Wine usually should as well. If I'm not mistaken the .nls contains that default values. It is entirely possible to change the currency and such in the registry to specify things differently for each user. That said I would find it unlikely that this patch would cause any serious problem. After all, as I said, the user can specify whatever currency it likes after the defaults have been set and every application is supposed to be able to handle it. So I do not really oppose the patch. It is more the principle I'm intrested in: Under what circumstances should Wine change the behavior if Windows does something in the wrong way?

4 3

Re: MSDOS Error Table Handling
by Ove Kaaven 05 Jan '02

05 Jan '02

On Thu, 3 Jan 2002 ccrayne(a)crayne.org wrote: > - /* We will use a snippet of real mode code that calls */ + > /* We use a snippet of real mode code that calls */ > /* a WINE-only interrupt to handle moving the requested */ - > /* message into the buffer... */ > + /* message into the buffer... ... > - INT (WINE-only interrupt) If that's what you need, I suggest allocating a DPMI Real-Mode Callback thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use it in dosaspi.c... you give it a Wine-implemented function, and it returns a real-mode address that DOS apps can use to call it... the only thing to keep in mind is that it's the Wine function's responsibility to pop the real-mode stack)

2 5

Re: ReadFile() question (Bug?)
by Mike McCormack 05 Jan '02

05 Jan '02

Hi Martin, The console doesn't use an fd, so no fd will be fetched in FILE_GetUnixHandle. (have a look at server/console.c) Mike > Btw, > > in the code in ReadFile() / WriteFile() handling consoles, > shouldn't there be a > close (unix_handle) > statement before calling ReadConsoleA() / WriteConsoleA() ? > > Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

SHGetSpecialFolderLocation function
by Chris Green 04 Jan '02

04 Jan '02

Hi, I've been looking into this function, trying to work out why ms office 97 can't install under Wine. (I've also been looking at the handling of command-lines when new processes are spawned, as office's setup program spawns a process called acmsetup with a string of command-line options, and it seems that wine manages to insert an extra " at the end of the command line.) What I've found though with the SHGetSpecialFolderLocation, is that it seems to me that it is designed to allow the caller to pick an arbitrary value for the CSIDL, and that this will cause windows to create a new CSIDL. As the function's implementation currently stands, it has a hard-coded table of possible CSIDLs, and rejects calls with unknown CSIDLs. Has anyone else looked at this function, and does anyone have any comments or suggestions on ways to address this? I'm thinking that these values probably need to go into the registry, or something, rather than being stored in the code... regards Chris Green

1 0

msnbc news alert installer: "Unable to start browser"
by Dan Kegel 04 Jan '02

04 Jan '02

While doing research for my site on the Microsoft antitrust trial ( http://www.kegel.com/remedy/ ), I came across a nasty little EULA for a product called MSNBC News Alert. The EULA is at http://www.msnbc.com/tools/newsalert/naeula.asp and says > MSNBC Interactive grants you the right to install and use > copies of the SOFTWARE PRODUCT on your computers running validly > licensed copies of the operating system for which the SOFTWARE > PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft > Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.]. It'd be nice to know how close Wine is to being able to (a) install and (b) run this on a fake windows installation, as this may have some bearing on whether Microsoft is damaging anybody with this exclusionary EULA. (Besides, how could I resist? That EULA practically begs to be disobeyed!) So I downloaded it from http://www.msnbc.com/tools/newstools/d/news_alert.asp and ran it, but it failed with the dialog box "News Alert and Windows were unable to start your default browser to access the following URL..." Can anyone have a look at what's wrong (presumably Wine doesn't implement browser control, or I don't have a browser registered?) I'm running Wine release 20010731 (my, that's old!) The output of wine -debugmsg +all is at http://www.kegel.com/wine/newsalert/log.bz2 and is 328KB compressed (200 MB expanded!) I can't see anything obvious, but then I'm out of practice. (You probably just want to download the executable and try it yourself.) Thanks, Dan Kegel

5 6

Wine Tasklist
by Francois Gouget 04 Jan '02

04 Jan '02

Hi, I would like to establish two Wine tasklists in Wine's bugzilla. * the first list would contain the items listed in my previous 'Call for Volunteers' emails. This would make it easier to keep track of these tasks. * the second list would contain more complex and general items like 'DCOM support'. For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items. I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different. * My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine. * Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date. I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one. Wine tasklist ------------- * Make the registry loadable on demand - when working from a Windows partition the registry is big. - this causes wineserver to allocate a lot of memory - this has a big impact on startup times - a 'database' based registry may be more robust * Rasterizer - to paint into a DIB we have to copy the IB contents into an X bitmap, call X functions to modify the bitmap, often only to have to copy the result back to the DIB when the application tries to read it. Imagine it for eash SetPixel operation! - a rasterizer would be able to perform these operations directly on the DIB and thus provide better performance, at least in some situations. - it would also provide better color accuracy: the X server often only supports a few bit depths so that if the application works on a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per color component. * Cross process messages - used by many applications - needed for DDE (bug 95) - Alexandre, you worked on this recently, right? Is this working now? - See bug 93 * Out of proc COM - Needed for Installshield 6 - Would probably help with at least some functionality of a host of other applications * DCOM support - same as out of proc COM but network transparent - should be interoperable with Microsoft's implementation so that, in a company setting, processes running in Wine can connect to servers running on whatever Windows server are present. * Better multi-user support - how to get per-user registry files - how much per-user setup is really necessary? (create a '.wine' directory, create per user registry files, who does that, ...) - is it possible to share a single read-only 'c:\' drive? What do we need to get parity with an NT environment? - is it possible to share a read-only 'system.reg' file? - what is the impact of a 'load on demand' registry? Could we share a single registry server? - what would be necessary to share a single - there are many options that need to be investigated and documented... * UNC path handling - for drives '\\.\e:', devices - for network paths - there's been a patch related to this recently but I believe it does not cover all cases - integrate with Samba to handle network UNC paths - provide a way to mount/unmount drives at runtime, especially network drives. One should be able to disable this in the config file (for security reasons). - Support for 'persistent' mounts... will require modifying the way w specify which drives are mounted where. - provide an applet to mount/unmount drives while Wine is running. * Native Alsa support - Alsa is the future of sound in Linux: should be integrated in 2.5 - Could it offer capabilities that OSS does not offer? - Other platforms may not support Alsa any time soon so we must keep OSS too - Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well - see bug 324 * aRts support - On an OSS system when the aRts daemon is running Wine cannot access the sound device - aRts makes it possible to send the sound other the network. This kind of functionality is great for a thin-client environments: setup a server and have the sound sent to each terminal ("You've got mail" ;-). Supporting aRts in Wine would let it integrate perfectly in such an environment. - this could either be native support, or making Wine compatible with artsdsp. The current problem may be related to the -Bsymbolic link option. - see bug 325 * ESounD support - Same thing as for aRts - see bug 326 - Making Wine compatible with artsdsp may also make it compatible with esddsp (and vice versa). * Write a regedit replacement - used by some installers to create registry keys - we can limit the functionality to just that although since Wine has a registry we should probably provide a tool to browse/edit it. - will be more important once we have a database based registry for the load on demand functionality * Write a regsvr32 replacement - used by some installers * Fix the desktop mode - If a process running in desktop mode start another, the new process creates a new desktop - the background is black - one cannot start a specific application in desktop mode. You have to modify the config file. * Compile with STRICT on - better type safety - reveales all the 16/32bits hacks - see bug 90 * Dll separation - to allow us to swap native dlls in and out with less problems - to make the dlls more independent of each other and make it easier to treat them as independent projects - see bug 96 * HEAP_strdup* removal - Alexandre said some day that they will go away - Part of the dll separation? * Move the winsock16 code to wsock32 - winsock16 is more related to wsock32 than to ws2_32 - ws2_32 is the new API. This would leave us with a clean 32bit implementation of the new API that is not encumbered with 16bit hacks. * Check .spec file completeness - we need complete spec file to know where we stand - determine what's new in WinMe, Win2000, WinXP - check that the ordinals/absence of ordinals is correct - I have scripts that can be used as a starting point * Winedbg expression handling - when modifying the contents of a variable there can be mixups where the debugger modifies its own memory instead of that of the debugged process. * Winedbg g++ 3.0 support - The debugging format and the ABI changed in g++ 3.0 and winedbg does not support the new ABI. - This prevents debugging of C++ Winelib applications - This is especially troublesome for MFC Winelib applications - Eric, you worked on this recently, do you know if this is a thing of the past or is it possible that there are still problems (I did not test recently) * Better memory allocator - some memory allocation/release patterns cause the current allocator to be relatively inefficient - see threads on wine-dev (Ove/Gav hit this problem) * Winelib richedit support - one of the things needed by MFC - the API seems at least partly supported, but the headers are very incomplete - see bug 330 * Visual C++ project support - make it possible to generate a Winelib project from a Visual C++ project - this should be done by extending winemaker - see bug 61 * Specify how to compile and package the MFC - many applications use the MFC. To make Winelib useful it is necessary to make it easier to compile the MFC and MFC-based applications - winemaker has some support for the MFC. But it makes suppositions about how the MFC were compiled (library names, etc.). So it is necessary to document how to get something that works well - see bug 110 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

5 9

ReadFile() question (Bug?)
by Martin Wilck 04 Jan '02

04 Jan '02

Btw, in the code in ReadFile() / WriteFile() handling consoles, shouldn't there be a close (unix_handle) statement before calling ReadConsoleA() / WriteConsoleA() ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: [RFC] cleaner FD_TYPE_XXX implementation
by Mike McCormack 04 Jan '02

04 Jan '02

Hi Martin, Sorry, i should have been a little more clear: if there is a overlapped console, the code in ReadFile (ie. the implemention) will ignore the fact that it is a console, and treat it as a standard overlapped file. In other words, ReadFile should check if the fd is a console fd first, then check if it has the overlapped flag. What you're trying to do is good, and my complaint is just a quibble since the console code doesn't support overlapped operations now anyway :-] Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > >On Fri, 4 Jan 2002, Mike McCormack wrote: > >> looks good to me. The only complication i can see is if overlapped >> operations are possible on consoles. > >Yes, but the OVERLAPPED flag must be set explicitly by the get_file_info() >method of the corresponding server object. >console_get_file_info() will simply leave this flag unset if overlapped >operations are impossible on consoles. > >The idea is that get_file_info() has a more flexible way to communicate >the capabilities of a file descriptor; this doesn't imply all fields are >completely independent of each other. > >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: [RFC] cleaner FD_TYPE_XXX implementation
by Mike McCormack 04 Jan '02

04 Jan '02

Hi Martin, looks good to me. The only complication i can see is if overlapped operations are possible on consoles. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >The FD_TYPE_XXX macros are used in the ReadFile() and WriteFile() >routines to invoke special read/write procedures for file descriptors of >certain types. I feel that for future improvements of Wine IO, it >might be important to distinguish between FD type (regular file, serial >port, pipe, ...) and FD attributes (can do overlapped IO, uses timeout, >....). > >That is the rationale for the following small patch. >Please comment. > >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Debugger on Solaris
by Robert Lunnon 04 Jan '02

04 Jan '02

I sent this message before but I dont think it reached the list. I am trying to make the debugger work on Solaris. The wineserver and debugger currently co-operate using ptrace to debug a client app, but on solaris the debugger deadlocks. It was previously thought that this was due to the threading model on Solaris which is different. (Different threads don't have different pids). The ptrace manual says that a client must call ptrace(PTRACE_TRACEME...) before it can be debugged but grepping the Wine source can find no useful references to TRACEME. Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though the process exists which causes the wineserver to assume the process is defunct and delete the app, apparently causing the deadlock (This deadlock will have to be fixed too !). Can anyone enlighten me as to what gotchas there are in fixing this since I don't know much about Linux behaviour (Though the linux ptrace mentions PTRACE_TRACEME too but apparently doesn't enforce it !) Bob

2 2

Re: We *really* need a development model change !
by Andreas Mohr 03 Jan '02

03 Jan '02

On Thu, Jan 03, 2002 at 04:55:03PM -0500, Robert Baruch wrote: > On Thursday 03 January 2002 07:54 am, Andriy Palamarchuk wrote: > The value is when you add new functionality (and possibly new tests) and old > tests break. Then you can pinpoint the changes that caused the old tests to > break. Again, that can only work if all the old tests succeeded, which means > you can't include tests that you know will fail in a release. No, you can ! This is exactly what everybody seems to assume we don't need: tests that are *known* to fail. (like Ulrich Weigand said: have status variables like FAIL, XFAIL, GOOD, XGOOD) The key to success is to check the *difference* to *expected* behaviour. And if there is indeed a *difference*, then we know that something changed and we need to examine it more closely and thus derive our ultimate result codes from it. Again, we can't just include tests that work on all occasions. Instead we should have tests that are as thorough/strict as possible, and thus with all sorts of failures, but which ultimately don't let the test suite fail, since they're *expected* to currently fail. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk 03 Jan '02

03 Jan '02

Sylvain Petreolle wrote: > Running test1.pl returns to me : > > [syl@snoop winetest]$ cd /c/winetest > [syl@snoop winetest]$ perl test1.pl > Can't locate wine.pm in @INC (@INC contains: > /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 > /usr/lib/perl5/site_perl/5.6.0/i386-linux > /usr/lib/perl5/site_perl/5.6.0 > /usr/lib/perl5/site_perl .) at test1.pl line 8. > BEGIN failed--compilation aborted at test1.pl line > 8.--- Sorry, I was not specific enough about the scripts launching instructions. It looks like you try to start the script from directory, which does not have wine.pm module. You need to put contents of the archive to directory "programs/winetest" of the wine source tree, build winetest application, then it will work. This directory should have wine.pm. Because of the problems I reported in the message (see below) the scripts require different launching. You can start the scripts as: # this script uses winetest framework winetest test1.pl #these don't perl test2.pl perl test_all.pl [...] >>However I found a few issues with winetest: >>1) For some reason running test_all.pl with winetest >>gives compilation error. I saw the same compilation >>error when I tried to use other Perl testing >>framework >>Test::Unit. >>2) Compilation failure when I try to run test1.pl >>directly with Perl, like "perl test1.pl" Let me know if you still can't start the scripts. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk 03 Jan '02

03 Jan '02

Alexandre Julliard wrote: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: >>Please comment on both my intended posting and the way I programmed the first >>version of the test suite (I'm not extremely happy with the current program; >>if you have any improvements, then get them here ASAP !). > > Look at programs/winetest, that's the tool we should use to write > tests IMO. Just looked at the tool. It only provides gateway from Perl to wine API functions, right? Advantages I see in using script-based tests: 1) tests can be used without recompilation 2) Perl is familiar to many developers 3) programming in scripting language is usually easier than in C 4) Perl is widely used for testing purposes and I expect to find many testing tools in Perl. Cons: 1) Many current Wine contributors don't know Perl 2) one more level of abstraction does not give significant advantages in this application. On the contrary, it is more difficult to locate cause of problems because developer has to go trough one more, often not familiar layer. Absense of strict typing in this layer will hurt a lot. Advantages of using C-based tests: 1) compilation has to be used to run the tests. In some cases this is an advantage. Before running the tests you'd better be sure it at least compiles in both environments. 2) C is the most familiar to developers language and the language itself is simpler than Perl 3) Documentation for Win32 API is C-oriented. Examples, given in documentation are in C or easy translated to C 4) Developers already have some testing code snippets in C Summary: Requirements to the unit testing tool: 1) should help to quickly create tests 2) easy to use, should help to involve as many developers as possible. 3) may be useful for developers, using Wine for there projects Because of the goals I'm more inclined to use C-based test suite. IMHO it is better suited for existing Wine developers audience and will provide us much bigger code pool. I'm even ready to have tests in both - Perl and C. The big question is a tool to test GUI. I did not find any OS Windows GUI testing frameworks :-( Comments, suggestions? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

11 60

[RFC] cleaner FD_TYPE_XXX implementation
by Martin Wilck 03 Jan '02

03 Jan '02

The FD_TYPE_XXX macros are used in the ReadFile() and WriteFile() routines to invoke special read/write procedures for file descriptors of certain types. I feel that for future improvements of Wine IO, it might be important to distinguish between FD type (regular file, serial port, pipe, ...) and FD attributes (can do overlapped IO, uses timeout, ...). That is the rationale for the following small patch. Please comment. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruw -X diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Wed Jan 2 12:50:02 2002 +++ MW/wine/files/file.c Thu Jan 3 14:55:13 2002 @@ -1436,9 +1436,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_READ, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1481,15 +1480,21 @@ /* fail on return, with ERROR_IO_PENDING */ SetLastError(ERROR_IO_PENDING); return FALSE; + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { return ReadConsoleA(hFile, buffer, bytesToRead, bytesRead, NULL); + } - case FD_TYPE_TIMEOUT: + else if ( FD_TYPE_HAS_TIMEOUT (type) ) + { close(unix_handle); return FILE_TimeoutRead(hFile, buffer, bytesToRead, bytesRead); + } - default: + else + { /* normal unix files */ if (unix_handle == -1) return FALSE; @@ -1499,7 +1504,6 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - break; } /* code for synchronous reads */ @@ -1639,9 +1643,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_WRITE, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1652,12 +1655,17 @@ } /* FIXME: try write immediately before starting overlapped operation */ return WriteFileEx(hFile, buffer, bytesToWrite, overlapped, FILE_OverlappedComplete); + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { TRACE("%d %s %ld %p %p\n", hFile, debugstr_an(buffer, bytesToWrite), bytesToWrite, bytesWritten, overlapped ); return WriteConsoleA(hFile, buffer, bytesToWrite, bytesWritten, NULL); - default: + } + + else + { if (unix_handle == -1) return FALSE; } diff -ruw -X diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/device.c Thu Jan 3 14:46:50 2002 @@ -83,7 +83,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_DEVICE; } /* create a device */ diff -ruw -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/file.c Thu Jan 3 14:53:56 2002 @@ -276,6 +276,7 @@ { struct stat st; struct file *file = (struct file *)obj; + int fd_type = FD_TYPE_DEFAULT; assert( obj->ops == &file_ops ); if (reply) @@ -308,7 +309,10 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } - return FD_TYPE_DEFAULT; + + if ( file->flags & FILE_FLAG_OVERLAPPED ) + fd_type |= FD_TYPE_FLAG_OVERLAPPED; + return fd_type; } static void file_destroy( struct object *obj ) diff -ruw -X diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/named_pipe.c Thu Jan 3 14:50:17 2002 @@ -197,7 +197,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_NAMED_PIPE; } static struct named_pipe *create_named_pipe( const WCHAR *name, size_t len ) diff -ruw -X diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/pipe.c Thu Jan 3 14:50:29 2002 @@ -140,7 +140,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_PIPE; } static void pipe_destroy( struct object *obj ) diff -ruw -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Wed Jan 2 12:50:05 2002 +++ MW/wine/server/protocol.def Thu Jan 3 14:53:27 2002 @@ -544,12 +544,22 @@ int fd; /* file descriptor */ int type; /* the type of file */ @END +#define FD_TYPE(x) ((x) & 0xff) + #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1 #define FD_TYPE_CONSOLE 2 -#define FD_TYPE_OVERLAPPED 3 -#define FD_TYPE_TIMEOUT 4 +#define FD_TYPE_DEVICE 3 +#define FD_TYPE_NAMED_PIPE 4 +#define FD_TYPE_PIPE 5 +#define FD_TYPE_SERIAL 6 +#define FD_TYPE_SOCKET 7 + +#define FD_TYPE_FLAG_OVERLAPPED 0x100 +#define FD_TYPE_FLAG_TIMEOUT 0x200 +#define FD_TYPE_IS_OVERLAPPED(x) ((x) & FD_TYPE_FLAG_OVERLAPPED) +#define FD_TYPE_HAS_TIMEOUT(x) ((x) & FD_TYPE_FLAG_TIMEOUT) /* Set a file current position */ @REQ(set_file_pointer) diff -ruw -X diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/serial.c Thu Jan 3 14:54:09 2002 @@ -192,6 +192,7 @@ static int serial_get_info( struct object *obj, struct get_file_info_reply *reply ) { struct serial *serial = (struct serial *) obj; + int fd_type = FD_TYPE_SERIAL; assert( obj->ops == &serial_ops ); if (reply) @@ -209,13 +210,13 @@ } if(serial->attrib & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; - if( (serial->readinterval == MAXDWORD) && - (serial->readmult == 0) && (serial->readconst == 0) ) - return FD_TYPE_DEFAULT; + else if( !((serial->readinterval == MAXDWORD) && + (serial->readmult == 0) && (serial->readconst == 0)) ) + fd_type |= FD_TYPE_FLAG_TIMEOUT; - return FD_TYPE_TIMEOUT; + return fd_type; } static void serial_poll_event(struct object *obj, int event) diff -ruw -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/sock.c Thu Jan 3 14:53:11 2002 @@ -288,7 +288,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_SOCKET; } static void sock_destroy( struct object *obj )

1 0

[Shrinker] Another landmine
by Robert Baruch 03 Jan '02

03 Jan '02

More stepping through the code, comparing Windbg to gdb, and I found another landmine. Shrinker gets the address of the NTDLL procedure LdrAccessResource, and looks for this code: FF74XXXX push [esp+X] E8XXXXXXXX call .... Instead, it finds an unimplemented procedure in Wine. So now I will look at LdrAccessResource (and friends) to see what's involved in implementing it, whatever it is. --Rob

7 11

Mixed-mode CD Labels
by Chris Green 02 Jan '02

02 Jan '02

Hi, I've just experimentally, in my own copy of the CVS, changed the code in misc/cdrom.c so that it handles mixed mode CDs the same as data CDs for retrieving CD labels. (In the process of trying to get Age of Empires 1 to run in single-player mode). And surprisingly, it worked! (mind you AOE is not fast under wine, but that's another problem). Does anyone have any comments on this approach? if not I'll submit a patch... regards Chris Green

5 12

winelib, CRT_INIT
by Bill Medland 02 Jan '02

02 Jan '02

Does anyone know how _CRT_INIT should interact with winelib? I have a load of code which uses it in the DllMain but I presume that it is a Microsoft hack that the compiler/linker cleverly converts to something else Bill

1 0

Re: some other console fixes
by Marcus Meissner 02 Jan '02

02 Jan '02

On Tue, Jan 01, 2002 at 05:47:26PM +0100, eric pouech wrote: > as spotted by Marcus, but only half done, the fg & bg colors were > inverted > moreover, this patch also some initialisation problems in wineconsole Oh, sorry for not fixing correctly. Eric, I have also found following additional problems: - The Apply button in the Propertysheet never gets enabled. It always stays grayed out. When I press [Ok], the changes do get active, but are not saved into the registry. Somehow the property sheet does not get noticed that values inside it have changed... I do not have a clue how that works. - The default font is not fixed pitch. This is strange, since the font enum appears correct. I hardcoded the default font to Console, but this is not a good solution. Testing now appears to provide only correct fonts. Strange. - IDA text display is slow, it does a lot of redraws all the time. I tried the following patch, which makes redraws async: Index: user.c =================================================================== RCS file: /home/wine/wine/programs/wineconsole/user.c,v retrieving revision 1.4 diff -u -r1.4 user.c --- user.c 2002/01/01 00:14:02 1.4 +++ user.c 2002/01/02 18:59:18 @@ -501,7 +501,9 @@ r.bottom = (bm - data->curcfg.win_pos.Y + 1) * data->curcfg.cell_height; InvalidateRect(PRIVATE(data)->hWnd, &r, FALSE); WCUSER_FillMemDC(data, tp, bm); + /* UpdateWindow(PRIVATE(data)->hWnd); + */ } } However, while the redraws do work, they are coming very late sometimes, as if repaints do not appears frequently enough. Strange. - Mouse presses should be sent as input events. If I get too annoyed I just can just implement it ;) - wineconsole without arguments crashes: 6 faulted at EIP=0x00000043, CR2=0x00000000, EAX 0x00000001 EBX 0x401ed0bc, ECX 0x40596cec, EBP 0x40596e18 EDI 0x00000000, ESP 0x002b:0x40596e08 FS 0x008f, pid 1189 exception 0xc000001d at address 0x00000043, fs 8f, pid 1189 () wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ((null)) (0) Read the Wine Developers Guide on how to set up winedbg or another debugger Ciao, Marcus

2 1

[PATCH] Async IO on regular files
by Martin Wilck 02 Jan '02

02 Jan '02

This patch implements asynchronous I/O on regular file objects. It is against the current (02/01/02) CVS version of wine. I know that async IO on regular files is pretty pointless at the moment, but it's better to have it working as expected, I guess ... The patch was successfully tested with a simple test program that checks the sequence of scheduled reqeuests and file positioning via the lpOverlapped->Offset and OffsetHigh fields. server/file.c: struct file: add two async_queue fields (read/write) for async IO. create_file_for_fd(): Intialize async queues. destroy_file(): destroy async queues. file_poll_event(): invoke async requests for overlapped files. file_queue_async(): implement the queue_async() method. file_get_info(): return FD_TYPE_OVERLAPPED for overlapped files. files/file.c: FILE_AsyncReadService(): Use pread() for fd's that support seeking. FILE_AsyncWriteService(): Use pwrite() for fd's that support seeking. Regards Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: mvcrt.ungetc and stdio buffering
by Jon Griffiths 02 Jan '02

02 Jan '02

>Have a look at the following two messages from Marcus Meissner to >wine-devel and wine-patches: Hmm, those links dont work for me, however I remember: The header files for stdio have macro versions of putc/getc so your implementation must use the FILE structure fields in a binary compatable way (as they are currently; I implemented the code to pretend that the buffer is alway empty and needs to be reread/put on every operation). Provided you can make optimised VC++ compiled programs (i.e. those that use the macro version of get/putc) work, you dont have any extra threading issues that the code should handle already (but probably doesn't; large sections are not yet thread safed). The performance improvement would be significant also. You should make sure you test your changes thoroughly tho, as the file code is rather vital to avoiding needing native msvcrt ;-) Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

1 0

Windows NT/2000 Native API Reference by Nebbett
by Dan Kegel 02 Jan '02

02 Jan '02

I have the dubious distinction of having hired a friend back in 1997 to write perhaps the first PE compressor utility. It eventually became the core of http://www.neoworx.com/products/neolite/ (a competitor to Shrinker). He mentioned recently that he found "Windows NT/2000 Native API Reference" by Gary Nebbett http://www.amazon.com/exec/obidos/ASIN/1578701996/ to be useful in updating his compressor to handle .exe's that use some of the newer API calls. http://kt.linuxcare.com/kernel-traffic/kt20000724_77.epl mentions it, too, as do many posts in comp.os.ms-windows.programmer.nt.kernel-mode, so it appears to be useful. Just thought I'd mention that book in case anyone here hasn't heard of it. - Dan

1 0

What have I done to my debugger?
by Bill Medland 01 Jan '02

01 Jan '02

I'm getting the wrong sort of terminal. Why? I vaguely remember doing something to the registry settings for the debugger about a month ago but I can't remebber what. Since then I have not been tripping it anyway. However I am now investigating a problem that does trip the debugger. However it now comes up with an enormous terminal of some sort with terrible font and bad agreement between font and cursor positioning, so that important data disappears off the right of the screen before wrapping. However in the old days it used to use an xterm. I'd like to go back to that. Did I do that or is it a result of the stuff going on with the debugger? TIA Bill p.s. Merry Christmas to all.

3 6

Re: mvcrt.ungetc and stdio buffering
by Mike McCormack 01 Jan '02

01 Jan '02

Hello Waldek, Have a look at the following two messages from Marcus Meissner to wine-devel and wine-patches: Mon, 23 Jul 2001 09:08:31 -0400 http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001- 07/date/article-185.html Sat, 21 Jul 2001 09:14:03 -0400 http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/200 1-07/date/article-102.html You can probably also use the native MSVCRT.DLL, from your windows installation. Mike > Recently I tried to run g77 compiled Fortran program under Wine. > It seems that to do any input g77 uses `ungetc'. Currently, > Wine msvcrt has unbufferd stdio. I would like to add buffering > and implement `ungetc'. Are there any traps (thread safety ??) > or will strightforward implementation work ? > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

current cvs doesn't compile with freetype-2.0.3
by Ben Stanley 01 Jan '02

01 Jan '02

Hi, I tried compiling current cvs wine on RH 7.2, and it fails... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:43:31: freetype/ftnames.h: No such file or directory make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi' It seems that the autoconf test for freetype/ftnames.h doesn't work properly. The file is not present in the RH package, and is not included in the freetype-2.0.3 tarball either. BTW, I'm not on the list atm. Ben.

2 2

mvcrt.ungetc and stdio buffering
by Waldek Hebisch 31 Dec '01

31 Dec '01

Recently I tried to run g77 compiled Fortran program under Wine. It seems that to do any input g77 uses `ungetc'. Currently, Wine msvcrt has unbufferd stdio. I would like to add buffering and implement `ungetc'. Are there any traps (thread safety ??) or will strightforward implementation work ? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Re: Using windows dlls in unix shared libraries
by lawson_whitney＠juno.com 29 Dec '01

29 Dec '01

On Fri, 28 Dec 2001, Robert Jonsson wrote: > Hi all, > > I just subscribed to this list, I hope my questions aren't evidently > answered elsewhere, I tried to do some homework browsing the docs and > parts of the mailing list, but then again I'm no pro so I might have > missed it. > > The background story: > There is a plugin system for professional audio applications in Windows > called VST. I suppose it does pretty much the same job as a multimedia > codec. With the exception that they have internally generated GUIs! > Perhaps a winamp plugin would be the closest match. > There is a similar format in Linux called LADSPA (www.ladspa.org). > Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. > > The question: > I don't know that much about Wine internals, but all the example > applications I've looked at use the wine executable as boot loader. Does I thought to quibble with that, but it is a pretty fair analogy after all. Wine (including wineserver and wine builtin dlls) is a *NIX application, but it does provide "OS" services. It sort of needs an address space or two to kick around if it is going to be able to load native dlls that are not relocatable, FI. > that mean that this is the only way to start a wine application? Well, something has to be sure the wineserver is started. > The way I'd like to use it is like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - > VSTplugin Can your ladspaplug not fork and exec wine to run your vst wrapper? > > A possible solution would be to startup the VSTplugin in another > application and do IPC between the LADSPAplugin and the > VSTplugin-proxyhost. > Like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> > winebased_VSThost (LoadLibrary vstplugin) - VSTplugin > This does however seem akward... Is it possible to do it in an easier way? There isn't all that much to the wine executable these days. Most of Wine is in the builtin dlls and the wineserver. Have a look at <wine>/miscemu/main.c. If you think you can get that to run inside your plugin, maybe you can. Codeweavers did a crossover plugin whosis for linux browsers, I think, that would have had to address the problems. Lawson

1 0

Re: We *really* need a development model change !
by Andriy Palamarchuk 29 Dec '01

29 Dec '01

Simplicity is one of the goals of the testing framework, but besides being simple the framework should be powerful enough for such big project. I'm looking for existing library which would suit our needs. Unit test framework "Check" looks promising. It provides many features which I'd love to use for our tests, including: - protection of the test address space - tests crashed do not put down the whole test suite and are reported. At the same time you can request to run tests in the same address space what is good for debugging. - grouping tests in suites, tree-like grouping of the test suites. You can choose to run only subset of the tests - having "set up" and "tear down" sections which can be used to set up tests and free resourses after. - a few forms of output - from silent to detailed Individual test looks like (section from manual): START_TEST(test_create) { fail_unless (money_amount(five_dollars) == 5, "Amount not set correctly on creation"); fail_unless (strcmp(money_currency(five_dollars),"USD") == 0, "Currency not set correctly on creation"); } END_TEST They also give information how to configure the tests with autoconf. The issues which need to be resolved: 1) License - GPL. Is it Ok to have the test suite under GPL? 2) Environment - POSIX. The library uses POSIX calls to manage processes, in particular functions fork, _exit, write, read, close, getppid, getpid, pipe. Calls "fork" , "_exit" and "getppid" are used only when test runs in FORK mode. We don't need to have address space protection under Windows - tests there should not crash. The rest of functions are used for communication between the test launcher and tests and can be implemented with using corresponding Win32 calls. After implementing these changes the framework can be used in pure Win32 environment, without Cygwin. Let me know if you are interested. I'll start to work on the port. Meantime we can start to use the framework under Wine and on Windows with Cygwin. More information about Check you can find here: http://check.sourceforge.net/ - home page http://sourceforge.net/project/showfiles.php?group_id=28255 - tutorial Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Getting "Practice Exam" software working
by Dax Kelson 29 Dec '01

29 Dec '01

We have a training room full of students who are taking a cisco networking design class. The class is basically all lecture so they don't normally use a computer, but tomorrow the students need to take a practice exam. The student workstations are running Red Hat Linux 7.2. Their student books come with a CDROM with a practice exam program that is, of course, a windows app. I've tried with the Wine that shipped with RH7.2, todays CVS snapshot, and Codeweaver's preview 5 all with the same results. It *almost* works. I would rather get it working so we don't have install windows just for them to run this one app. The problem starts up ok as seen in the screenshots 1 through 3 below. http://www.gurulabs.com/files/snapshot1.png http://www.gurulabs.com/files/snapshot2.png http://www.gurulabs.com/files/snapshot3.png http://www.gurulabs.com/files/snapshot4.png <- Problem here The problem is the sample questions and answers don't show up. http://www.gurulabs.com/files/snapshot5.png The "exhibits" seem to work fine. I'm using 100% builtin. There are no warnings or outputs that are displayed when exam question window starts. Any help would be greatly appreciated. Please save me from having to install windows on 13 computers. :) Dax Kelson

2 1

Using windows dlls in unix shared libraries
by Robert Jonsson 28 Dec '01

28 Dec '01

Hi all, I just subscribed to this list, I hope my questions aren't evidently answered elsewhere, I tried to do some homework browsing the docs and parts of the mailing list, but then again I'm no pro so I might have missed it. The background story: There is a plugin system for professional audio applications in Windows called VST. I suppose it does pretty much the same job as a multimedia codec. With the exception that they have internally generated GUIs! Perhaps a winamp plugin would be the closest match. There is a similar format in Linux called LADSPA (www.ladspa.org). Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. The question: I don't know that much about Wine internals, but all the example applications I've looked at use the wine executable as boot loader. Does that mean that this is the only way to start a wine application? The way I'd like to use it is like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - VSTplugin A possible solution would be to startup the VSTplugin in another application and do IPC between the LADSPAplugin and the VSTplugin-proxyhost. Like this: Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> winebased_VSThost (LoadLibrary vstplugin) - VSTplugin This does however seem akward... Is it possible to do it in an easier way? Btw, I know about the avifile project, don't know the history but it is based on wine right? However, to my knowledge avifile supports only a very limited amount of API calls, ie no graphics/window calls (perhaps except some trivial ones). Which would probably make it pretty hard to implement the above...

1 0

err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available
by Rein Klazes 26 Dec '01

26 Dec '01

Date: Wed, 26 Dec 2001 12:51:22 +0100 X-Agent-Group: X-Agent-Format: 0 0 0 0 0 500000 0 0 1 0 "*" 0 Hi, This patch makes a two of my programs fail with the subject error message: | ChangeSet ID: 1008789390367047399282455 | CVSROOT: /opt/cvs-commit | Module name: wine | Changes by: julliard@wine2. 01/12/19 14:16:30 | | Modified files: | dlls/kernel : kernel32.spec | dlls/ntdll : Makefile.in debugtools.c ntdll.spec rtl.c | dlls/ole32 : ifs.c | graphics/win16drv: font.c | include : heap.h ntddk.h winbase.h winnt.h | memory : heap.c selector.c | Added files: | dlls/ntdll : heap.c | | Log message: | Moved heap functions to ntdll. | Got rid of internal heap flags. | Reimplemented MapLS to not depend on the segptr heap. Both programs use native win98 commctrl,comctl32 dll's. One of them is CDmage, available at http://cdmage.cjb.net Any suggestions? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

We *really* need a development model change !
by Andreas Mohr 26 Dec '01

26 Dec '01

Hi all, due to the number of regressions I found few days ago, it occurred to me that we really need an API test suite now. Thus I went ahead and implemented a test functionality for LoadModule16(). The result: 7 of the 21 tests that I implemented were FAILING !! That's ONE THIRD. And that for such a highly basic function as LoadModule16(). That's quite incredible. I guess we really should change our development model from trying tons of programs to *systematically* testing functions and Windows mechanisms now. If we can show everyone where stuff is failing, it might be a lot easier to attract new people. I attached a preview of the posting I intend to post on *tons* of Windows devel newsgroups ("Call For Volunteers"). That way we might actually get hold of hundreds of Windows developers helping us implement a complete test suite (complete tests of up to 12000 Windows functions). Not to mention the additional PR we might get out of this... If this works, then we'd need someone in charge of managing the assignment of specific windows functions to specific programmers. I won't do that (very limited time). Anyone from Codeweavers up to the task ? Or maybe someone non-developer and rather foreign to the Wine devel could do that task ? About the program: My goal was to get a program with very easy parsing interface: fields separated by colons, nothing fancy and difficult to implement, ... A .exe can be found at: http://home.nexgo.de/andi.mohr/download/wt_ldr16.exe Please comment on both my intended posting and the way I programmed the first version of the test suite (I'm not extremely happy with the current program; if you have any improvements, then get them here ASAP !). As 12000 Windows functions is an enormous number, I think we should really start doing this NOW instead of years later once Wine really needs this. Wine does not extremely need this yet, but we're getting pretty damn close to that already. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

3 2

Re: We *really* need a development model change !
by Andriy Palamarchuk 26 Dec '01

26 Dec '01

C Unit test frameworks I found after a quick search: http://check.sourceforge.net/ http://people.codefactory.se/~spotty/cunit/ http://freshmeat.net/projects/autounit/ C++: http://sourceforge.net/projects/cppunit/ Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk 26 Dec '01

26 Dec '01

Andreas Mohr wrote: > I guess we really should change our development model from trying tons of > programs to *systematically* testing functions and Windows mechanisms now. > If we can show everyone where stuff is failing, it might be a lot easier > to attract new people. I *completely* support this idea. Benefits of such test suite are enormous. Existing developers can contribute a lot by adding test snippets for the functions they create. Now they create such snippets anyway and throw them away. > I attached a preview of the posting I intend to post on *tons* of Windows > devel newsgroups ("Call For Volunteers"). That way we might actually get > hold of hundreds of Windows developers helping us implement a complete > test suite (complete tests of up to 12000 Windows functions). > Not to mention the additional PR we might get out of this... Lets ask for help only after the suite structure is more/less defined and we'll be able to give people something to work on. Comments: - Don't want to reinvent the weel. Is there any existing test suite framework we can use? Sorry, I can't suggest any for C but I'm very impressed with JUnit in Java. It is even Ok if the framework is GPLed or LGPLed - I don't think any company will make buziness based on the test suite. - I /personally/ prefer CL interface only for such suite - it would be better if the suite print summary information and information about failed tests only - make the test suite more "visible" for existing developers. Ask them to run the test suite before submitting a patch? - I think the suite test will consist from a few separate applications because different tests may have different requirements to GUI configuration, processes, etc. We need a way to run all the applications in one batch. - define variable which indicates whether the suite runs under Wine. Such indicator can be used for Wine "white-box" testing. - it would be greate to have functionality to support output comparison? For some functionality it is easier to write tests to compare output instead of doing explicit checks (e.g. tests, involving a few processes). The output can be redirected to file and files compared. If we use files we need to store files for Wine and a few versions of Windows :-( - the suite applications size will be pretty big. Is it better to move it to separate CVS tree? - what about running the suite weekly (or daily) automatically and publishing the results to wine-devel? - most developers on this list have access to one version of Windows. Is it difficult to create "testing farm" with remote access to a few versions of windows? This would help developers to test their code on a few platforms. Existing environments in the companies, involved in the project can be used. - I remember long time ago there was a post on wine-devel about using Perl or Perl-like language for unit testing. What is current status of that project? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 2

Cooperation between Odin & Wine
by Sander van Leeuwen 26 Dec '01

26 Dec '01

Hi, As some of you might remember I'm the lead developer of the Odin project. (project for OS/2 with the same goals as Wine). Odin is partly based on Wine code. The core dlls (gdi32, user32, kernel32) + some special dlls (winmm, directx, winsock) use some Wine code, but is basically incompatible with Wine for obvious reasons. Most of the remaining dlls are based entirely on Wine code. The last few years there has been little cooperation between both projects for several reasons. One of them is that we have far fewer active developers and cooperation sometimes proved to be difficult. Some source files of the two project had grown apart since changes were never merged back into Wine. Now, I'm trying to change this situation, but am wondering how to proceed. I can post bug fixes to this list, but it will be difficult for me to actually test these changes in Wine itself. (too time consuming) Posting diff files is not always possible due to the major differences between source files. Merging changes from Wine into our source tree is no problem. We can do that ourselves. However, it would be nice if compiler incompatibilites (we use IBM VisualAge C++, not GCC) could be resolved. There aren't many, but the IBM compiler is not always as flexible as GCC and of course doesn't understand any GCC extensions. It would be a big help if incompatible code could be changed. Switching compilers is not an option for us. I can post a (small) list of changes we had to make. The license of our project is not compatible with Wine, but the dlls that are largely based on Wine (such as comctl32, shell32, ole) are an exception to the project license. The sources of those dlls are released under the Wine license. In case there is ever interest in the other sources, then you can just ask me. I'd be happy to 'donate' them to Wine. For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). There you can find out where to download the sources (cvs). The next post from me will contains some patches for bugs in Wine that I've recently found. Sander

2 2

CVS server
by Dimitrie O. Paun 26 Dec '01

26 Dec '01

It looks like we're running an old version of CVS on the server, as it complains it does not understand #cvs up -C is it possible to upgrade it? That would be a good idea irrespective of the -C problem, as the new versions fixed quite a few (nasty) bugs. -- Dimi.

2 1

Re: Wine Tasklist (UNC)
by Mike McCormack 26 Dec '01

26 Dec '01

Hi Francois, I think the best way to handle UNC pathes is to do it properly; Wine should talk SMB/NBT directly to other machines on the network, not through Linux's VFS layer. This approach would give high level of flexability to Wine. We could: * support NetDDE and DCOM with a common code base * use Windows file permissions and security properly * support unicode share names properly * support named pipes, etc across the network * eliminate SMB<->VFS<->SMB problems eg. parsing /etc/fstab There's three options: 1) write our own SMB code (wineserver talks NetBIOS/SMB) i have a short snippet of code to resolve NetBIOS names in CreateFile, but that is only the beginning of the effort. 2) link with a LGPL'ed CIFS implementation. http://www.ubiqx.org/libcifs/ (very incomplete, but maybe possible later, may still have threading issues) 3) get Samba to provide us with a Unix domain socket to talk with. (SambaTNG looks like the best bet there.) i have experimented with linking Wine to samba's libsmbclient and use it to open files. That works (i have a test patch), has threading and licensing issues (it's GPL). This would be alot of work, but i think it's the only way to do it properly. Mike > * UNC path handling > - for drives '\\.\e:', devices > - for network paths > - there's been a patch related to this recently but I believe it does > not cover all cases > - integrate with Samba to handle network UNC paths > - provide a way to mount/unmount drives at runtime, especially > network drives. One should be able to disable this in the config > file (for security reasons). > - Support for 'persistent' mounts... will require modifying the way w > specify which drives are mounted where. > - provide an applet to mount/unmount drives while Wine is running. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: Bulletproof the debugger.
by Michael Stefaniuc 26 Dec '01

26 Dec '01

On Fri, Dec 21, 2001 at 01:52:12PM -0800, Medland, Bill wrote: > Bill Medland (medbi01(a)accpac.com) > Don't ask me why but on my setup vsnprintf returned a value greater than This is the new and correct behavior according to the C99 standard. All snprintf function should return in error case the number of characters that would have been written to the buffer if the size of buffer would have been big enough. This change while usefull will brake a lot of things. IMO the glibc is still using the old behavior. bye michael > the size of the buffer (much bigger), resulting in the debugger tripping > a segment violation. > Considering the location of this code I see no problem with using belts and > braces; it isn't going to be executed much but when it is we want it to work > (despite braindead operating systems) -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 3

Patches for several bugs
by Sander van Leeuwen 26 Dec '01

26 Dec '01

Hi, Here are the bug fixes I promised. There are more, but I can post those at a later time. - controls\button.c CB_Paint, line 806 hBrush = SendMessageW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); if (!hBrush) /* did the app forget to call defwindowproc ? */ hBrush = DefWindowProcW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); -> (Auto)Check, (Auto)Radio & (Auto)3State buttons send WM_CTLCOLORSTATIC instead of WM_CTLCOLORBTN (verified in NT4) (fixes opening dialog buttons in Opera 6 (choose interface)) - dll\user32\text.c TEXT_GrayString, line 499 if(!hdc) { DeleteDC(memdc); return FALSE; } -> DC leak - COMCTL32: Comboex, rebar, tooltips, toolbar: NEVER delete the font object received by WM_SETFONT -> See attached diff files for comboex, rebar & toolbar. Our tooltips has too many differences for diff to produce usable output, but the changes are similar to the other three. - COMCTL32: Tooltips: wrong COMCTL32_Free calls -> 4 calls with wrong pointer: COMCTL32_Free(&lpttsi); should be COMCTL32_Free(lpttsi); - user32: frame tracking * - Only draw changed track frame instead of clearing the old one and * drawing the new one (less flickering) * - Send WM_MOVING when moving a window * - Send WM_SIZING only when sizing a window * - Fixed handling of rectangles changed by WM_SIZING/MOVING -> Can't easily produce diff file. Too many changes. (check src\user32\wintrack.cpp in our CVS tree) - USER32: groupbox redrawing fixes -> I am not 100% sure the same happens in Wine, but it looks like that. When an application changes the font or the text of a groupbox (smaller font or fewer characters), then the old text has to be erase properly or else you'll still see part of it. If I remember correctly, that could be seen in Opera 5.12 (property dialogs) -> Again, too many changes to produce a diff file. (check src\user32\button.cpp, BUTTON_SetText & BUTTON_SetFont) - USER32: static control -> our version supports more styles (SS_CENTERIMAGE, SS_REALSIZEIMAGE) and features (SS_ENHMETAFILE) (src\user32\static.cpp) Sander

1 0

Re: DOS packing patch (fix)
by Lionel Ulmer 25 Dec '01

25 Dec '01

Hi all, I am a bit worried by this patch : I looked at how "pshpack1.h" works, and it uses the '#pragma pack(1)' method when compiling with GCC. > +/* WARNING: one byte packed structs from here !! (i.e. not DWORD aligned) */ > +#include "pshpack1.h" > + And I wonder if this really works as with the latest versions of GCC (2.95.3 onwards AFAIK), '#pragma pack(1)' is ignored (at least on my self-compiled GCC :-) ) and you need to use the '__attribute((__packed__))' construction after each structure. But well, I may say completely stupid things as otherwise a lot of bugs would exist in Wine... Lionel PS: Merry Christmas all :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

16 bit comm issue
by Mike McCormack 24 Dec '01

24 Dec '01

Hi, There's a problem with the current 16bit comm architecture which i'm not sure how to solve correctly. If a 16bit Windows programs uses EnableCommNotification to receive WM_COMMNOTIFY messages then sits in a message loop waiting for them, it will never receive them because there is no chance for APC that sends the message (COMM16_ReadComplete) to run. I have a patch for this problem which puts an alertable wait in GetMessage(16), which i posted in October. What is the problem with this method, and is there a better solution to the problem? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]
by Andreas Mohr 24 Dec '01

24 Dec '01

On Tue, Dec 04, 2001 at 02:54:50PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1007495689308334133587778 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/12/04 14:54:50 > > Modified files: > dlls/kernel : kernel_main.c wprocs.spec > dlls/ntdll : Makefile.in ntdll.spec > dlls/winedos : Makefile.in dosvm.c int09.c module.c > winedos.spec > graphics : dispdib.c > include : callback.h miscemu.h > miscemu : main.c > msdos : Makefile.in dosmem.c dpmi.c int20.c int21.c > int2f.c interrupts.c ioports.c > Added files: > dlls/winedos : devices.c dosaspi.c dosexe.h int10.c int16.c > int17.c int19.c int20.c int21.c int29.c int31.c > int33.c ioports.c vga.c vga.h xms.c > Removed files: > include : dosexe.h vga.h > msdos : devices.c dosaspi.c int10.c int16.c int17.c > int19.c int29.c int33.c vga.c xms.c > > Log message: > Moved most of the real-mode stuff to dlls/winedos. > > Patch: http://cvs.winehq.com/patch.py?id=1007495689308334133587778 This one probably breaks a whole heap of older Win3.x apps. When I started the Win98 setup.exe for fun, it choked on int 0x21 "list of lists" (DOS_LOLSeg not initialized). Trouble is that we initialize DOS variables in case of DOS programs *only*. This is rather fatal IMHO, especially in the case of List Of Lists, which is a pretty important structure with lots of information that some Win 3.x programs might rely on. Thus DOS stuff should be reorganized somehow. Any suggestions ? IMHO probably winedos should get loaded as soon as DOS3Call() gets called even once. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
by Laurent Pinchart 24 Dec '01

24 Dec '01

When trying to install The Longest Journey (an adventure game), I ran into a problem with modal message boxes. The installer displays at some point a task modal message box, but for some reason the box disapears almost instantly, and I'm stuck with a focused installshield screen on which I can't do anything as the task modal msgbox is invisible and unfocused. I'd like to implement the modal message boxes to fix my problem, but I don't know where to start. Could someone give me a few indication about what would be required to achieve a proper behaviour or modal message boxes ? Thanks. Laurent Pinchart

4 8

Terrible bug: WinExec16, DOS programs
by Andreas Mohr 24 Dec '01

24 Dec '01

Hi all, I just found out that WinExec16 doesn't even support starting DOS programs. Whereas LoadModule16 doesn't seem to support loading DOS programs (error 22, which is not documented for LoadModule16), WinExec16 definitely does launch command.com on Win98SE. Not so when using Wine. What to do about that ? More specifically, which functions to change how exactly to support this ? (the whole interoperation between WinExec, WinExec16, LoadModule*, LoadLibrary*,CreateProcess etc. is highly problematic). This thing makes me get slightly worried about our Win16/DOS compatibility as a whole... :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Windows screensaver.
by gleb＠nbase.co.il 24 Dec '01

24 Dec '01

Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Thanks, -- Gleb.

2 2

Re: License debate conclusion
by James Tabor 23 Dec '01

23 Dec '01

Dan Kegel wrote: > > Roger Fujii wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > - Dan Hum????????? Like the ODIN Project! James

1 0

Re: License debate conclusion
by Dan Kegel 23 Dec '01

23 Dec '01

James wrote: > > Dan Kegel wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. Its protection might not be airtight -- but it would clearly > > communicate the spirit. And my impresson was that the majority of > > Wine developers agree. > > Like the ODIN Project! Good point. The ODIN project's license is at http://odin.netlabs.org/License.phtml There was some talk of sharing code between Wine and Odin in 1999; see http://www.winehq.com/News/1999-50.html#0 We might want to update http://www.winehq.com/others.html to reflect the current status and license of the Odin project. I'm not quite sure whether the Odin license is compatible with the LGPL. It looks fairly GPL compatible, but I didn't look hard. - Dan

1 0

Re: License debate conclusion
by Roger Fujii 23 Dec '01

23 Dec '01

Alexandre Julliard <julliard(a)winehq.com> wrote: > > My conclusion is that there clearly isn't enough support in the > developers community to justify changing the license. So I'm not going > to proceed with any change, either now or in the foreseeable future. hurrah. before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs. This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license. -r

6 6

[Fwd: Re: License debate conclusion]
by lee 23 Dec '01

23 Dec '01

> I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with Transgaming > might be to start a campaign to get people to buy Transgaming subscriptions, > or perhaps try to rummage up enough of a one-time payment to get Transgaming > to contribute their current changes back. I suspect that there's some > such arrangement they'd be happy with. I tried to do just that and got rejected ( error after submitting and didn't want to try 'again' until they contact me ) by the online payment system for some odd reason....I wonder how many others have experineced this ( I checked my input twice and had all *'s filled out )........granted it could be isolated in that I made some minor goof on form..-we'll see. just a fyi in case it wasnt' me.. lee -===

1 0

Re: [PATCH] forward tab notification to the parent
by Andreas Mohr 23 Dec '01

23 Dec '01

On Sat, Dec 22, 2001 at 02:31:56PM +0000, Gerard Patel wrote: > The following patch : > ChangeSet ID: 1008622332606314052827656 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/12/17 15:52:12 > > Modified files: > dlls/comctl32 : tab.c > > Pass on all unhandeled messages to the owner. > > leads to bad regressions with some apps. > > The attached patch has the same positive effect on hh.exe > but without the regressions. Confirmed: That patch had horrible effects on desk.cpl. Applying your patch fixed it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

fixme:win32:DeviceIoControl Unimplemented control 256 for VxD
by Matts Kivik 23 Dec '01

23 Dec '01

[root@localhost Visual Pinball]# wine Vpinball.exe +relay +snoop +vxd x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b4be8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b50c4)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device NWLINK wine: Unhandled exception, starting debugger... I get the following errors when trying to run a windows program called Visual Pinball. Wine release 20011108. In addition to the crash, the toolbars are not drawn. Some tools in the toolbars are drawn when I "hoover" over them with the mouse. I another thread I have read that the VNETBIOS call is to check the MAC adress, but what is the NWLINK doing ? _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net

1 0

Re: CVS regression.
by Gerard Patel 23 Dec '01

23 Dec '01

At 02:30 PM 22/12/2001 -0800, you wrote: >I'm in the processess of doing a cvs regression to find out what broke >half-life in the main wine. The first problem appears in the "2001-11-8 >EDT" cvs, but it's not the same promlem as I was having with the current >cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 >EDT". > >But unless anyone has any ideas I though I'd start working on what patch >did it, and I was wondering if "2001-11-13 EDT" was the cvs at the >begining or end of the day (before or after that days pathces were >applied). And if the dates in the wine.cvs newsgroup are accurate. > >I'm rather new at this so any advice would be welcome. Did you read documentation/cvs-regression ? I updated some weeks ago to add precisely that you can use times up to the second so that it's possible to apply each patch separately. I use http://www.winehq.com/hypermail/wine-cvs/ to find exact patches times. > >P.S. The error i'm looking for is a timeout of a CriticalSelection when >you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" >cvs is an unhandeled exception when it first goes to the "Loading..." >screen. > Unfortunately, it is not impossible that a first breakage is completed by another a few days after. The more important breakage to find is the first (unless the second breakage is an attempt to fix the first) Another possibility is that the 2 problems are only different manifestations of a single problem; you can have a thread crash nicely, triggering the debugger, or in different circumstances nastily, without much messages. In the latter case, it can happen that another thread is blocked by the crashed thread and displays a critical section wait timeout. It will not be possible for me to help you more until next year, I'll not have internet access until then. Good luck. Gerard

1 0

CVS regression.
by Daniel Sabo 22 Dec '01

22 Dec '01

I'm in the processess of doing a cvs regression to find out what broke half-life in the main wine. The first problem appears in the "2001-11-8 EDT" cvs, but it's not the same promlem as I was having with the current cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 EDT". But unless anyone has any ideas I though I'd start working on what patch did it, and I was wondering if "2001-11-13 EDT" was the cvs at the begining or end of the day (before or after that days pathces were applied). And if the dates in the wine.cvs newsgroup are accurate. I'm rather new at this so any advice would be welcome. P.S. The error i'm looking for is a timeout of a CriticalSelection when you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" cvs is an unhandeled exception when it first goes to the "Loading..." screen.

1 0

For review... CD interfaces in wine
by eric pouech 22 Dec '01

22 Dec '01

not ready yet for cvs inclusion (yet), this patch implements two things: - it replaces the wine internal & proprietary cdrom interface (used in MCICDA and MSCDEX/int2F) with the proper win32 ioctl:s calls - it allows opening any device with CreateFile (using the name "\\.\E:") (this is still very hackish, but not worse than what already existed) patch posted for review/comments/enhancements... (before I go on vacation, in case someone would work on something equivalent) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 22 Dec '01

22 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > > However, just because it doesn't combine to something normal > > > > doesn't mean that is doesn't combine. > > > > > > And how does it combine exactly? Both the book and the > critic are > > > available independently. > > > > > > You can still read the book independently from the critic so > > > they are obviously two separate pieces of work, not a single one. > > > > > > Or how do you define 'combine'? > > > > I do not define combine in any general way. It depend on > what my intent > > is and on the circumstances. I do not expect others to > nessarily define > > combine in the same way either. > > I would say that piece of work 1 combines with piece of > work 2 if it > alters piece of work 1 and results in an entity that a user would > consider to be a single piece of work of the same type. > > Now I believe this is a more restrictive and reasonable > definition of > 'combine' and should match general expectations better than your > 'everything combines with everything if I decide so' definition. What a user would consider a single piece of work depends on the user so it is very vague and unsuitable definition in a court of law. > [...] > > > So you agree that gratis, open-source and commercial > works are all > > > entitled to the same copyright protection. The last two > paragraphs of > > > your email seemed to imply differently to me. > > > > Yes, it is entitled to the _same_ copyright protection. > > Good. We agree on something! :-) > > > > However since you give away your work gratis to the end user by > > your free choice, you have the right to stop doing this(1), > > if anything I sell to the end user bothers you. > > Yes, or as the copyright owner I have another alternative: choose a > license that restricts what you can do with my work. I can even choose > to use multiple licenses and tell you to which one you must abide by > depending on how much money you give me. And no matter how much or how > little you pay me, you must abide by this license, this at least we > agree on, so that's good. > And if I say that you must not redistribute work based on mine then > you must comply. And basically saying 'take his work and then apply my > modifications' still has the same effect: the user magically > gets a copy > of your work which is clearly based on mine. So the end > result is still > that you are redistributing a work based on mine which is > precisely was > forbidden by the license agreement. No, the license is not a contract, and even if it was it can't override the original contract that you implicitly made with society to get any copy protection at all. The license can only be about the rights granted to you by society to your work and while you certainly can deny me, as normal commercial licenses do, that right do redistribute, you can only deny me the right to do derived works to the extent copyright law defines a derived work.

1 0

License debate conclusion
by Alexandre Julliard 21 Dec '01

21 Dec '01

OK folks, I think we are way past the end of the useful part of this discussion, and it's time to come to a conclusion. I'll ask people who want to continue arguing the fine points of the LGPL to please do it by private mail. My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future. Thanks to everybody who participated to the discussion, and now let's go back to writing code... -- Alexandre Julliard julliard(a)winehq.com

1 0

Latest OSS changes and Pajam Sam, again
by Ori Pessach 21 Dec '01

21 Dec '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, For what it's worth, I've been testing those troublesome games from Humongous with newer versions of Wine. Up until Nov. 9th, they worked fine. Afterwards, they started failing with a difficult to diagnose error message on startup, saying that the sound card was not detected. I tested this with OSS and ALSA sound drivers. The latest version fails after playing a sound on startup. I get two error dialogs - the first says: "The sound card driver is refusing to accept our sample", the second says "The sound card driver will not unprepare our sample header". I'm also still getting "err:wave:OSS_AddRingMessage buffer overflow !? " messages. I have the feeling that these messages should give someone who's familiar with the code a bit more to go on. waveOutUnprepareHeader() seems like a good place to start, and I'll look at it myself when I have the time for it (not soon), unless somebody else figures it out first. Bye, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE8Ip0kzA/uWWyw6uQRAgeUAJ9K2NvscRvz0ciAvvsWqVF/3M1qBACfe8QA k8KtoVC5TIP2cYhONTWbLlk= =17aJ -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > - a critic's book about the original is not a derived piece > > > of work. It > > > is clearly specific to the original book but does not > modify it and > > > clearly does not combine with it to form a single piece of work. > > > (no real equivalent to this one, closest thing would be an > > > application/script that uses another, like a script that > calls 'ls') > > > > This is not all clear IMHO. What a single piece of work is not > > well defined. Sure a combined work will not be a book since a book > > normally is something that can be read in linear order and combining > > with the critisism will not likely form a normal linear book. > > > > However, just because it doesn't combine to something normal > > doesn't mean that is doesn't combine. > > And how does it combine exactly? Both the book and the critic are > available independently. > > You can still read the book > independently from > the critic so they are obviously two separate pieces of work, not a > single one. > > Or how do you define 'combine'? I do not define combine in any general way. It depend on what my intent is and on the circumstances. I do not expect others to nessarily define combine in the same way either. However, the problem is that you (or rather the law) must define what combine means for your: "Can't legally distribute, is derived work" to have any meaning. > [...] > > > > > > From my point of view open-source is not any different from any > > > commercial work. Obviously there are legal means to obtain > > > the original > > > work in both cases (whether you have to pay for it is irrelevant). > > > Otherwise the point is moot. > > > > > > But saying that open-source is different would mean that > > > because you > > > are not making a direct profit from this work, you are > not entitled to > > > any protection under copyright law. You can't mean that, can you? > > > > But you _have_ protection from copyright, everybody that > _distribute_ your > > work must fullfill the license otherwise you can sue them. > > So you agree that gratis, open-source and commercial works are all > entitled to the same copyright protection. The last two paragraphs of > your email seemed to imply differently to me. Yes, it is entitled to the _same_ copyright protection. However since you give away your work gratis to the end user by your free choice, you have the right to stop doing this(1), if anything I sell to the end user bothers you. (1) Of course you, by your free choice, choose to give the end user the right to redistribute as well so, he can legally give it to his "friends" all other the world, but that is not my problem either. Note that I not saying that your choice was wrong, but you shouldn't complain that rights that you gave up by _free_ choice have been used against you.

2 1

Re: Visual FoxPro 5 apps
by Rick Romero 21 Dec '01

21 Dec '01

I just noticed that my Foxpro 5 post is on WWN, so I thought I'd share the thread from the wine-users list... Rick On 5 Dec 2001 at 13:34, Rick Romero wrote: > On Wed, 2001-12-05 at 13:22, gerard patel wrote: > > On 05 Dec 2001 11:55:10 -0600, Rick Romero <rick(a)valeoinc.com> wrote: > > > > <snip window problems> > > > > >Now I've tried a few different distro's, and quite a few different > > >releases of wine (been compiling from cvs for the last couple months), > > >so I don't think it's just me... BUT. > > > > Try with Wine from 01 june 2001. > > Huge changes have caused several severe regressions > > after this date and they are mostly unfixed. > > Well, I downloaded Wine-20010510, and the MDI windows work PERFECTLY. > They're highlighted blue when active > The scrollbars work > The mouse click is released. > > Although overall, it doesn't work near as well.. > > > > > If your app has the same glitches with Wine as of 01 june > > 2001, its problems are not related to the general regression. > > In this case try to do this, I'll take a look. > > In the other case, it's unnecessary as I'm already aware of > > these problems. > > If I'm not imposing too much, could you point me in the right direction? > > I don't know if I could come up with anything of 'acceptable patch > quality', but I'd like to try. > > Is the problem in mdi.c? > If it was only a simple bug, I'll have it killed since a long time. I'm mostly in the dark, but I think it's more the progressive passage to a whole new design that has caused a string of regressions. Gerard ----- Valeo, Inc. will be closed for the Holiday season starting on December 20, 2001 through January 1, 2002 resuming business on January 2, 2002. We wish you a Happy Holiday Season! -- Rick Romero IT Manager Valeo, Inc. ph 262.695.4841 fax 262.695.4850 rick(a)valeoinc.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > > > There are many thing that are important in the world not just one, > > so it was just a reaction of your persistance that the spirit of > > something is the only thing that matters. > > I focused on the spirit to put some sense in the discussion, > go get to the > point where we agree to disagree, but you don't seem to want that. > > In computers we have interfaces and implementations. It's healthy to > separate the two. Yes, but this doesn't mean that this is always possible. > In our case, the interface is the spirit of > the LGPL, > while the implementation is the LGPL itself. > > If there are 'Gapping Holes' anywhere, they are in your > arguments. You say > you agree with the interface, but you disagree violently with the > implementation. On the other hand, when I ask you for a different > implementation, you can't it can not be done. I say that it can't be done without having a copyright law that will be unacceptable in other ways. > Patrik, you > can not agree > with an unimplementable interface, for crying out loud!!! You > have to make > up your mind and choose! I would very much like to have "Peace on earth", but I don't think it every will be "Peace on earth". You can call that illogical if you wish. It is up to you.

1 0

license discussions
by Marcus Meissner 21 Dec '01

21 Dec '01

Hi, Could we please create a new mailing list wine-license, where all the people who care about licenses can discuss them? Ciao, Marcus

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Does it nessararily follow that you wish to accept any means to > > achieve this? Including, say, to be really extreme: > > "Nuke the middle east, then it will be peace there" > > and after enough nukes it probably WILL be peace, > > so it would be entire in line with peace on earth. Right? > > Patrik, if you think licensing software under the LGPL is > equivalent to > nuking the middle east out of existence, you need to take a _deep_ > breath, drink some cold water, and stay away from those pills. > > Since we're here, this is the type of attitude that really > destroys the > credibility of much of your arguments. It was purposely extreme to illustrate that you can fullfill the spirit of something good with very bad results. There are many thing that are important in the world not just one, so it was just a reaction of your persistance that the spirit of something is the only thing that matters. > I mean, exagerations > of the form: > 'LGPL gives you nothing, it's a pile of crap' despite the > enormous effort > put in it by various lawyers and law professors from reputable > universities, will not buy you many friends. Do you really > think that the > entire law establishment in the US has all gone mad and can't see the > 'Gapping Hole' in the LGPL, and you were the chosen one to see it? I'm sure they all have worked very hard, however as in the extreme example above, all means to achieve something is not nessarily good, if seen as a whole. The meant this time is the doctrine of derived work, which since it is one of the few means they got it was naturely the choice. However, a to strong doctrine of derived work, is not good from other points of views so it will be entirely possibly that the courts will not rule in their favour.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > No, its not irrelevant because it will effect the advise the company > > lawyers give their clients. > > But know you are inconsistent with yourself. You've been > claiming that it > is the very spirit of the LGPL that would scare companies > away, and I can > see some merit to that idea. No, I have been say that the _means_ to implement the spirit of LGPL might scare away companies. > You've also been claiming that > the LGPL may > not be enforceable, thus in mathematical terms, > the expected value of the LGPL < the intended meaning of the LGPL > it follow directly, that the more you are right, the less negative the > advise of the lawyers. Only if lawyers have certain mathematical properties, which they certainly do not have. Actual most functions don't have such properties either. > So, if you 100% right, the LGPL would become BSD, and the > lawyers would > give the same advise, as for the BSD. If you are 100% wrong, > then we do > get the full protection of the LGPL, and we're happy. > Anything in between > is a linear combination of the two. In any case, there really > is no point > about bitching the doctrine of derived work. QED. LGPL can only be BSD if the doctrine of derived work is very weak, so it does have something to do with that. > In fact, choosing the LGPL is a very nice way of hedging our > bets agains > future changes in copyright law. And this is so because of > the negative > feedback loop that the LGPL introduces agains the copyright > law. Brilliant. Now you are contradicting your self. You said earlier IIRC something about that you shouldn't believe that the license Wine chooses effect copyright law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Sure it is true that what people (read: companies) believe > is true is > > more important than what really is true. > > So, in fact, you indirctly agree that arguing about the doctrine of > derived work as part of this discussion is irrelevant. No, its not irrelevant because it will effect the advise the company lawyers give their clients. You seem to wish to use ignorance (or uncertainty) as weapon to protect Wine, but know this: Ignorance (or uncertainty) cuts both ways. Gav has said that Transgaming or for that matter Corel would have use Wine if it had been LGPL:ed. Perhaps this was because of ignorance, perhaps not. Anyway even if you would be able to convince Gav that he was/is wrong, you must realize that Gav IIRC have researched legallity issues extensively so it is entirely likely that somebody else spending similar resources would come to the same, in your opinion wrong, conclusion. In short: Ignorance (or uncertainty) is a dangerous weapon. > All you seem to be saying is that you think that the _spirit_ > of the LGPL > would be detrimental to Wine since it will drive companies away. > > Right? No. I have been trying to explain just because to are for the spirit of something it is not nessarily so that you support all possible means to acheive something and sometimes any acceptable means to acheive something might not exists. Do you support the spirit of: "Peace on earth!" Does it nessararily follow that you wish to accept any means to achieve this? Including, say, to be really extreme: "Nuke the middle east, then it will be peace there" and after enough nukes it probably WILL be peace, so it would be entire in line with peace on earth. Right?

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > But why should I do that? > > I can for example write a script that download Wine for the > end user user > > and apply the patch automatically. > > The patch would be considered a derivative work, so distributing it > would also violate the LGPL. That again is dependent of the doctrine of derived work have any meaning since the patch is written by me and only contains my work. Just because you build upon somebody else work doesn't mean it is a derivation. Anyway since it denies my right to speech it must be constitional within the context of the first amendment which is IMHO very unlikely that a strong doctrine of derived work is. The copyright clause exception only reserves only gives congress the right to give exclusive rights to _their_ work not to the work of others (read: me). Note by patch I do not nessarily mean a patch like (diff -u) that contains the (LGPL:ed) context of the patch. An "ed-script" or whatever similar will do. Anyway the LGPL:ed context of a (diff -u) patch might very well be consider fair use so that might not be relevant.

4 4

Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 21 Dec '01

21 Dec '01

On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP] > Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) > and > was going to submit a full patch for it at the end of the week. My > patch, > however, has almost a completely different approach to the problem! > Attached is my version (not quite complete or clean). > > These are the main differences and issues I see between our patches: > > 1) I can successfully acquire/release a context (tested with MSDN sample > code). I have not experienced any problems with <loading> a CSP. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants. > 2) Currently the ms CSPs can perform but all launch pstores.exe - the > protected stores service. This is fine except that it eventually crashes > > with an unhandled exception c0000005 and then becomes unwilling to start > again. Pardon my ignorance, but I didn't realize that that was what pstores did. > 3) Dependancy functions of pstores and M$ providers not implemented: > (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, > mpr:WNetGetCachedPassword, etc.) Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list. > 4) I do not create any list of providers. This should not be required as > the > registry is supposed to contain the list of available providers. Once a > handle is acquired then we can gain access to the provider by this > handle. > Note: Key and hash objects need to link to the provider handle, when they > are > created. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet. And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory. > 5) I have not yet considered thread or process safing/locking. Nor have I > > done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning. > 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not > used by > the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet. > 7) I currently do not allow a CSP to drop any of the stardard functions. > > This only affects a few functions, however, as MSDN states these > functions > are *required* for the CSP to have. If they are not implemented they > must > set the last error as ERROR_CALL_NOT_IMPLEMENTED. Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext. > 8) You seem to make not use > ?????????? > Anyway I think the correct thing to do right now is to co-ordinate our > work > to make a single patch and implementation. > YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel. > I am currently testing this code against windows 98. > Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave

1 0

Re: timed-out non-overlapped ReadFile
by Mike McCormack 21 Dec '01

21 Dec '01

Hey Lawson, Cool. i just wanted to get apps like yours back to their working state. Ideally i need to add a bit more code for the case (ReadIntervalTimeout = -1) that waits until at least some data is received before returning.... more trouble :-) The timeouts for non overlapped ReadFile should help alot of the recent problems reported on wine-users... hopefully. Mike Original message from: lawson_whitney(a)juno.com .. >Sorry if that sounded like faint praise. The app works as well with >both patches as it did before with neither, and probably there is some >other app that needs non-overlapped ReadFile to time out. > >Thanks! > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 21 Dec '01

21 Dec '01

On Fri, 21 Dec 2001, Mike McCormack wrote: > > This patch handles the special case where > ReadIntervalTimeout=MAXDWORD, ReadTotalTimeoutConstant=0 and > ReadTotalTimeoutMultiplier=0 a little better. We should just wait > until we get some data, then read it and return in that case. > > Mike > > ChangeLog: > * handle ReadIntervalTimeout=MAXDWORD special case a bit better > Sorry if that sounded like faint praise. The app works as well with both patches as it did before with neither, and probably there is some other app that needs non-overlapped ReadFile to time out. Thanks! Lawson Slowly but with considerable uncertainty.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> > You forgot that the end user still need to legally get hold of > > the work somehow. For normal commercial stuff this involves > > paying for it and the author will get payed just like he did in > > the old non-digital world for _each_ copy. > > I did not forget that. Good because this is _very_ important. > But I still do not think a book author would > allow you to publish a patch that would modify the last chapter to > provide a different ending. Why, if people like the alternative ending and recomend it to other he might get increase sales because presumeable they want to read the begining. Anyway, we a talking about what is legal and what is not, so that doesn't matter. > The point is that whatever way you use to distribute your > modifications, they are specific to the original work, alter it and > combines with it to provide a single new work. And these are the > criteria I would use to define a 'derived piece of work'. > > And since > derived pieces of work reuse the original work it seems only fair that > they can only do so if they respect the license of the original work. I might sound good from a open source perspective but it nearly isn't as attrative applied to normal commercial works. > Let's take a couple of common sense examples and assume that the > original work is a book. > - a bottle of black ink is not a derived piece of work. Obviously you > can alter the book quite a bit by dropping its content on it > and the ink > will definitely merge with the book. But just as obviously the ink is > not specific to your book. > (computer science equivalent: a file compression utility) First of all since we have a physical object we defintively in addition have the doctrine of first sale so inkstaining your book and reselling it is specifically allowed by law. By selling it the author lost control over that copy. > - a critic's book about the original is not a derived piece > of work. It > is clearly specific to the original book but does not modify it and > clearly does not combine with it to form a single piece of work. > (no real equivalent to this one, closest thing would be an > application/script that uses another, like a script that calls 'ls') This is not all clear IMHO. What a single piece of work is not well defined. Sure a combined work will not be a book since a book normally is something that can be read in linear order and combining with the critisism will not likely form a normal linear book. However, just because it doesn't combine to something normal doesn't mean that is doesn't combine. > - as long as you have the right to sell the original book, you should > have the right to sell it bundled with other books. The reason is that > this does not alter the original book and that it does not form a > combined piece of work. > (linux distributions) Again, you seem to miss that just because thing does not combine in normal ways it doesn't mean that they don't combine. > - but leaflet that replaces the last chapter of the book to provide a > different ending is a derived piece of work. The reason is that it is > specific to the original book, alters the story (the original work of > which the physical book is nothing but a printed > representation) told by > the book, and combines with it to form a new work (a new story with a > different ending). Thus you can only distribute it with permission of > the original author, even if you do not distribute the original book > with your leaflet. > (that's your patch example) Here it combines in a linear readable way. In short: Everything combines with everything else is some way, so unless you define some exact criteria on where the legal border talking about what can combine is rather pointless. The only trend, in your examples, I can see is that you wish to give work that combine in linear readble way more protection, for some, not mentioned, reason. Can you please explain why? > > No particular problem, > > except that some companies might be greedy and want more, > > but hey, do you really wish to give them more? > > I did not express any wishes and in any case they are irrelevant: I > do not have the power to give companies more or less. Now, when I'm > world-dictator for life... :-) :-) > > Open source is more problematic since the end user legally can > > get hold of the work for free and thus any distribution > > restrictions is meaningless since the end user doesn't distribute. > > From my point of view open-source is not any different from any > commercial work. Obviously there are legal means to obtain > the original > work in both cases (whether you have to pay for it is irrelevant). > Otherwise the point is moot. > > But saying that open-source is different would mean that > because you > are not making a direct profit from this work, you are not entitled to > any protection under copyright law. You can't mean that, can you? But you _have_ protection from copyright, everybody that _distribute_ your work must fullfill the license otherwise you can sue them.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> I see exactly what you mean. You mean a binary patch that says > things like: > * delete bytes 2294 to 2297 > * replace bytes 38455 to 39345 with "...." > * insert "...." at offset 41753 Yes. > Such a patch is very specific to a given source version > but does not > include any of the original source. Yes, but that is not a very problematic restriction. > Well, if you can legally use such a patch to work-around the LGPL > license, then you can use it to get past *any* license: GPL, AFPL, MS > shared-source, .... whatever. And this is not only true of > source files, > this is also true of binary files: you can apply such a patch to > executables, libraries, mp3s, mpegs, ... It means what you mean by get past, but OK for the sake of argument: Yes. > This has already been done and the author very quickly got into hot > water. IIRC it was less that two years ago, about a GPL game and an > individual who published a mod as a patch to the game binaries but > refused to publish his source. I'm not sure how it ended. You can > probably research it in your copious amounts of spare time, I think > there was an article on it on Slashdot at the time. I rememember. Of course it was impopular, I do not question that. The question is: Was it it illegal? > But I can assure you that no company in a 'developped' > country would > try such a thing. In the form above perhaps not so likely, but doing a proprietory Crypto API implementation with a patch to make Wine use it, much more likely. > If such a stunt were recognized as legal > then it would > spell the end of copyright of all electronic forms of songs, movies, > books, ... You can be sure that the RIAA, MPAA and all the other > entertainment companies in the world out would never allow such a > thing... and for once I say that they would be right. Please calm down. You forgot that the end user still need to legally get hold of the work somehow. For normal commercial stuff this involves paying for it and the author will get payed just like he did in the old non-digital world for _each_ copy. No particular problem, except that some companies might be greedy and want more, but hey, do you really wish to give them more? Open source is more problematic since the end user legally can get hold of the work for free and thus any distribution restrictions is meaningless since the end user doesn't distribute. But hey, do you really think this so important that you wish to give companies more power than they already have?

2 1

CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 20 Dec '01

20 Dec '01

A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again. The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave

3 4

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So almost all functions would look like > > void CryptFoo() > > { > > #if HAVE_LIBCRYPTO32 > > CRYPT32_CryptFoo(); > > #else > > /* Old Wine code */ > > #endif > > } > > > > with a few minor exception. > > > > So you mean that I can't legally do that despite the fact that > > the LGPL is meant to allow linking to proprietary licenses. > > The LGPL allows using LGPLed code from proprietary applications. It > does not allow making the LGPLed code dependent on proprietary code > for its own functionality. > > > I think you have misunderstood something seriously. > > Please, this is the absolute worst argument from you > > as of yet. You can't seriously believe this. > > > > Also note that the code that I wrote above was supplied > under the LGPL, > > so I don't see how you can claim that I violated the LGPL. > > Of course you cannot violate the license of your own code, don't be > silly. Exactly. > But if you put this code in an LGPL library written by someone > else and distribute the end result, you have to make a good faith Yes and DISTRIBUTE the end result is the key. But why should I do that? I can for example write a script that download Wine for the end user user and apply the patch automatically. > effort to ensure that the library works properly even in the absence > of your proprietary library. This means you need to implement the > #else case and release that under the LGPL. Go read the square root > example in section 2 of the LGPL. Perhaps, but I need not distribute so it doesn't matter. The point that I have been tried to make all along that only the doctrine of can make my trickery illegal. Without it, it doesn't matter that I use Wine in a, hmm, let call it a non standard way. Anyway I think this discussion, at least the one between you and me, are running around in circles and doesn't move forward at all, so lets just end it. > > Could it be that they rely on that that the dotrine of derived work > > will save them from people trying to use the lopeholes in > the licenses? > > Sure, maybe you understand the law better than all the lawyers who > looked into this issue. I'm not betting on it. It is not primarily understanding that is the issue here. I have said that I believe, and have tried to explain why, that a strong doctrine of derived work is not good for society, because it leads to all sort of absurd consequences. Therefore is believe (or rather hope) that the courts will se sanity and only constitionally allow a very weak doctrine of derived work and thus render viral licenses such as LGPL of most (all?) of its power since it will be quite easy avoid the requirements with a little trickery. Note that this will almost exclusivly effect viral open source license since normal commersial work will get their $100 or whatever regardless since there is no trickery that can legally avoid it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> But, I hear you say, 'why change the license if it doesn't > give you any > protection?' Well, this is where your reasoning is flawed, because the > LGPL gives you quite a bit of protection. And this is because > there is at > least a 50% chance that it is enforceable, and this is > _good_enough_ in > practice. This is trivial to see: the market place is littered with > unenforceable EULAs, yet they seem to do the job. Why? Because big > companies will have not desire whatsoever to test these > licenses in court, > since they have to much too loose (remember, big companies = > have $$$), > while small companies can build on a business plan based on such shaky > grounds, as no one is going to fund such ventures. Add to > this the immense > public pressure, and you have Protection, with a capital P. Sure it is true that what people (read: companies) believe is true is more important than what really is true. The problem is that the example of things you could do that I consider trickery might be considered perfectly normal for some companies, in fact something are not really something strange at all if you applied to the normal world. I adjust the thing I bought a little and then resell it. Then their lawyers tell them that it is unclear if they can do it. Many might not not bother at all and thoose are lost to Wine, some might risk it a later find themselves it a situation that they can neither move forward nor backwards because of "public presure", and because of the amount of money invested they have little choice but to say the LGPL is absurd, we don't not believe we ingfringe on somebodies rights and move forward hoping that somebody doesn't sue them. > And just for shits and giggles, if you think _any_ license > will give you > absolute protection, you are sadly mistaken. And the reason > this can not > happen is rather simple: the laws change. I have said it before and I say it again: I have no illusions that something gives absolute protection.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > Okay, that makes a bit more sense. Although couldn't one argue that > > it still does work since it could fall back to the original LGPL > > createwindow? > > Sure, if this is the case it's OK. You can perfectly provide a > user32_better library that implements a new CreateWindow, and links to > user32 for the rest. But the modified user32 you ship must work > properly, it cannot be dependent on your proprietary user32_better for So as an alternative trickery: I distrubute everything just like the example above it just happends that user32 is a symbolic link to user32_orginal. This would be alright wouldn't it? So now I just can distribute a script that move the symbolic link user32 from user32_original to user32_better. Problem solved in a way even more convienient for my end user.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So what you basicly saying is that a Crypto API that is a > part of ADVAPI32 > > can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. > > > > Isn't that quite an absurd state to make? Or rather the > perfect illustration > > of the absurdities of LGPL. > > No, I think it makes perfect sense. If your code is sufficiently > independent that it can be put in a separate library, then the LGPL > gives you the right to release it under another license. But in order > to do that, you have to demonstrate that the code is really as > independent as you claim it to be; and requiring you to put it in a > separate library is the best way to ensure that. Somehow I guess you would say that. OK, so now are down to independence. So independence is an issue of whether something is on either side of an artifical barrier in this cases the DLL boundary? Note that you your condition: "If your code is sufficiently independent that it can be put in a separate library" can always be fullfilled with a little trickery. For example: void CryptFoo() { CRYPT32_CryptFoo(); } and release the code above under the LGPL. Note that we now return to the doctrine of derived work for nothing except for it can ever make this illegal. > You known, no matter how much you may disagree with the FSF or their > license, they are not a bunch of idiots. They have been through this > long before you, and have spent a lot of time (and lawyers) to make > sure that it worked as they wanted. You can certainly find minor > issues and border cases, but the LGPL is not the useless crap you seem > to think it is. They had a goal and I'm sure a lot of competent people did the best they could be accieve it. However, you can do the impossible no matter how hard you try.

4 3

TrueColor <16bpp modes
by François Gouget 20 Dec '01

20 Dec '01

There is a problem with <16bpp TrueColor modes: some windows applications will just check BITSPERPIXEL and if it's < 16 they will assume that we are running with a 2/16/256 color palette. What are the affected modes: * 15bpp: rgb555 and bgr555 * 8bpp: VNC's bgr233 mode! This patch is an ugly hack but it seems to work relatively well. The trick is to lie to the application about the screen depth. If we have a TrueColor mode but a <16bpp screen depth then we return 16bpp anyway. But then the application is going to create 16bpp bitmaps, and CreateBitmap will try to create a 16bpp pixmap... and this is likely to fail. So in CreateBitmap we reestablish the truth and put the right depth in bitmap.bmBitsPixel. Actually some X servers, especially the 4 series seem to support many pixmap bit depth so this may not always be necessary. Anyway, we then rely on the code in dib.c to do the conversions from one format to the other. The last bit in bitblt.c may not be necessary. It seemed useful once but I'm not convinced anymore. Well, if anyone's interested in hacking more on this, have fun (and let me know if you find interesting stuff or have questions :-). -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.34 diff -u -r1.34 bitmap.c --- graphics/x11drv/bitmap.c 2001/09/07 15:28:10 1.34 +++ graphics/x11drv/bitmap.c 2001/12/20 00:31:19 @@ -156,6 +156,14 @@ GDI_ReleaseObj( hbitmap ); return 0; } + /* In case we lied to the application wrt. the screen depth, then it's + * time to patch things up before X complains it does not support this + * color depth. Of course it means we'll have to convert depths from + * DIB to Bmp. + */ + if (bmp->bitmap.bmBitsPixel==16 && screen_depth<16 && (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL)) + bmp->bitmap.bmBitsPixel=screen_depth; + if ((bmp->bitmap.bmBitsPixel != 1) && (bmp->bitmap.bmBitsPixel != screen_depth)) { ERR("Trying to make bitmap with planes=%d, bpp=%d\n", Index: graphics/x11drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/init.c,v retrieving revision 1.41 diff -u -r1.41 init.c --- graphics/x11drv/init.c 2001/07/29 20:25:15 1.41 +++ graphics/x11drv/init.c 2001/12/20 00:31:22 @@ -190,7 +190,11 @@ case VERTRES: return screen_height; case BITSPIXEL: - return screen_depth; + /* Some applications assume that if the bpp<16 then we are using a + * palette. This is wrong, we could be in 15bpp, or even bgr233 in VNC. + * So we just lie to them. + */ + return (screen_depth<16 && X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? 16 : screen_depth; case PLANES: return 1; case NUMBRUSHES: @@ -202,10 +206,11 @@ case NUMFONTS: return 0; case NUMCOLORS: - /* MSDN: Number of entries in the device's color table, if the device has - * a color depth of no more than 8 bits per pixel.For devices with greater - * color depths, -1 is returned. */ - return (screen_depth > 8) ? -1 : (1 << screen_depth); + /* MSDN: Number of entries in the device's color table, if the + * device has a color depth of no more than 8 bits per pixel. For + * devices with greater color depths, -1 is returned. + */ + return (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? -1 : (1 << screen_depth); case PDEVICESIZE: return sizeof(X11DRV_PDEVICE); case CURVECAPS: Index: graphics/x11drv/bitblt.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitblt.c,v retrieving revision 1.37 diff -u -r1.37 bitblt.c --- graphics/x11drv/bitblt.c 2001/10/03 18:45:41 1.37 +++ graphics/x11drv/bitblt.c 2001/12/20 00:31:19 @@ -626,7 +626,7 @@ pdata += swap ? start+width-1 : start; if (image->depth == depthDst) /* color -> color */ { - if (X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) + if (!(X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) && X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) if (swap) for (i = 0; i < width; i++) *pdata-- = X11DRV_PALETTE_XPixelToPalette[XGetPixel( image, i, row )]; else for (i = 0; i < width; i++)

1 0

timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 20 Dec '01

20 Dec '01

Mike, None of your recent comms pathces has made the slightest difference to my app, but this little one breaks it. It dials, the modem connects, but the app never sees RLSD AKA CD AKA TIOCM_CAR. I reversed overlapped_good.diff II, because AFAIK that is not in the CVS yet, but it didn't matter. I don't think I have any other stray comms patches, but ICBW. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Add color cursor support
by Alexandre Julliard 20 Dec '01

20 Dec '01

Duane Clark <dclark(a)leewardfpga.com> writes: > The main ugly hack that is performed here is in determining whether a > pixel is a foreground or background pixel. This is done by adding the > red, green and blue values for each pixel, and testing whether they > exceed an arbitrary threshold. This should probably be a reasonably > safe method, since presumably any cursor will have a high level of > contrast between foreground and background colors. It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: overlapped ReadFile should ignore EAGAIN
by Mike McCormack 20 Dec '01

20 Dec '01

Hi Alexandre, Apologies, i thought explicitly about the error handling issue, and should have made a note about why i did it that way. Since the async handler code will handle problematic fds correctly, rather than duplicating all the checks, i thought it would be easier to fall thru to the existing checks in check_async_list and FILE_ReadAsyncService. Do you think it would be better to pick up any problems early? Did you look at my async queues patch? Are you waiting for Martin to respond? The async handling code is a bit of a hacked up mess the moment... i haven't applied the fixes to WriteFile that i've applied to ReadFile, and overlapped WaitCommEvent needs to return immediately if events are already available. I don't want to fix those problems twice, so i'm waiting for the big async patch... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> writes: > >> This is a fix for the problem below. Since all COM port fds are >> non-blocking, if we get an error (EAGAIN) return from the initial >> read, we should just ignore it and let the wineserver poll on it. > >Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore >all errors. > >-- >Alexandre Julliard >julliard(a)winehq.com ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: overlapped ReadFile should ignore EAGAIN
by Alexandre Julliard 20 Dec '01

20 Dec '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a fix for the problem below. Since all COM port fds are > non-blocking, if we get an error (EAGAIN) return from the initial > read, we should just ignore it and let the wineserver poll on it. Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore all errors. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > On the contrary, there will be a lot more reasons. The main market is > not in developing Wine; frankly there isn't that much money to be made > on that. The main market is in using Wine to make money on > applications, and the more complete Wine gets the easier this will be. If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity. If they are open source they have an incentitive to work making Wine complete. I don't really see the problem. > But if Wine never gets complete because some parts are held > proprietary by other companies, it won't be possible to enter that > market. So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it. In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented. You can't seriously believe this?

10 19

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > For example: > > void CryptFoo() > > { > > CRYPT32_CryptFoo(); > > } > > > > and release the code above under the LGPL. > > That's the square root example. If you do that, you have to make sure > that the use of CRYPT32_CryptFoo is optional and that the function > still behaves properly if your CRYPT32 function is not available. Forget for a moment I was trying to circumvent the LGPL. Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API. So almost all functions would look like void CryptFoo() { #if HAVE_LIBCRYPTO32 CRYPT32_CryptFoo(); #else /* Old Wine code */ #endif } with a few minor exception. So you mean that I can't legally do that despite the fact that the LGPL is meant to allow linking to proprietary licenses. I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this. Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL. The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL. > > They had a goal and I'm sure a lot of competent people did the best > > they could be accieve it. > > > > However, you can do the impossible no matter how hard you try. > > Strangely there are thousands of people, including lawyers, who seem > to think that the LGPL does what it claims to do. If the problems are > so obvious, how come no one else sees them? Could it be that maybe, > just maybe, it is because all these people are right and you are > wrong? Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Now, here's another something to mull over. We've pretty > much established > that you could statically link something proprietary with > something LGPL. > One question I have is how much of the library are you > allowed to use. > Alexandre mentioned that while the CryptoAPI example would be > a pretty > clean-cut allowed case, a proprietary CreateWindow would not > be allowed. > His argument was that because it would necessarily use > internal functions > and data structures that it would be a derived work and thus > subject to > the license. > > I think what Patrick has been trying to get at is that that > is not very > clean-cut and that in fact there is little to no precedent on > what exactly > a derived work is. If Alexandre is indeed correct then we > are pretty well > protected. If it is at the opposite extreme and anyone could > statically > link in proprietary versions of functions then we have very little > protection and it really makes it not worth it to go LGPL. At > least that > is what I think Patrick has been trying to say. Yes, approximately. > Let me put it to you the way I see it. Whether a function or data > structure is exported or not does not matter. It would be trivial to > declare an internal structure or function as exported and thus the > proprietary function is simply making use of the library and > therefore not > a derived work. Indeed... > That is my argument that avoids all of > Patrick's doctrine > of derived work crap and gets right down to the fact that > it's trivially > easy to make your work fall under the work that uses the > library category, > so long as it is a seperate object file. That is, to put it > in Slashdot > terms, a "Big Gaping Hole(tm)" ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. > Look at section 5 in the LGPL. If you use (from the header > files) only > numerical parameters, data structure layouts and accessors, and small > macro and inline functions then regardless of whether it would be > considered a derived work it remains a work that uses the library. > > So that's great, after I had pretty much convinced myself > that the LGPL > was still good despite some minor problems, I now find myself > realizing > that the LGPL has major holes written into it! Welcome to the club. :-) > And so I emphasize my original statement now. The only thing > the LGPL > really prevents is the direct use of the source code. Anyone > wanting to > release a proprietary implementation of any function can do so fairly > easily simply by 1) writing that particular function from > scratch, and 2) > keeping it in a seperate object file. Agreed. > > > Try reading section 2C of the LGPL and tell me how it's good for > > commercial > > > companies. > > > To respond to Roger: I fail to see how 2c makes any > difference. It only > applies to derived works and only means that you have to release the > code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine.

2 1

[SHrinker] gdb still doing funny things
by Robert Baruch 19 Dec '01

19 Dec '01

I got around the problem of gdb unprotecting the write protected page by not setting the breakpoint until after the write fault occurs. When I stepped through the Shrinker exception handler, I got to the point where it calls ReadProcessMemory with a handle of -1 to get the 8 bytes around the EXC_CallHandler's call. ReadProcessMemory fails with an ACCESS_DENIED, and trips a landmine. 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: read_process_memory() = ACCESS_DENIED { data={} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000000 ret=0075f1c3 However, when I run wine alone, without gdb, that particular landmine is not tripped: 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: *attached* 0806d9e8: *signal* signal=19 0806d9e8: read_process_memory() = 0 { data={ff,75,08,ff,d1,64,8b,25} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000001 ret=0075f1c3 BTW, the data returned by ReadProcessMemory is correct, and also will not trip the "Have I been called from Microsoft's NTDLL.DLL method" landmine. I'll have to think about this for a while, how to use gdb without getting ACCESS_DENIED for ReadProcessMemory. That usually means going off and doing something else until an idea hits me. --Rob

2 2

[Shrinker] Modified EXC_CallHandler
by Robert Baruch 19 Dec '01

19 Dec '01

Well, the assembly-coded EXC_CallHandler works (to my surprise), with a little modification from what I described because after all, no plan survives contact with the enemy. However, we're still getting hit by one of the landmines in Shrinker. The awful thing is that I can't debug this easily with gdb. The first exception that's supposed to take place is a write fault to the code area. But if I set a breakpoint in the process's code area, gdb is going to remove the write protection from the code area because, I guess, it needs to put a breakpoint in there (I thought it would use breakpoint registers instead of int $3?) Anyway, I don't want to release the EXC_CallHandler code until I find out which landmine we're hitting, since I can't be certain the rest of EXC_CallHandler works -- the stuff past calling the exception handler. But if you're interested in a morbid "I-love-assembler" way, here it is: static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_FRAME *frame, CONTEXT *context, EXCEPTION_FRAME **dispatcher, PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) { DWORD tmp = 0; __asm__ __volatile__( "push %1\n\t" // ebp-1c = nested_handler "push %2\n\t" // ebp-18 = handler "push %3\n\t" // ebp-14 = dispatcher "push %4\n\t" // ebp-10 = context "push %5\n\t" // ebp-c = frame "push %6\n\t" // ebp-8 = record "push %%ebp\n\t" // ebp-4 "push %%ecx\n\t" // ebp-0 "movl %%esp,%%ebp\n\t" "movl 0x18(%%ebp),%%ecx\n\t" "pushl 0x1c(%%ebp)\n\t" "pushl %%fs:0\n\t" "movl %%esp,%%fs:0\n\t" "pushl 0x14(%%ebp)\n\t" "pushl 0x10(%%ebp)\n\t" "pushl 0x0c(%%ebp)\n\t" "pushl 0x08(%%ebp)\n\t" "call *%%ecx\n\t" "movl %%fs:0,%%esp\n\t" "popl %%fs:0\n\t" "movl %%ebp,%%esp\n\t" "popl %%ecx\n\t" "popl %%ebp\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "movl %%eax,%0\n\t" : "=&g" (tmp) : "g" (nested_handler), "g" (handler), "g" (dispatcher), "g" (context), "g" (frame), "g" (record) : "memory" ); return tmp; } --Rob

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > Now, here's another something to mull over. We've pretty much > > established that you could statically link something > proprietary with > > something LGPL. One question I have is how much of the library are > > you allowed to use. Alexandre mentioned that while the CryptoAPI > > example would be a pretty clean-cut allowed case, a proprietary > > CreateWindow would not be allowed. His argument was that because it > > would necessarily use internal functions and data structures that it > > would be a derived work and thus subject to the license. > > Actually the fact that they are internal or not doesn't make a > difference, I wasn't clear on that point. Agreed. It doesn't matter. > If your code is linked to > the library it is considered a derivative work, and by default the > whole has to be released under the LGPL. Now there are cases where you > don't need to do that: one is if your app is considered a work that > uses the library (section 6), the other is if you are placing your > code side-by-side with the library (section 7). > > So if you don't want your code to fall under the LGPL, you have two > choices: one is to put it in some part of your app that only links to > the library, but in that case you cannot have other parts of the > library depend on your code (this is the square root example). This > would work for the crypto API, probably not for CreateWindow since the > rest of user32 needs CreateWindow. Well, only if it made CreateWindow work different that it was supposed to. Note that supposed to it pretty vague, however, if you leave it out you can't even apply bug fixes since it would change the behavior. > The other solution is to put your code side-by-side in the library; > but this is only possible if your code is not covered by the license, > which means it isn't a derivative work of the library, which in turns > means it cannot use any functions or data (exported or not) of the > library. This would work for the crypto API as long as you don't use > anything from the rest of libadvapi32. So what you basicly saying is that a Crypto API that is a part of ADVAPI32 can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. Isn't that quite an absurd state to make? Or rather the perfect illustration of the absurdities of LGPL. Of course, I assume that you by use a function mean call a function not cut and paste from a function.

3 2

RE: Installshield 6 (inter-proc) patches. LGPL hole.
by Patrik Stridvall 19 Dec '01

19 Dec '01

[David Elliott explaination snipped] > Thanks for explaining what Patrik has been going on about. Yes, it was quite a good explaination. However... > In summary: > > Consider a proprietary application which ships as a > proprietary library > which is statically linked with LGPL libraries at install > time in a way > that lets users supply new versions of the LGPL libraries. > This lets them > fix bugs in the LGPL'd code and thus in the proprietary app. > The harm you see is that a vendor could, once he found a > Winelib function > with a bug, simply do his own clean-room implementation of > that function, > and use it instead of the Winelib version of it, and keep the > improvement > to himself -- which would also deprive the user of the ability to fix > bugs in the proprietary reimplementation of that particular > WineLib function. ... while this is an entirely possible scenario there is little profit in doing what you suggest so while it is one of the holes in LGPL it is not really a problem in pratice I think. No, the problem as far as Wine is concerned, is that somebody might do proprietary extension of some important part of Winelib that enough people want so much that most people uses the proprietary extension and under such circumstances there won't be any incentive for people to work on Wine. However, I neither believe this to be true, nor do I believe that the LGPL will help to stop it other than very marginally.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> >> MS Word (to use an example) might have to dynamically link in > >> a special MS Word component to process specifics in my > >> document, it doesn't mean my document is "linked" with the > >> MS Word component does it? > > > > Ah, you are beginning to see the problem. :-) > > What problem? A GPL program is the same as any other - GPL > protects the > code, not the use of said code. Indeed. It is a not a use license. However because of the doctrine of derived work that GPL depends upon, some use (read: linking) are considered derivation and thus a possible violation of the GPL. > There's nothing to stop a > GPLed program > such as, say an amiga emulator (UAE) running the emulated non-free > software. As geoffs example rightly points out. You think (read: hope) that it is not so because it would be quite absurd wouldn't it? However if the doctrine of derived work is strong enough to prevent want the GPL hopes it will prevent namely linking, I see no reason to assume that emulation would be considered differently. After all from a technical point of view essentially that same things that happends. > And in any case, we are talking about the LGPL - a totally different > matter. Not entirely whatever power the LGPL have also derives from the doctrine of derived works eventhough is doesn't try to use it to the extent that the GPL does. > Which is my response to Rogers comment above - sure the GPL > prohibits linking with a nonfree component. Yes, but what is linking? Don't you understand it is the vagueness of linking that is the problem. This is further made worse by that fact that the doctrine of derived might possible, and are very like to do, at least to some extent, place some kind of limit on what linking legal extends to. > That 'closes' the > source and > provides far too many ways to cheat the license. > > The LGPL allows dynamic linking with a nonfree component. > Remebering that > the LGPL is meant to apply to LIBRARIES (hence allowing a > libssh library > to use nonfree crypto routines for example) not for an application. You can cheat with both the GPL and the LGPL at I have tried to illustrate in earlier mails, but the LGPL at least as applied to Wine is a gaping hole, that hardly provides any protection at all.

3 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > The problem is the doctrine of derived works. Nothing else. > > And to you truly believe that our choice for Wine's license > will have any > influence over the doctrine of derived works? Of course not. But it _will_ effect our abillity to attract companies. Eventually I think the courts, possibly with the help of the politicians will realize that only a very weak doctrine of derived work could every service society without introduces needless uncertainties and/or absurdities. For example I think that some cases where the doctrine of derived work has been used like IIRC in some case considering unauthorised Star Trek books. Using the Star Trek characters in a book without Paramounts(?) permission, would be much better served using trademark law instead. This might or might not require changing trademark law but that is a different issue. Don't expect it to happend soon though. > If not, there > really is no > point in discussing this any further. If yes, than even more > so should we > chose the LGPL, as it will help settle the debate the right way. See reply in previous mail.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > I'm against the fact that the GPL or to a smaller extent LGPL > > tries use the doctrine of derived work as a weapon to achieve > > their goals. It is a very dangerous weapon, since if the courts > > or the policitians decide that a strong doctrine of derived work > > is good it might be disasterous for society as a whole. > > This is a very good point which in fact _promotes_ the LGPL. Not really. See below. > Let me > explain. > > There are two possibilities for copyright law: > > 1. The copyright law becomes stronger. > 2. The copyright law becomes weaker. It is much more complicated than that, but fair enough, lets assume this for the sake of argument. > I will assume, for the purpose of this discussion, that: > > A. Wine contributors wish for 2. I, for one, am very worried about the > direction of law these days (see: software patents, DCMA, > SSSCA, etc.) and > I fully agree with Gerard that it's an unfortunate situation > B. There doesn't seem to be any negative feedback loop that > will prevent 2 > from happening. That is, it is very probable that 2 _will_ > happen sooner > rather than later. I agree. > Now, let's just go through the possibilities: > > Let's look at copyright law. If our dreams come true and 2. > will become > reality, then Wine will be in no worse situation than it is > now in. The > LGPL will effectively become BSD, i./ii. become irrelevant, > and we're all > happy. This scenario is possible, but (unfortunately) not probable. Yes, but in the mean time it is likely that we scare away potential good companies and regardless of the LGPL be effected negativly by bad companies using the lopeholes in the LGPL. > On the other hand, if society moves towards 1., then the LGPL is the > perfect tool because it turns the stronger copyright law > against itself. > In this case, it is the only moral/ethical thing to do: to > turn an evil > instrument against itself, thus provides the > _negative_feedback_loop_ that > is missing at the moment. > > Moreover, if you are worried about the fact that open source > software is > so influential that it can influence the debate over the doctrine of > derived work, then even more so should we opt for the LGPL > because in that > case we would contribute to a negative feedback that will deter > politicians from making the copyright law arbitrarily stronger. So you want Wine to be the catastrofic failure, that was used to change copyright law. You can't seriously want this.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > > Note that I said "_small_ improvements" because of the > > > modular nature of Wine. If the improvements are big, the DLL > > > separation would allow them to keep those changes proprietary. > > > > I don't think small improvements is a problem anyway and > > beginning an implementation of say DCOM is probaly not a > > small improvement and DirectX certainly isn't. > > But if it's not, it's within a small constant factor to > replace the rest > with prorietary code and not release anything. See, if the > DLL is mostly > implemented, the changes are not that big, so they should be > contributed > back. If the DLL is mostly stubs, just rewrite the entire > thing, you're > not wasting that much effort in the first place, and you can choose > whatever licence you want. DirectX and DCOM fall in this cathegory. I have use the Crypto API as an example several times that to illustrate that the DLL:s isn't a relevant protection boundary for the LGPL, even Alexandre seems to accept this. In any case if the DLL is mostly implemented there is very little reason for a company to try to enter the market, it is simply to dangerous, so I don't see the problem. > > > I fail to see _any_ moral/ethical/philosophical problem with > > > this. Do you? > > > > Perhaps you have been more enlightend now. > > Focusing on obscure issues only is anything but enlightening. :) Well, the concrete issues like do we scare potential companies that wants to help way quite hard to argue about in a objective way and I do not really like subjective arguments. I leave them to for example Gavriels that IMHO has done a good good job at that. I have been trying to approach the problem from the other side, that the LGPL doesn't provide much protection at all.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > You forget that some "independent"(*) parts like the Crypto API are > > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. > > This is ridiculous: it is one of the few exceptions, it is > simply silly to > bring the Crypto API into this discussion. If this the Crypto > API is the > only problem, we can fix it in multiple ways. It is not the only problem it is just a symptom of the gaping hole in LGPL. > > > At this point, I would like to know if people agree up to > > > this point. > > > > I don't. > > That's informative. WHAT don't you agree with? In fact, if we > can agree on > WHAT we disagree, I think it would be a great step forward. "I don't" primarily refered to the previous argument concerning "independent"(*) parts. > > > 0. Isn't Wine's best interest to evolve and develop as fast > > > as it can? > > > > Yes. > > This is a fundamental point. A project like Wine is just like > a living, > breathing creature. And being need to be selfish to survive. Not too > selfish, but it is essential that they have a certain level of > selfishness. Your analogy is flawed, Wine is not living in the meaning that it, if it is to unselfish can die. The mechinisms are entirely different compared to normal life. > In Wine's case, that has to be: 'the licence > should be such > that it would maximize Wine's development'. Yes, but I don't believe that LGPL does, that I have being trying to explain in I forgot how many mails. > > > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? > > > > No, not nessararily. See different mail. > > 1 follows from 0. Period. You can not agree with 0 and > disagree with 1, no > matter what you write in other emails! :) Again, THE SPIRIT > of LGPL, not > the letter. Again, the spirit is: 'if you improve Wine in minor ways, > please contribute back your improvements'. Yes, and the key is minor ways and I believe that is a absolute non-issue as I have explained before. There is no profit in holding minor improvements. > > > 2. If so, why shouldn't we formalize it in the license? > > > > But it isn't nessarily so. > > And why is that? Quite the contrary, because: > > -- For people that contribute back, would chnage nothing > -- For people that don't contribute their changes, it's no > good to us, so > we don't care (which follows by point 0). > > Tertium non datur. That is, there's no other case. QED. OK, since you bring mathematics in to it, I will try to explain in mathematical terms: "The set of people is not invariant over a license change." In fact the set of people are likely to be considerly less. While I have no strict mathematical proof of that, I especially point to Gavriels' reply concerning Corel and Transgaming.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On 2001.12.18 05:09 Patrik Stridvall wrote: > [snip] > > Dimitrie O. Paun wrote: > > > Stop for a movement and tell me: are you against the letter > > > or the spirit > > > of the LGPL. > > > > Asking that question is like asking whether I support the spirit of > > Communism: > > "From each according to his abilities - to each according > to his needs." > > > > Well, it sound nice doesn't it? However doing a little > deeper analysis > > I realize that the price for being able to do this is not > worth paying. > > > > Note however that I'm not equating GPL or LGPL with Communism. > > It was just an example from real life, that you get more that > > you wish for. See below. > > > [snip] > > That's a piss poor example. The statement that something > would be from > each according to his abilities and to each according to his > needs sounds > to me at first glance like it would suck. And you don't have > to dig too > deeply to figure out why that would suck. But maybe that's > because I am > an American capitalist though and through and that blatantly > conflicts > with my core values that everyone should do for themselves. Perhaps. However, I think that if you move to Europe, especially northern Europe you will find that people have different opinions. While most people there certainly do not believe in Communism and to various degrees understand why is doesn't work, people are more inclined to be believe in this principle. Actually I think the reason for this is more Protestant Christianity than Communism, but why is not really that important. > And to get > off topic, why is that? Because that's what everybody will > do anyway, > might as well work with that rather than pretend that it is otherwise. So there is no such thing as morality? > This has lead me to another thought. We cannot pretend that > people are > going to release code back to Wine under the X11 license. > However we can > realize the obviousness of the truth that given the chance > people will > take whatever they can and give back nothing in return. Some > folks will > give back because it may make more sense to do so than to > not. But some > folks will be more than happy to take the whole codebase for > their own > good and provide nothing in return. > > We need to stop living in the dream world that everyone who > uses Wine will > contribute back. I have no illusions that everybody will. However there is no need to scare away potentially good companies by using a hard to understand license. > Yes, it is true that Corel, Codeweavers, > TransGaming, > etc. have given a lot to Wine. None of them was or is > required to give > anything. And yet they did. That is kind of shocking for an American Capitalist, isn't it? :-) > If the goal is to let people know that if they want to use > Wine then they > need to contribute back, then the only choice is to put that into the > license. By "use" I am obviously not referring to simply porting an > application using Winelib. I am referring to incorporating > source code > from wine into their own products. > > This is exactly what the LGPL was meant to address. And if they borrow some obscure functions, they might even supply some bugfixes in hope that at a later stage there will be more bugfixes waiting for them when they borrow again (resync) a year later. And if they don't, who has been hurt? If Wine was LGPL:ed they certainly wouldn't have borrowed at all, so no chance at all of getting any bugfixes back at all. > I recall Uwe's usual .sig which is: > Free Software: if you contribute nothing, expect nothing. Indeed and what is your hypotetical sig? "LGPL:ed Software: if you contributed something, use the law as a tool to force others to contribute as well." > Maybe we should have one for wine: > Wine: If you contribute nothing, well, there isn't shit we > can do about it > since we are X11 licensed. I don't think that one came out the way you hoped. Try again.

1 0

Installshield 6 (inter-proc) patches
by J.Brown (Ender/Amigo) 19 Dec '01

19 Dec '01

Any idea when Oves interprocess patches will be put into the main Wine CVS tree? The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support. Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]

5 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Mon, 17 Dec 2001, Patrik Stridvall wrote: > > > > This has been my argument against Patrick exactly. Some > > > protection is better than none at all. > > > > As a general rule, yes. > > > > However this time the protection comes with a price. > > And what might that price be? You fear that we are going to > alienate the > commercial ventures developed around Wine? Yes. > > The problem is not whether LGPL is well written or not the > > problem it is the doctrine of derived work. That is very > > unclear because of lack of good case law. > > Oh, come on, for crying out loud! The LGPL is the best thing > we have -- we > can't wait for a good case law to adopt a license. Yes, there may be > problems, but that's life. We take our best shot -- this is what we're > doing with Wine in the first place! The main problem is that using the LGPL introduces uncertainty to what is allowed and that advantages is not good enough IMHO to outweight the disadvantages. > Patrik, your entire arguments are based on such obscure > assumptions that's > scary! I must tell you, both the GPL and LGPL have received careful > scrutiny from FSF's legal council (and a bunch of other law > professors, > I'm sure). The problem is the doctrine of derived works. Nothing else. Even if their understand of other parts of law are perfect it matters not. IIRC their arguments always seen to assume that the doctrine of derived works is unproblematic if applied to source code. > It's the best we can hope for now. You come along > with a bunch > of 'it is possible' type of scenarios (doh, everything is > possible!), and > say that 'well, everything's in vain, we're doomed, there's > no point in > doing anything, actually...'. In all honesty, it just looks > stinks. Badly. To connect again to the example of the spirit of Communism: I am sure it was very popular to dismiss to fear of the opponents by saying what you have been saying. Trivialising the problems and clinging to clean, pure and uncomplicated spirit of it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Patrik, > > The more I read your posts, the less I understand what you > are trying to > say. You argued over many hundreds of lines over weird > technical details > and various dubious assumptions about what courts will do in > the future. The main point is that what is legal allow is very unclear. I'm not primarily trying to explain what is legal allowed or not, just pointing out some difficulities in understand what the law really means. > Stop for a movement and tell me: are you against the letter > or the spirit > of the LGPL. Asking that question is like asking whether I support the spirit of Communism: "From each according to his abilities - to each according to his needs." Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. > The spirit is simple: > > Here is this thing, we give it to you for free, use it for your own > benefit however you see fit. But it's a labor of love, and > many people put > thousands and thousand of hours in it, together with their hearts and > souls. As such, they hold it dear, and they want it to survive, and > thrive. All we ask is: if you've made _small_ improvements to > it, to make > it useful to your purpose, please contribute those back such > that our baby > can grow and develop together with your business. I'm against the fact that the GPL or to a smaller extent LGPL tries use the doctrine of derived work as a weapon to achieve their goals. It is a very dangerous weapon, since if the courts or the policitians decide that a strong doctrine of derived work is good it might be disasterous for society as a whole. Various commerical intrest might (read: will) for example try to use this to stop 3rd party additions to their works and I don't want that to happend. In short: Be careful what you wish for: "The road to hell is paved with good intentions" > Note that I said "_small_ improvements" because of the > modular nature of > Wine. If the improvements are big, the DLL separation would > allow them to > keep those changes proprietary. I don't think small improvements is a problem anyway and beginning an implementation of say DCOM is probaly not a small improvement and DirectX certainly isn't. > I fail to see _any_ moral/ethical/philosophical problem with > this. Do you? Perhaps you have been more enlightend now.

5 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Technicalities aside, the LGPL spirit seems to be accepted by most > people. We've heard no end of discussion of what represents > the code, and > so on, but in reality (please Patrik :)), Wine is a > _well_defined_ piece > of software. In fact, it's defined by Microsoft, and well > accepted by the > world at large. > > Now, that being said, there seems to be two camps: > -- the BSD camp, which maintains that BSD is good enough, and that > people will in fact do what the LGPL wants. > > -- the LGPL camp, which says 'well, if that's the case, why > not have it > formalized in the license'? No, I think you misunderstand. I'm not in the BSD camp as you define it. I do not nessarily believe that everybody will follow what the LGPL wants or at least that they will do things that they are certain would have been allowed if it was LGPL. And that is an important part of my objection: It makes it less clear what is allowed. > Before I go any further, I would like to stress a very important > point: Wine is in fact a collection of independent projects. > These are the > DLLs, and they nicely (and unequivocally) partition Wine into lovely > little, independent components. And this means that the LGPL is > independently contained to each and every DLL. It is the _perfect_ > position to be LGPLed. You forget that some "independent"(*) parts like the Crypto API are parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. Actually large parts of the Windows API are "independent"(*). They are just helper function wrappers around other functions. (*) By "independent" mean that they just use other parts of the Windows API like normal applications do and claiming derived work for this would be absurd, just like claiming it for normal applications would be absurd. > At this point, I would like to know if people agree up to > this point. I don't. > The > discussion has been going all over the place, so I would like > to keep this > email short and to the point: > 0. Isn't Wine's best interest to evolve and develop as fast > as it can? Yes. > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? No, not nessararily. See different mail. > 2. If so, why shouldn't we formalize it in the license? But it isn't nessarily so. > When answering these questions, let's try to leave the > commercial aspect > out of it for a second. That is a separate discussion. You > see, the reason > we care about the commercial aspect is that we hope (from > Wine's selfish > point of view -- as it should be!), that the commercial world will > actually _help_ in the development of Wine (that is, having a > commercial > universe around Wine would be in Wine's best interest). Now, > I claim that > the LGPL is _way_better_ for the commercial interests in the > long term, > but I will leave that to a future email (if people care to > discuss it). Claiming that it is better for Wine as a whole is one thing, but claiming that limiting commercial intrests choices is good even for them, requires a explaination.

2 1

implementation of ImageList_*Drag*
by Michael Stefaniuc 19 Dec '01

19 Dec '01

Hello, the attached patch (it's my first wine gui patch, that's why wine-devel is CC'ed) implements the dragging part of the ImageList functions. It works quite well with FreeSolitaire besides the dragged image isn't drawn semitransparent. But how do I draw a semitransparent image? IMO this isn't possible with the BitBlt functions. The ImageList_*Drag* functions shouldn't produce flickering as per the MSDN documentation, but ImageList_SetDragCursorImage (at least in Win9x) produces a short flickering when called. I implemented this function to match the behavior of the native comctl32.dll, but it would be very easy to stop the flickering. Should I change it or keep the Win9x behaviour? bye michael Changelog: Michael Stefaniuc <mstefani(a)redhat.com> fixed/implemented the ImageList_*Drag* functions -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

does mingw include share.h
by Bill Medland 18 Dec '01

18 Dec '01

I'm just off home now so I haven't time to learn sourceforge and download 100M. I need a share.h to go into the msvcrt (for two lousy symbols). I see that much of the msvcrt is based on mingw. Does it include share.h? TIA Bill

1 0

Re: Big Bummer for running Shrinkered files!
by Robert Baruch 18 Dec '01

18 Dec '01

Uwe: > showsehframes.exe from the examples there foinds an endless loop even with > native msvcrt: That was a good idea, to try out that program. I'll have to review how that whole program works. Maybe it has something to do with the fact that scopetable is only valid inside MSVC code -- anything in a frame past the handler and prev ptr is compiler-dependent. Maybe it will work once I finish the EXC_CallHandler code. --Rob

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> Patrik Stridvall wrote: > > > > > Patrik, > > > > > > The more I read your posts, the less I understand what you > > > are trying to say. You argued over many hundreds of lines > > > over weird technical details and various dubious assumptions > > > about what courts will do in the future. > > > > The main point is that what is legal allow is very unclear. > > Hogwash. I feel the LGPL is extremely clear. It allows > you to dynamically link to LGPL code without worries. Full stop. The clearness of the LGPL in itself is a non issue. The issue in the foundation that LGPL rests on namly the doctrine of derived work. > Patrik, it might be good for you to create a web page outlining > the problems you see in the LPGL; that would give you a > chance to explain > them more clearly than is possible in this forum. Do try to > be succinct. > I'd like to understand your point of view. Hmm. I think I already spend to much time trying to explain my point of view. I would rather answer questions concerning details insteed. Perhaps I will someday, but don't hold your breath.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> > But most apps wine will run *cannot* use a GPLed component. GPL > > expressly forbids being linked to a nonGPLed component. > *GPL does not > > only cover the source, but rather the USE of the components > as well. > > Read the > > license. It's quite an eye opener. > > I'd argue (though IANAL) that a nonGPLed win32 executable > running under > wine is not being "linked" to any GPL component - wine itself may be > linking to its own GPL components at run-time depending on > what's going on > with the win32 executable. But in terms of true linkage, I'd > have viewed > the win32 executable as more like a document that causes the host > application (wine) to load appropriate sub-components with > which to process > the document. MS Word (to use an example) might have to > dynamically link in > a special MS Word component to process specifics in my > document, it doesn't > mean my document is "linked" with the MS Word component does it? Ah, you are beginning to see the problem. :-) This is the spot on one of the main problem with the GPL. Proponents of the GPL are trying to use the doctrine of derived work as a means to achieve their goal without realizing (or rather ignoring) that if the doctrine of derived work supported want they wanted it would also, as a logical consequence, support to the absurdity you meantioned above. This is why I firmly oppose the doctrine of derived work and instead hope that the courts will embrace the much more senisible doctrine of combined work that I have been talking about earlier. Of course a strict doctrine of combined work would make the GPL and for that matter the LGPL largely meaningless, since you could distribute the LPGL work, the proprietory patch and a combining script seperately and let the user do the combining as thus no combined work is distributed and thus no violation of copyright law. Note that a doctrine of combined work doesn't effect normal commercial software at all since the end user is legally required to pay for the software if he uses it, regardless of whether the user used some patch offered under whatever license. It ONLY effects viral licenses. > Of course, we could all ask RMS his opinion but we all know > he'll interpret > it (once again) to mean whatever is required to spread his > GPL tenderhooks > as far as possible. Living in Wellington, NZ I'm having to > fight back hard > the temptation to make a "Sauron" joke here ... :-) I don't believe RMS is evil, quite the opposite, just that: "The road to hell is paved with good intentions"

1 0

Re: Big Bummer for running Shrinkered files!
by ek sqrl 18 Dec '01

18 Dec '01

On Mon, 17 Dec 2001 14:49:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> wrote: > Did you try running wine with -winver win98? Yes, Shrinker tries to load a VXD which is not allowed under Wine. At first I was going to implement a special Shrinker VXD replacement for Wine, but then I found that it wouldn't try to load the VXD under --winver nt40. Thus, I figured I would try to resolve the problems with running under nt40, since that would (at least theoretically) improve the existing functionality of Wine, rather than add new functionality. > > Did you try finding an Un-Shrinker? A quick search using google turned > up a few candidates. Haven't tried any out though. Yes, I've looked at them. They all seem to be h4x0r toolz with no source code. Some new news on the Shrinker front. I've managed to determine, for the most part, what Shrinker's exception filter function does. It's a minefield! Recall that earlier I said it was looking for a magic signature in ntdll.dll. I found all of the landmines. The first landmine makes sure the exception handler was called with the code "call ecx". If not, the process dies. Next, we read 8 bytes from the process around that location. If the read fails, the process dies. If the code starting with the call is not FF D1 64 8B 25 or FF D1 64 8B 0D, the process dies. It then tries to allocate some memory, and copies some of the process code into that memory. If the allocation fails, the process dies. With that in mind, it seems that the only thing it's really looking for is that signature. So one idea that I had is a "Shrinker fixer". When Wine loads an executable, it would look for this specific exception handling code, and then NOP out the checks. Is that a reasonable approach? --Rob

4 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> Did anybody mention that if wine moved to an LGPL license, we would be > able to borrow code from a wider variety of other projects? > > That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS > and any other LGPL (or compatable) projects. Sure, but I would much rather use them by linking them to Wine than borrowing code and having to maintain it. Whether Wine is LGPL or BSD matters not in such cases.

1 0

Re: Installshield 6 (inter-proc) patches
by Roger Fujii 18 Dec '01

18 Dec '01

Alexandre Julliard <julliard(a)winehq.com> wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > As for the license of Wine, I was among the ones opposing the LGPL last > > time it was discussed, and I have not changed my mind. I feel that Wine is > > most widely useful if it keeps the X11 license, and usefulness is more > > important in my mind than making it 50% harder for companies to "steal" > > the code. If X11 is so bad for large projects such as Wine, why is the > > largest project of all, XFree86 (and associated projects like DRI), still > > using it, even though its maintainer would have the power to switch to > > e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)? > > A thing to keep in mind is that X11 got almost killed by licensing > issues and the proliferation of closed source vendor versions. You understanding of X11 is pretty flawed. X11 had closed parts of its implementation practically from the very beginning. Look at the original X11 contributers. It was DEC, SUN, IBM... The main reason for the dry spell was that it became a mature product. Why tinker with stuff that basically works? Vendors, quite unlike the GNU people, really resist changing things without a good reason. I think the current interest in the X project was due to the advent of so many graphics cards plus 3d/video. Look at gnuemacs - it's GPLed, and had a really long dry spell. Was the lack of interest the result of the licensing? > If the XFree86 team hadn't picked it up, there probably wouldn't be a free > version of X11 available today. What are you talking about? What do you think is sitting on www.x.org? > This is something that could happen to Wine; Wine should be so lucky as to be accepted like X11..... > and if it does happen, will we find enough people to do what > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > people like Patrik saying that it's OK for parts of Wine to become > proprietary because we can't do everything anyway, I'm worried. If wine was even CLOSE to being complete, I would agree with you. But given its current state, I think that a *gpl license would just discourage companies from even looking at wine (I can't see why any company would like *GPL over X11 so long as they are not the givER - this is not to say they won't accept *gpl, just as to what the preference would be). And given that IMHO, a lot of wine work to be done (looking at Direct* and other M$ stuff) falls under the unpleasant column (ie, most people won't do this for fun), discouraging commercial work doesn't seem to be the way to go. -r

5 6

Re: Installshield 6 (inter-proc) patches
by Mike McCormack 18 Dec '01

18 Dec '01

Did anybody mention that if wine moved to an LGPL license, we would be able to borrow code from a wider variety of other projects? That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS and any other LGPL (or compatable) projects. Mike http://freshmeat.net/browse/16/?filter=&orderby=popularity_percent+DES C > 0. Isn't Wine's best interest to evolve and develop as fast as it can? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> > Then if the LGPL holes are dangerous, the X11 license should be even > > more dangerous; after all it's a much larger hole than the LGPL will > > ever have. I still don't understand where you are trying to go with > > your argument. > > > This has been my argument against Patrick exactly. Some > protection is > better than none at all. As a general rule, yes. However this time the protection comes with a price. > > You really make it sound like the LGPL is some kind of unexplored > > wilderness that we shouldn't venture into. The fact is that a large > > majority of free software projects use either the GPL or > the LGPL, and > > in practice it works just fine for them, just as I'm confident it > > would work just fine for us. > > > Agreed. The LGPL is a very well-written fairly clear > license. There are > some borderline cases as mentioned, but this does not mean > that we should > thus throw the possibilty of LGPL completely out the window. The problem is not whether LGPL is well written or not the problem it is the doctrine of derived work. That is very unclear because of lack of good case law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > The crypto part of ADVAPI32 was the example I used. Let's > say I were > > to write a CryptoAPI implementation as a set of seperate > source files. > > With the LGPL I could compile all of that stuff and refer to it as a > > library. What is a library? I would say one or more object files > > linked together form a library. I could then take my CryptoAPI > > library, link it with the rest of Wine's ADVAPI32 and distribute a > > libadvapi32.so that could be dropped into a wine install. > > If it is a completely separate library that doesn't contain portions > that are derivative work of ADVAPI32, then yes you can do that. But > you cannot for instance decide to reimplement CreateWindow and not > release it simply by putting it into a separate file, which was what > Patrik suggested; because your new CreateWindow will necessarily use > internal functions and variables of USER32, and thus would be > considered a derivative work. It takes more that use to be considered a derived work, but the doctrine of derived work is central to the discussion. One thing that is very important to note is copyright only protects expression not fact or ideas. In this case we are talking about use which I guess is better to talk about in terms of functionality. Functionality on the other lies closer to fact or ideas than to expression so I would consider it doubtful for the courts to extend the doctrine of derived work to protect this.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> Alexandre Julliard wrote: > > > > Gavriel State <gav(a)transgaming.com> writes: > > > > > There are several factors to that equation, and I'm > afraid we don't have > > > a firm ETA yet. > > > > Well, this worries me. It sounds like you are planning to > do the same > > thing you did with your DirectX stuff: by making the code > available on > > your site, and promising to release it at some hypothetical future > > date, you remove all incentive for other people to spend time > > improving the main Wine, thus ensuring that it always lacks some > > features. I don't like this at all. > > > > If you can't/don't want to release your code, I'd strongly suggest > > that you reconsider your strategy of making it publicly > available. If > > it was only available to paying customers, there would at least be a > > reason for other people to work on a free implementation. But if > > everybody who needs some feature in Wine can simply download WineX > > instead, no one will spend time re-implementing that > feature. This is > > beginning to seriously hurt the project, and we need to > find a way to > > address this issue. > > The DCOM issues had been ignored by other Wine developers for YEARS > before we came along. Yes, but that is because it hasn't been needed for anything but obscure application until now. > It's not at all clear that our work there has > discouraged anyone else from working in that area. Granted. > To say that > our work is preventing anyone from doing a free version of DCOM is > completely incorrect. To the contrary: we have already contributed > substantial amounts of this code to the public tree - thousands of > lines, in fact. That can only help anyone with a sudden and > unexpected > interest in recreating our work. That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below. > Now, it is our firm desire to see *all* of that code end up > in the main > version of Wine. The fact is, unfortunately, that we simply cannot > afford to give everything away as soon as we write it. We only got a > minimal implementation of the DCOM code working six weeks ago. We are > not a rich company, with millions in VC funding to burn; this > means that > our DCOM work has to remain under the AFPL until we can find a sponsor > willing to defray some of the tens of thousands of dollars it cost us > to develop it. I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-) What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy. Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already. In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long. > Furthermore, we are committed to writing quality, robust > code. We don't > think it's in anyone's best interest for the current version > of the code, > which is effectively limited to the requirements of > InstallShield, to be > used as the basis of future DCOM related work. We in the midsts of > working on a much more flexible architecture which will permit more > than just typelib based proxying. > > I don't really think this affects individual users at all. They can > simply download and use the code from our website, or apply the > necessary patch to WineHQ wine. They can even redistribute it all > non-commercially should they wish. > > Without a doubt, we are committed to the Wine project and have already > contributed a great deal of code to support it. However, to > maintain the > quality and integrity of the project, we stand by our decision of only > contributing code when it makes sense to do so (in order to > allow us to > continue developing quality code) and when it reaches a > certain minimal > degree of quality. Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now. However I reserve the right to do so in the future. > Publicly questioning our ethics is certainly not the right solution > nor is it in the spirit of the project, especially given how much we > have supported it to-date. We believe that we ARE doing the Wine > user and developer community a service and propelling it further. I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all. In short: Should the Wine project wait until you release or should it not? > The > only people that our lack of haste in contributing code back really > affects are organizations that want to make immediate commercial use > of the code. These organizations include the one you work > for, and its > clients. If you want to see the DCOM code Wine-licensed soon, you > need to talk to your boss and your clients, not me. :-) I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong. Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following. A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows. > At this point, I think it would be best if we were to take this > discussion off-line so that we can determine a solution that works > for everyone. For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-) However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it. I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine? Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement. Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine. Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.

10 16

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> > But you cannot change the license once it is mostly > complete; by then > > it will be too late. > > If it was mostly complete, what would it be too late for? Yes, I wonder that as well. To late for a 100% open source world perhaps, but then only the most naive (like Richard Stallman) actually think it is realistic. Open source is good for some things, but it is not the solutions to all problems. > Patrik Stridvall <ps(a)leissner.se> wrote: > > > Why would you want to change the license when it is mostly complete? > > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > I was using the following lines of thinking: If it were > mostly complete, > any changes would most likely be the result of bug fixes or > minor improvements. Exactly and therefore there would be very hard to find a niche for a company to profit in. > In the end, if you look at the larger projects (mozilla, > openoffice, perl), you will > see that any of them uses a straight *gpl scheme. My You mean _neither_ of them, I guess. > suggestion is that if you are > going to change it, change it to something like a currently > existing project that > has commericial involvement (mozilla/openoffice). And the advantage of this would be the following?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So you mean that all the people that are current voluntering > > to work of Wine won't work on Wine if it is almost complete > > just because somebody else have done the parts they need > > to run their applications and that they will happily pay for > > the right to use it. > > No, I'm not saying they won't work on it when it's almost complete. > I'm saying that there may not be enough incentive to complete it if > all the parts are available under more or less proprietary > licenses. Maybe I'm wrong, but your reasoning that it's OK for people > who want games to have to pay for it certainly doesn't reassure me. What I meant is that for people that play games might it might make more sense to pay a monthly fee since most of them, I guess, lack the knowledge to contribute to Wine anyway. Companies wishing to use Winelib to port their productivity application are not in the same situation, they have the resources pay somebody to improve what they need or perhaps even do it themselves. Sure they can also choose to pay companies with business models like Transgaming but then they become dependent on them to fix bugs in the extra parts they supply. Actually, this is analogous to normal argument for using open source instead of proprietary software, nothing that is unique to Wine. In short: The incentive is the same as working on any open source software. Sometimes is makes sense, sometimes is doesn't. > > In that case it would be disasterous to make Wine run > > all Microsoft implemented non-core Wine DLL:s because > > then everybody would just be happy to use the Microsoft > > DLL:s and nothing beyond non-core would ever be > > implemented. > > It would not be a disaster, but it is certainly a potential problem > too. It is a smaller problem first because making the dlls run is > about as much work as reimplementing them, and because they are > completely proprietary, not half-way open source. But yes, I do think > a number of features could have improved faster if people didn't use > native dlls to work around the problems. There is a distinct possibillity that people used the time they didn't need to reimplement the working Microsoft implemented functions to implement functions that didn't work so it is quite hard to provide hard proof on this. Furthermore the fact that a lot of the Microsoft implement functions works might instead have encourage people to work on because SOMETHING work instead of giving up then NOTHING worked. In any case I think neither of us will be able prove the correctness of our respective theory.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> > > and if it does happen, will we find enough people to do what > > > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > > > people like Patrik saying that it's OK for parts of Wine to become > > > proprietary because we can't do everything anyway, I'm worried. > > > > If wine was even CLOSE to being complete, I would agree with you. > > But you cannot change the license once it is mostly complete; by then > it will be too late. Why would you want to change the license when it is mostly complete? There will be very little reason for companies to enter the market at that time and why try to make it difficult for the few that might.

2 1

win32eviceIoControl problem
by Ancient Computers 17 Dec '01

17 Dec '01

When trying to run a game called Visual Pinball, I get this as console output. The DecodeHash problem can be fixed by using a windows version of advapi. What about the win32eviceIoControl problem, what is it about ? [root@localhost Visual Pinball]# [root@localhost Visual Pinball]# wine Vpinball.exe x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b58f8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b5d64)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:advapi:CryptAcquireContextA (0x405b5c30, (null), (null), 1, f0000008): stub! fixme:advapi:CryptCreateHash (0x405b5c34, 0x8001, 0x0, 00000000, 0x405b5c58): stub! fixme:advapi:CryptHashData (0x10010, 0x49ab80, 14, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b5c5c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b583c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x41615710, 4, 00000000): stub! _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> While I am thinking about this, there are some interesting > things in the > LGPL. One of these is that you can modify the LGPL library > to work with > your code. The catch is that you have to release source to the > modifications and that the modifications must not require that your > proprietary component be included. The text of the license > mentions that > if you modify a function that computes square roots to hook into your > proprietary components that the function must still compute > square roots. > But in Wine's case, many functions don't do what they are > supposed to do, > or they do what they are supposed to do but that's not what > actually needs > to be done. That is a very intresting point. Thank you for bring it to my attention. I didn't realize that. Hmm. I will have to think about it what this means, if it indeed means something. > This stuck out like a sore thumb to me, but > maybe it's not > such a big deal. Can you perhaps say exactly what bothered you?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > No, of course the LGPL doesn't provide absolute > protection; nothing > > > does, and I don't think absolute protection is desirable > either. There > > > are some things that the LGPL clearly allows, some that it clearly > > > forbids, and a number of border cases, that frankly are only > > > interesting to people who want to try to get around the license > > > restrictions. And what would be the point of doing that? > > > > Making their business model work. > > Trying to ensure investment return. > > That would be the case if the code they are using magically turned > LGPL once they had invested millions. But that's not possible, since > only new code becomes LGPL. Indeed and that makes any protection LGPL gives even weaker. My earlier analysis was based a 100% LGPL:ed Wine... > Now, if someone is basing his business > model on turning LGPL code proprietary by exploiting possible > loopholes in the license, I wouldn't suggest investing in his > company... I don't think our goal in choosing a license is to make > sure every flawed business model can succeed. There are lots of > reasonable business models that can be built on a LGPL (or GPL) code > base. Lets arguments sake assume somebody is called Bar and have a business model that might possibly be illegal under your interpretation of the LPGL. What's preventing him from creating a library called bar under his proprietory license as well as supplying a patch under the LGPL that results in code looking like: void WINAPI Foo(void) { #if HAVE_LIBBAR BAR_Foo(); #else /* Old Wine code */ #endif } Wouldn't this always be legal under the LGPL? In that case the only thing you did by threatening to sue him was to increase his costs. The point is, you didn't get his code, that it seems, that you hoped you would get. > > The current license is something that is easy to understand and > > are unlikely to scare companies like Transgaming away, but can > > you really say the say same about LGPL? > > OK, now we are getting somewhere. So your argument is basically that > the LGPL might scare some companies away. Yes. > Yes, I agree that's a > possibility. Good. > Most likely these companies will have been scared away > from Linux already, since many other things they need are also LGPL > (most notably the C library). That is a claim that makes no sense at all. Why should anybody want to make a business model out of modify or making additions to the almost 100% complete C library? One of the main reason Wine has the possiblity at all to attract companies like Transgaming is that it is not complete far from it. > But of course this possibility cannot be > excluded. Indeed. > I think that the risk of this happening is not larger than the risk of > having companies hold hostage pieces of Wine, and the damage in the > second case is much larger; so I think the LGPL would minimize the > potential damage to the project, even if damage cannot be excluded in > any situation. Your analogy with hostage holding is a bad analogy, sure I understand that you are refering to Transgaming promises to release eventually. If you don't believe them announce that publicly and developers that might be hanging back in fear of doing "double" work might step forward. They might not, of course, but then perhaps nobody was intresting in doing work in that area, Transgaming or no Transgaming. > Of course only the future can tell us who is right. Agreed.

1 0

Filename case handling
by Duane Clark 17 Dec '01

17 Dec '01

I have a question about the handling of filename case when trying to find an existing file. When files are on a win filesystem, the case is ignored, by the setting of flags by DRIVE_GetFlags(). As expected. When on a ext filesystem, that call sets the DRIVE_CASE_SENSITIVE flag, which is ok. But then the flag is used in the call to DOSFS_FindUnixName() (from DOSFS_GetFullName()), and I guess the fundamental question I have is under what circumstances wine would want to do a case sensitive search. One of my apps (Xilinx ngdbuild) always supplies upper case names when searching for a file, but the files always have lower case names (they were created by another Xilinx app). When searching for this file in DOSFS_FindUnixName() on an ext filesystem, the first test always fails, because we do a case sensitive test: if (!ignore_case) { if (!strncmp( long_name, name, len )) break; } However, and here is the other part I am questioning, if the file is an 8.3 filename, an alternate dos filename is created by DOSFS_ToDosFCBFormat(), and then a second test is performed here: if (!strcmp( dos_name, short_name )) break; This call passes and the file is found. However, if the file is not an 8.3 filename, the call to DOSFS_ToDosFCBFormat() fails, and no case insensitive test is made. So it seems to me that either a case sensitive search should be made in both cases, or in neither case. And of course I think that it should be both cases (since this fixes my app) :-) Duane

3 4

Wine and Drivers
by Viacheslav Zilberfayn 17 Dec '01

17 Dec '01

Hello, I'm wondering if anyone ever attempted to use wine to run Windows driver, specifically videocard drivers. Or at least to load them. I'm thinking of using Wine to load windows drivers into Linux, along with whole DirectX. I understand that drivers are special s/w, but I guess they use smaller part of windows api. Any information/opinions would be appreciated. Slava ===== --- NOTE: EMAIL HAS CHANGED !!! --------------------- Slava Zilberfayn | Home +1(416)7838430 EMAIL: slavka012(a)yahoo.ca ADDRESS: appt 1219, 377 Ridelle ave, M6B1K2, Toronto, ON, CANADA ______________________________________________________ Send your holiday cheer with http://greetings.yahoo.ca

2 1

Microsoft Antitrust Remedy proposal, take 3
by Dan Kegel 17 Dec '01

17 Dec '01

I've learned a fair bit since putting together my essay on the States' proposed remedies. In particular, Microsoft's response to the States was enlightening; it pointed out the parts of the Court of Appeals ruling that need to be heeded when fashioning a remedy. I now feel that the States' proposal has little chance of being accepted by the judge. The Proposed Final Judgment negotiated by Microsoft and the DOJ is probably the right starting point for any new proposals. Accordingly, I've started over, and this time I'm sticking very close to the negotiated settlement, and paying close attention to the law. As before, you can read my proposals at http://www.kegel.com/remedy.html I'm looking forward to your feedback. I've set up a mailing list at http://groups.yahoo.com/group/ms-remedy/ (aka ms-remedy-subscribe(a)yahoogroups.com ) for those who want to discuss this further. Together we can find a way to make the settlement more just and fair, or I'll eat my hat. Dan Kegel http://www.kegel.com

1 0

Re: Big Bummer for running Shrinkered files!
by Mike McCormack 17 Dec '01

17 Dec '01

Hi Robert, Did you try running wine with -winver win98? Did you try finding an Un-Shrinker? A quick search using google turned up a few candidates. Haven't tried any out though. eg. http://www.programmerstools.org/unpackers.htm Mike > Given that the application appears to look into ntdll.dll's > code to compare it against essentially a magic number, is there > any hope of getting Shrinkered exe's to run under Wine? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Wine and Baldur's Gate
by Ian D . Stewart 17 Dec '01

17 Dec '01

On 2001.12.16 21:39:52 -0500 Peter Hunnisett wrote: > <snip> > > > fixme:dsound:IDirectSoundBufferImpl_QueryInterface > > Unknown GUID > > {31efac30-515c-11d0-a9aa-00aa0061be93} > > > > (undocumented API call?) > > > > Anybody knows what this GUID refers to, or how to > > research it, I would be > > much abliged. > > Get a copy of the DirectX SDK and check out, most > likely, dsound.h. The GUID defines the interface that > the application is trying to aquire through the > IDirectSoundBuffer interface it already has. You'll > probably find that it's basically asking for an > unimplemented feature of direct sound. Thanx Peter. I'll check it out (tomorrow... ;)) Ian -- Linux, the choice | "Eat, drink, and be merry, for tomorrow you of a GNU generation -o) | may work." Kernel 2.4.15-gr /\ | on a i686 _\_v | |

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 17 Dec '01

17 Dec '01

At 02:20 PM 16/12/2001 -0800, you wrote: >Well, this sounds like an argument for the LGPL. There is absolutely >no guarantee of stability with the X11 license; anybody can start a >Wine tree under another license, and if developers think this is a >good idea there is nothing I or anybody else can do to prevent it. Theoretically yes. The project leader has a much higher chance to do it successfully in fact. Since he is fixing the rules in the first place he has to be more responsible IMO. >It's simply part of the existing rules that the rules can change. trusting people is always a problem, yes. >You know, that's exactly why we are having this discussion. If I was >as selfish as you seem to think, I could change the license today >without asking anybody. > I'm not doing it precisely because I *do* care >what people think, and I won't make the change unless it is acceptable >to at least a large majority of the people affected by the change (and >yes that includes Transgaming). it's for them (and possibly others professionals) to say then. Gerard

3 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> It would help us in several ways. First, since we've > always effectively > treated the Wine code base as though it were LGPL, we would gain > the protection that the LGPL offers. If someone else takes > the code we've > worked on, and competes with us, we would gain back > any improvements that they make. For example, if Wine had been LGPL, > then Transgaming would have been oblidged to release > Installshield fixes > back > (after all, they do follow on work that we did). Not according to the David Elliot and I agree. Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released. > With better > InstallShield > support, for example, our CrossOver customers might have a > wider range > of plugins > that would successfully install. This is a pretty minor problem; I > can't think of a > significant plugin affected by this. :-) Of course you claim that. Even if it was a problem you probably wouldn't admit it since it might raise to price in any possible negotions with Transgaming. :-) > Further, I think I > understand why > Gav has > has hesitated on this issue, and I firmly believe that Transgamings > intentions > with regards to the Wine project are honorable and good. As said above the only thing it would enforce would be file seperation so you more easily could integrate the part from Transgaming in your CrossOver product. Of course distributing it after that would violate Transgamings copyright, so you really need their permission after all. The point is LGPL wouldn't help you here. > However, I can imagine alternate scenarios where we could > have all of > our hard work > used against us by others who are more ruthless than Gav, and so the > LGPL would at least offer us some protection from that threat. Does it? It seems you overestime any advantages of LGPL. > A second benefit is simplicity. I spend a lot of time discussing > license > issues with my customers, and fighting very difficult battles to > preserve the integrity of the Wine code base (and while that sounds > noble and all bear in mind that a single, coherent source > code base that > I can fully > use is a key part of my business strategy). So, if the > license were LGPL, > my negotiating requirements would be simplified. In fact, I > would feel > free to > encourage my clients (and my company) to ruthlessly take > advantage of every > possible opportunity to create competitive advantages, because I feel > that the LGPL would protect the integrity of Wine. The same question here: Are you sure you are not overestimating the protection LGPL provides? > Of course, there are a number of downsides. First of all, it is > possible that > I would have fewer clients; the LGPL is complex license, > and it's core premise can deter many people. That is one of my objections as well. > It is widely > believed in the > Wine community that Corel would have never touched Wine if it had > been LGPL, and Corel's contributions to Wine were very significant > (the irony of course, is that AFAIK, Corel treated Wine as though > it were LGPL). Side note: I am one of them. > Second of all, the LGPL does, oddly enough, take away some freedom > on my part. Today, I have a full range of choices available > to me with > every product I release or help a client to build. After a > switch to LGPL > (and after enough time had passed for the LGPL'd pieces to be > significant), I'd have to be very cirumspect every time a > public release > of a product was made to be certain that I had all of my licensing > ducks in a row. Exactly, it increases your cost of doing business. > For example, right now, we don't provide a copy of the > source code contained within our CrossOver Plugin Wine tree. The only > changes we have not published back into the main WineHQ tree are > ones specifically required to interoperate with a > Linux/Netscape plugin. > The changes we made to Wine would never have been accepted by > Alexandre as being good or generally useful patches, and yet > they could > conceivably give someone who wished to replicate our proprietary > Linux plugin code a good insight into how to go about doing > so. To be > honest, > we sweat a lot of blood and tears to learn how to do that > right, and it > would > hurt if someone were able quickly knock off CrossOver Plugin > because we were > forced to show that code. To be honest and actually say something in support of LGPL: This wouldn't be required even with a strict LGPL interpretation. You would have to provide object files for relinking but that would not be much worse than providing the binary. Reverse enginerring it will be almost as hard. > On the other hand, we also had a > heck of a lot > of work on the Plugin code that has nothing to do with Wine, and I'd > like to see someone knock that off quickly <grin>. :-) > With all that, speaking on behalf of CodeWeavers, I would neither > call for > nor oppose a switch to the LGPL. Since that change would > impact me and my > customers somewhat slowly, I think I could make the necessary > adjustments in time. Perhaps the clarifications above might make you change your mind? > The most important thing is for us to continue to have a vital and > thriving Wine community. Agreed. > Finally, speaking strictly on a personal basis, and with > no corporate > considerations whatsoever, I would welcome a change to the LGPL; > I have always preferred it to BSD style licenses (and to the GPL, > for that matter); with LGPL projects, I feel more certain that I know > exactly > where I stand and how my code will be used. Well, perhaps it is because you misunderstood what the LGPL means?

6 7

Wine and Baldur's Gate
by Ian D . Stewart 17 Dec '01

17 Dec '01

Well, Now that I've made it through the actual install, I figured I'ld take Baldur's Gate for a spin. The main screeen, where you select to play the game, change the configuration, etc, comes up fine. There's a slight pause after clicking 'Play' while BGMain.exe starts and X is set yo 640x480 (I'm guessing this has something to do with DETACH_PROCESS?), but that's no biggy. The opening credits and movie play just fine. I'm able to create the main character without any noticeable problems. The first 'problem' I ran into was at the opening of the 'Prologue' chapter. Under windows, a narrator's voice reads the opening text as it scrolls across the screen. Under wine, the text is scrolling, but sans naration. A bit annoying, but no biggy. The real fun starts when the game actually begins. First off, the sound, when there is any, cuts out quite a bit, with no apparent rhyme nor reason. Secondly, the left and bottom panels are covered by the main section. You have to click on the various buttons to make them display. The third 'error' appears to be related to X's virtual desktop. Moving the cursor to the left or bottom side of the screen moves the 'viewport' away from the window, instead of scrolling the view in the Baldur's Gate window. After shutting down Baldur's Gate, I noticed a whole slew of error messages in the xterm window I launched it from. Here are a few examples: fixme:module:CreateProcessA (BGMain.exe,...): DETACHED_PROCESS ignored fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403f8034,00020021,3):stub fixme:dsound:IDirectSoundBufferImpl_QueryInterface Unknown GUID {31efac30-515c-11d0-a9aa-00aa0061be93} fixme:ddraw:Main_DirectDraw_CreateSurface App didn't request a valid surface type - assuming offscreenplain err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX Any help in getting any of these issues resolved would be greatly appreciated! Thanx, Ian

2 3

Big Bummer for running Shrinkered files!
by Robert Baruch 17 Dec '01

17 Dec '01

The plot sickens... Here's the background info. I have a file, power-structure-demo.exe which can be obtained from www.write-brain.com. Uwe has another file, tar2001.exe. Both have been compressed by the commercial Shrinker utility. When these exe's are run under Wine, Wine will spin. A look at the +all debug messages shows that the app tries to write into its own code area in order to purposely throw an exception. Kind of like this: void my_function() { try { *(char *)&my_function = *(char *)&my_function; } catch (access violation) { } } Shrinker was written using Visual C++, since this article at MSJ (http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/exception/exce…) describes the code's exception handler perfectly. The Visual C++ exception handler, which gets control of the app from ntdll.dll, first calls a filter function corresponding to the catch clause to see if the handler associated with the catch will handle the exception. If so, it passes control to that handler. Otherwise it moves to the next catch clause. Here's the weird thing. The filter function looks at the code which called the exception handler, which is in ntdll.dll. Under Windows, this code is FFD1 (call ecx). The filter function compares that code to the call ecx instruction. At first the only difference between Wine and Windows is this comparison. A register gets decremented if the comparison fails. However, then the function calls ReadProcessMemory with a handle of -1 (what does that do?) to read 8 bytes, and compares some of the data returned to FFD1, and to 648B25 (which is the beginning of the next instruction after call ecx, mov esp,fs:[00000000]). Things rapidly deviate from there, resulting in Wine spinning and Windows continuing execution. Given that the application appears to look into ntdll.dll's code to compare it against essentially a magic number, is there any hope of getting Shrinkered exe's to run under Wine? --Rob

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 02:09 PM 16/12/2001 -0800, you wrote: >Gerard Patel wrote: >> I'd have no objection to Gpl *if* people having invested >> money in Wine success accept the move without problem.... > >I believe Gerard meant to write LGPL, not GPL. >There hasn't been any proposal to the the GPL on >wine, as far as I know. (The GPL might be too restrictive >IMHO.) Yes, correct. I said in my first post that from my (particular) point of view the licenses were similar. Gerard

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 11:35 AM 15/12/2001 -0800, you wrote: >I think that's quite unfair. I have stated that I personally don't >care about games, I don't have a single application that even uses >DirectX. The only reason I think DirectX is an issue is because I see >users complaining that Wine doesn't run their favorite game, and I >want Wine to be useful for as many people as possible. This has nothing to do with license, Transgaming or anything. All that is needed is a developer writing code. If there is none, nothing is written. Before Lionel Ulmer, there was no big DirectX game that could be played under Wine I think. Now Lionel is not contributing anymore - did he say to you privately that this was because of Transgaming ? There are many other top developers who have faded away like he did since I began on Wine, so it could be for many other reasons. Now, game users can as well subscribe to Transgaming as far as I am concerned. The vast majority of them seem to need professionnal - paid - support anyway. <snip> >> You want to use the Gpl as a tool, but I don't see a lot of respect >> for the philosophy that is behind it. > >I must say I'm quite offended by your comments. The only reason I >raise the issue is because I want Wine to remain as useful as possible >for everybody. <snip> you are the leader of this project since 8 years : the Gpl already existed when you began to work on Wine. You could have switched the license at any time. I don't remember you ever expressing any interest in Gpl for Wine since 3 years I am following - and I have read also quite a few of your interviews. Looking from the outside, this has more the appearances of a knee-jerk reaction, not the result of a long reflection. > What I find even more disturbing in what you said is the allusion >> (when replying to Patrick) to a future tightening of copyright laws, >> a tendency that is in my opinion directly linked to the idea of >> copyright, patents, etc being 'intellectual property' assets, >> and infringers thieves stealing them. You seemed to welcome >> the additional protection it would give Wine. > >Absolutely not, and I don't know how you got this impression. I'd love >for copyright law to get back to sanity, but I don't see this >happening in the near future. Yes, there are a lot of abuses done in >the name of intellectual property these days. Does this mean we have >to let people hurt us and do nothing? You seem to think that users >rights are important, but how are you going to defend their rights if >not by using the only tool that we have, namely copyright law? No, that not what I was saying. If I am here, that's because I think that having Win32 Api outside of Windows is important. User rights have never got in the figure, since it was always acknowledged that people could take the stuff and turn it proprietary. Now that someone seems to succeed, you want to change the rules. Transgaming is playing by the existing rules, the rules you have enforced for a long time. If they are hurting you, that's surprising. They are not hurting me, since I have accepted your rules. What you are planning will hurt Transgaming business plan, by spreading Fear, Uncertainty and Doubt in their business discussions with potential customers. Business plan that they did and implemented in good faith, perfectly conforming to your rules and expecting their stability. I'd have no objection to Gpl *if* people having invested money in Wine success accept the move without problem. I think you should feel more responsibility towards people investing in Wine, not only responsibility towards the project - in other words you, because you are the Wine project. <snip> >I'm not planning to send anybody to jail, and I find that suggestion >insulting. What you are planning I don't know but in this context Gpl seems more a weapon than anything else. What happens when weapons are drawn can be anything. <snip> > I do think that given the lack >of developers, discouraging even a few of the existing ones can cause >a lot of harm to the project. I think that you will discourage one. Gerard

3 2

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> The right patch attached this time. Rein. -- Rein Klazes This patch superceded my patch "Check WND structures before accessing", as it solved the problem with encarta99 startup Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: wine-devel digest, Vol 1 #584 - 10 msgs
by Roger Fujii 16 Dec '01

16 Dec '01

I tried to resist.... really..... "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Possibly, however remember that license may not always be for the > application - it is for the product, including any proprietary works not > GPL'ed, or support rights. It is also however true that the GPL'ed > portion of the code may have no other restrictions placed on it's use. other than the restrictions that the GPL imposes... > Going back to the user, how could a user who brought this infringing > product be benefited from the developer suing? Mostly, they may not. In > other cases, they benefit from the fact the code is again public, and they > have a far easier way to see about getting bugs fixed, etc.. the usual > benefits a good open-source project has. Here is a good counter-example. Sun Microsystems developed a toolkit that would convert linux network drivers source to function with Solaris (their proprietary OS). It was just a toolkit. They weren't distributing driver binaries. AFAIK, this use is perfectly legal to do with the GPL. What happens? The GPL GNUts get all bent out of shape because it allowed use of their drivers under a proprietary OS, so Sun yanked it, even though they were not in violation. As a *USER*, this is a negative impact placed on me by the linux developers to exercise my rights, since it impedes my ability to USE GPLed software. > > The usual argument about Gpl, that courts would not accept the > > action because there is no material interest (money) for Linus > > Torvalds, for example, in Linux, is akin to mine, but my point of > > view is not legalistic. > That's a load of bull, of course. A copyright has been violated.. it's > like with a trademark - if someone violates a trademark, the owner comes > very likely to forgoing his rights on that mark for not enforcing it. You are confusing copyrights and trademarks. A copyright is not invalidated due to lack of an active defense. A trademark would. > All I wanted was installshield support! :p All I want is for VirtualDub to work! :) "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > I feel rather dismayed by the whole discussion. > Maybe this is so because the way you approached the issue. > See, you are concerned with the semantics of things, the 'why', I think the better question is "what" as in what is trying to be accomplished? > centuries. Second, even suggesting that a LGPL Wine will the an evil > 'intelectual property' monster is ridiculous. Just a reminder, most open > source projects are (L)GPL and _that_ community is the only significant > force in today's society fighting against such things as software patents, > DCMA, SSSCA, etc. I would not equate the LPF with the FSF. They have very different agendas. > If we agree up to this point, what is the 'syntax' I was referring to? > Well, IMO this is a stronger Wine that keeps evolving and that has a life > of its own. Wether this is good or not for users it's irrelevant. You probably meant something other than what you wrote here. Existence for the sake of existence is useless. I would presume the point of wine is to provide a WINXX environment on top of x86 platforms. If M$ was sued into oblivion tomorrow, and Wine was a *perfect* 95/98/ME/XP emulator, there would be no need for future development (other than to port to new platforms). The point is that the end goal is to attempt to be the perfect emulator for the USER - not to keep wine going indefinitely. > Some may say yes, others (e.g. Microsoft) may say no. I submit that we that this > goal as axiomatic and we go from there. > > Now, I can argue that this very axiom eliminates any sort of proprietary > licence, but I will not do it since it's understood by everybody here. I > will just look at the two possible options: BSD vs. LGPL. There are two > points in my axiom: > 1. we should try to make Wine stronger (e.g. evolve faster) > 2. Wine should have a life of it's own > > Let's look at the first part: make Wine evolve faster. > LGPL > pros: > -- _far_ bigger code base for sharing/reuse and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL. > -- _far_ bigger developer base Can you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD? > -cons: > -- we may lose developers that are opposed philosophically to the > GPL ideals > -- less commercial freedom when using the code base Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences. It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation". I can also add a few more cons: -- FSF discourages use of LGPL -- Discourages commercial companies for its use/development. -- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL. > BSD > (just negate the above) > > And now for the second part: Wine should have a life of its own. This is, > to my mind, the crucial part. The problem with a BSD licence is that it > does not ensure that. and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying. > The cool and amazing thing about the (L)GPL is that > it puts in place the right feedback loop (or vicious circle if you > will) that ensures a project a life of its own independent of who's > developing and maintaining it: the bigger the project becomes, the more > people will use it, (up to now BSD and GPL are the same), the more people > will contribute to it, the bigger the project becomes!!! It's the > equivalent for the 'rich get richer', but the currency is not money but > usefulness/code. It is simple, yet brilliant. This is an artifact of "open software". GPL is a *part* of open software - it is not the definition of open software. I don't believe anyone here is advocating making wine non-open. The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free". As a side question, what IS the difference between what's available on winehq vs codeweavers? -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

4 4

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> hi, My application, girotel v 2.1, crashes during the creating of Rein> its first windows when calling the CBT hooks in Rein> --- ./wine/windows/win.c Wed Sep 29 17:14:39 1999 Rein> +++ ./mywine/windows/win.c Tue Oct 12 20:24:27 1999 Rein, are you sure this is the right patch? It seems from 1999... I want it test the patch if it supercedes my recent get_whole_window patch... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Even according to a strict interpretation of the LGPL > > they would just have to provide their code in seperate > > files so everything could be relinked when new versions > > of Wine was released. > > It seems you really don't understand the LGPL. Modifications made to a > library released under the LGPL are a derivative work of this library, > and have to be LGPL no matter if they are in separate files or > not. Saying the ALL modifications gives rise to a derived works even if distributed seperately is a ridiculous proposition that is the main problem with (L)GPL. As I have been trying to explain is that the courts are unlikely to support this, at least not 100%. The question is where is borderline is. At the extreme end the courts might totaly reject the doctrine of derived work in favour of the doctrine of combined work what I have been talking about in previous mails. If somebody (A) only provide drop in files that replaces some functions say the Crypto API in ADVAPI32, they are not any combined work since they are 100% written by A. Sure the application/library as a whole is of course a combined work, but that doesn't matter if you do not distribute it as a whole. > This is the standard interpretation that just about anybody > except you agrees with. If you think everybody agrees what a derived work is you are badly mistaken. Even Richard Stallman himself admit that the power of (L)GPL is dependent on how far the courts will allow the doctrine of derived work. Note that I do not pretend to know how the courts will rule. But I do know that sticking the head in the sand and pretending that (L)GPL doesn't have large potential holes in it is quite naive and potentially dangerous.

3 2

Decision process on possible switch to LGPL
by Roger Fujii 16 Dec '01

16 Dec '01

Dan Kegel <dank(a)kegel.com> wrote: > > Who has to decide what in order for the Wine project > to switch to the LGPL? I believe the process involves all prior contributors allowing this, or have the non-LGPL code rewritten and that work be LGPLed. Pending on the number of authors, the effort can be non-trivial. Look at the license change discussions for mozilla and kde if you want to get the grasp of what is required. > Could it be as simple as the wine cvs tree accepting LGPL'd contributions > along with old-license contributions? Not if you want a "pure" LGPL distribution. > Or need one go so far as requiring all new contributions to the cvs > tree be under the LGPL? even further. > Would a valid way of voting be to open up a new cvs tree that > accepted only LGPL contributions, and giving maintainers the > choice of which tree (or both) to submit to? That would > within not too long show how contributors felt. This is going to encourage more development... NOT. What you definitely don't want is confusion over what license is being used. Unless you make a stipulation that the final license chosen will automatically convert the other license, it would just be a mess as you then will have 2 source trees which you have to go back and reconcile. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 1

OSS stuff
by Duane Clark 16 Dec '01

16 Dec '01

The recent OSS stuff is working pretty good. I have one area, where one sound clip stops and the next starts, that sometimes has problems. Sometimes the second clip runs normally, and sometimes there is just a brief bit of the very beginning of the second clip. I think this is where the problem is. The difference I see is that when it breaks, some wodNotifyClient msgs are received before the wodGetPosition messages are set to valid values for the new clip. When it works, those values get set before the wodNotifyClient msgs. Then again, I really don't understand what is going on. A trace from when it fails: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-1226 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=4294966070 trace:wave:wodGetPosition TIME_SAMPLES=134217421 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=742 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=742 trace:wave:wodGetPosition TIME_SAMPLES=185 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=3/16, fragsize=1024, bytes=2694 trace:wave:wodPlayer waiting 110ms (110,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=2694 trace:wave:wodGetPosition TIME_SAMPLES=673 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=5/16, fragsize=1024, bytes=4648 trace:wave:wodPlayer waiting 88ms (88,4294967295) It continues this way until the DSP buffer is empty, and nothing further is written to it. Here is when it works: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=78 trace:wave:wodGetPosition TIME_SAMPLES=19 trace:wave:OSS_wodMessage (0, 0009, 0000001C, 4290CE74, 00000020); trace:wave:wodWrite (0, 0x4290ce74, 00000020); trace:wave:wodWrite imhere[3-HEADER] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_HEADER 4290ce74 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=108 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 108 dwLength 4096 available space was 108 trace:wave:wodPlayer waiting 45ms (132,45) trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-990 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=2/16, fragsize=1024, bytes=928 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.108[4096] trace:wave:wodPlayer_WriteMaxFrags Written 928 dwLength 3988 available space was 928 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200

1 0

Adding protections in map_image
by Robert Baruch 16 Dec '01

16 Dec '01

Hi all, Uwe and I have been working on several executables which have been compressed by Shrinker. Basically, under win98 it tries to load a VXD which is disallowed. The prospects are better under nt40 mode, but it looks like Shrinker purposely causes read and write exceptions. After looking at this for a little over a week, I've found that there are two problems which need to be solved. The first is that the exception handler installed by Shrinker under Wine causes another fault and then a spin. Under WinDbg (in W2K/VMWare) the exception handler does not cause another fault, and execution continues nicely. The second is that WinDbg finds a write fault where Wine does not. To fix this, Wine must set protections on the executable's image map. I came up with a patch to do this, and it worked for my Shrinkered exe, but not for Uwe's. Uwe's exe loads MSVCRT20.DLL, and then Wine calls PE_fixup_imports, which attempts to write to that DLL's .idata section, which had been set read-only. Clearly Wine needs to write to that section to set up imports which haven't been implemented. Now, my patch put the protections on the mapped image right at the end of map_image. This works when map_image is called (eventually) from PROCESS_InitWine, so that the initial executable gets its protections set right. However, it doesn't work for PE_LoadLibraryExA (called by LoadLibraryExA) because it first checks to see if the library has already been loaded. If it has been loaded, it calls PE_fixup_imports. If it has not been loaded, it calls (eventually) map_image. So if the library has already been loaded, it has already had its protections set up by map_image at some point in the past. Then when PE_fixup_imports is called, a protection violation occurs. My current idea is to go into PE_fixup_imports, unprotect the .idata section, do the fixups, and reprotect the section. The bad thing is that if someone else in the future writes some code that does additional fixups to other sections, they are also going to have to unprotect and reprotect. This might turn out to be a good thing, though, if it forces you to do that. What does everyone think? Thanks, --Rob

2 6

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> > Note that I do not pretend to know how the courts will rule. > > But I do know that sticking the head in the sand and pretending > > that (L)GPL doesn't have large potential holes in it is quite > > naive and potentially dangerous. > > Then if the LGPL holes are dangerous, the X11 license should be even > more dangerous; after all it's a much larger hole than the LGPL will > ever have. I still don't understand where you are trying to go with > your argument. Sure it has a larger hole. But at least it is obvious that is does. It doesn't make you believe good things will happend. The point is that you seem to wish some things to happend and I point out that LGPL provides not guarentee that it will actually will happend despite that LGPL at a quick glance looks like it in some meaning forces what you wish to happend. One the other hand the LGPL might scare away potential companies wishing to extend Wine. See below. > No, of course the LGPL doesn't provide absolute protection; nothing > does, and I don't think absolute protection is desirable either. There > are some things that the LGPL clearly allows, some that it clearly > forbids, and a number of border cases, that frankly are only > interesting to people who want to try to get around the license > restrictions. And what would be the point of doing that? Making their business model work. Trying to ensure investment return. > If the > license is not acceptable to someone, they don't have to use the > code. Who would risk bad PR and potential lawsuits just to prove that > they can find a loophole in the LGPL? So we lose some possible companies willing to help in two step. 1. Because they do not dare 2. Because you (or somebody else) sue them Great idea. NOT. > You really make it sound like the LGPL is some kind of unexplored > wilderness that we shouldn't venture into. We are not a normal software project and thus what really is a derived work when faced with a lot unimplemented stuff are much more difficult to know. I have tried to show that LGPL in itself is pretty weak and are likely to be even weaker then faced with Wine's special circumstances. > The fact is that a large > majority of free software projects use either the GPL or the LGPL, and > in practice it works just fine for them, just as I'm confident it > would work just fine for us. Normal software project doesn't have any large design with a lot of not yet implemented functions, there it makes sense for some company to say: Hey I could provide an implementation of this special part under this special business model. Face it we are not a normal software project and the arguments they used for chosing (L)GPL are not really relevant here. Note that I'm not denying that convincing arguements for choosing LGPL might exists, but reference to earlier success is not one of them. Your argument that LGPL forces good things to happend is not entirely convincing either for reasons stated earlier. The current license is something that is easy to understand and are unlikely to scare companies like Transgaming away, but can you really say the say same about LGPL?

2 1

Decision process on possible switch to LGPL
by Dan Kegel 15 Dec '01

15 Dec '01

Who has to decide what in order for the Wine project to switch to the LGPL? Could it be as simple as the wine cvs tree accepting LGPL'd contributions along with old-license contributions? Or need one go so far as requiring all new contributions to the cvs tree be under the LGPL? Would a valid way of voting be to open up a new cvs tree that accepted only LGPL contributions, and giving maintainers the choice of which tree (or both) to submit to? That would within not too long show how contributors felt. - Dan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel