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

Regression tests, UNICODE vs ASCII

by Geoffrey Hausheer

So I've finally started writing tests for functions that have both Unicode and Ascii equivalents, and I'm wondering how to write the tests. I re-read the thread about this that occurred back in January, and there didn't seem to be a clear decision. With the current framework, it doesn't appear to be possible to just write one test, and have it build both unicode and ascii versions, and it seems like at least Alexandre was strongly against this anyway. But in my case, I know nothing at all about writing Unicode tests, or how to explicitly test unicode functionality, so I see that I have three options: 1) Don't write any 'W' tests, and use only 'A' functions in my tests 2) Duplicate my 'A' tests as 'W' tests, and acknowledge that there is likely Unicode specific stuff that is not tested 3) Learn something about Unicode, and figure out how to test the functions correctly. Now obvioulsy (3) is the best choice, but honestly, I am not motivated towards this at the moment. Which leaves (1) and (2), with (2) being the way I'm leaning. But the tests are getting really big, and pretty messy, and duplicating them and managing both versions looks like a nightmare (there are lots of TODOs, and I expect the tests to behave differently on different OS). So what is the recomendation that I do? In the simplest case, I can just copy the Ascii test to a new file and replace all 'A' with 'W', and just keep the tests seperated that way. Anyhow, any comments would be appreciated. Thanks, .Geoff

April 6, 2002

Re: wine/objects text.c

by Dmitry Timoshkov

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > Yup, this is what Word 2000 uses to get the 'Outline' effect you can > select in Format->Font. Wine doesn't implement it yet hence the > FIXME. It would essentially mean writing another ExtTextOut clone > that gets the outlines of the glyphs and adds them to the path, as > well as doing all the other stuff that ExtTextOut does. But I think that patch is too harsh, since it doesn't allow normal ExtTextOut functionality to at least provide minimal replacement for the not implemented case: just print FIXME and proceed with normal ExtTextOut implementation. -- Dmitry.

April 6, 2002

Re: wine/objects text.c

by Huw D M Davies

On Sat, Apr 06, 2002 at 11:51:12AM +0900, Dmitry Timoshkov wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > > On April 5, 2002 07:37 pm, Alexandre Julliard wrote: > > > Log message: > > > Huw D M Davies <hdavies(a)codeweavers.com> > > > Spout a FIXME if we try to call ExtTextOut on an open path. > > > > FIXME what? Is there some unimplemented functionality, or is it just illegal > > to call ExtTextOut on an open path? > > It's completely legal to do: > > BeginPath(hDC); > ExtTextOut(hDC, ...); > EndPath(hDC); > StrokePath(hDC); > > to get an outlined text output. Yup, this is what Word 2000 uses to get the 'Outline' effect you can select in Format->Font. Wine doesn't implement it yet hence the FIXME. It would essentially mean writing another ExtTextOut clone that gets the outlines of the glyphs and adds them to the path, as well as doing all the other stuff that ExtTextOut does. Huw.

April 6, 2002

Re: [PATCH] HOMAM III fix

by Geoffrey Hausheer

On Friday 05 April 2002 13:56, Francois Gouget wrote: > On Fri, 5 Apr 2002, Andreas Mohr wrote: > [...] > > > Are you sure that simply completely removing code doesn't break anything > > here in other cases ? > > The only way to handle that is to write a regression test involving > GetFullPathName and a couple other related functions (like > GetLongPathName (buggy) and GetShortPathName). > > Then we can check the behavior in Windows. If someone writes such a > test I will run it on Win95, Win98, NT4 and WinXP and we will finally > know. I have some code I did a week ago to test file and path functions. I've really barely begun (there are a LOT of path/file functions to test), but if it would be useful, I can clean up what I've got so far and post it here. I have preliminary tests for the three functions you mention above (only ANSI so far) though. Or if it is not so important, you can wait until I've actually finished all the tests I plan to do, which will probably be sometime next week. .Geoff

April 6, 2002

Re: wine/objects text.c

by Dmitry Timoshkov

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On April 5, 2002 07:37 pm, Alexandre Julliard wrote: > > Log message: > > Huw D M Davies <hdavies(a)codeweavers.com> > > Spout a FIXME if we try to call ExtTextOut on an open path. > > FIXME what? Is there some unimplemented functionality, or is it just illegal > to call ExtTextOut on an open path? It's completely legal to do: BeginPath(hDC); ExtTextOut(hDC, ...); EndPath(hDC); StrokePath(hDC); to get an outlined text output. -- Dmitry.

April 6, 2002

Re: wine/objects text.c

by Dimitrie O. Paun

On April 5, 2002 07:37 pm, Alexandre Julliard wrote: > Log message: > Huw D M Davies <hdavies(a)codeweavers.com> > Spout a FIXME if we try to call ExtTextOut on an open path. FIXME what? Is there some unimplemented functionality, or is it just illegal to call ExtTextOut on an open path? -- Dimi.

April 6, 2002

Re: [PATCH] async IO API, reworked

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > Purpose: Modified API for asynchronous IO requests. > > - separate cleanly between async scheduling and file IO related issues, > - make the API compatible with other types of async requests (e.g. for sockets), > - remove exports of async IO related functions for DLL separation. You cannot add private headers to work around the dll separation restrictions, this only hides the dependencies between dlls it doesn't solve them... I have applied the patch for now, but the async.h file will have to go away eventually (or the functionality will need to be "officially" exported from ntdll). -- Alexandre Julliard julliard(a)winehq.com

April 5, 2002

Newbie developer looking for pointers (re printing)

by Carl Sopchak

I've decided to try to fix a problem myself that I'm having printing from QuickBooks (partial page checks need to be landscape). I've downloaded the source, updated it via CVS, and now I'm trying to figure out where the problem is. I know where the problem is at the moment: ME! :-) That is, I could use some pointers on where to look... I have no knowledge of the Win API, and I can't say that I'm a strong C programmer (although I've played with it for a while a few years ago). However, being a consultant for over 15 years, I've jumped into more difficult situations and got results in a reasonable period of time. With a few helpful pointers, I don't think this should be any different. :-) I've looked around MSDN for a while, searching for printing API info with no luck (perhaps it's a lack of patients, perhaps its a poor search enging on top of a huge mass of information). I've looked at the Wine source, have successfully watched my program trace through wineps.c (et al), and even made a slight mod to it to make sure that I would know that I was running modified code (which worked). I've also looked around winehq and codeweavers, in the wine developer's sections... Here's where my head's at: It seems to me that I'm "too low" looking at wineps.c, but I can't figure out where else to look. Using the cross reference on winehq, and looking at the "where used" for wineps.c, the trail "goes cold" after a level or two (still "too low"). I know the app is making the proper calls to the Win Printing API to set landscape mode when needed since the program works fine on an NT box. I just don't know WHAT gets called to do this! If I started there, I could trace down to whatever levels I need to to figure out what is currently going on, so I can figure out what needs to be changed... So here are my questions: - What APIs are called by programs to talk to the printing subsystem? Is there a MS URL that gives an overview of this API? - What --debugmsg options can I use to trace programs through these API calls? (+psdrv works for the routines in wineps/*.c; +gdi [am I on the right track?] seems to give a whole bunch of traces, none of which [well, maybe a few] seem relavent.) - What calls the PSDRV_ functions? What's the --debugmsg option for it? - Is anyone willing to Mentor me?? (VERY big grin; flash the long eyelashes; etc.) I'd love to get this to work, and I'd be more than happy to supply the patch once it is working. I'm also be willing to continue working on the printing in wine, and perhaps fix other bugs that I run across. But in order for this to become reality, I sure could use some help up the learning curve!! Humble thanks, Carl

April 5, 2002

Re: [PATCH] HOMAM III fix

by Martin Lexa

* Enrico Horn (farmboy1(a)subdimension.com) wrote: > That is understandable. > it seems that HoMM3 assumes C:\Program Files\3DO\Heroes3 or wherever it > was installed in as current path and wont check that it really is so. > the GetFullPathNameA call with the relative path .\\DATA\\ > will of course fail when this assumption isnt true. > One solution could be to start the exe in path that it resides in but > this might cause problems with other apps and is really not the right thing to > do. > I would assume that HoMM3 would fail on windows too if called like this, any > one who can confirm this? When I've Windows installed I played this game and everything works ok for me. Yes, it was the same copy, which I'now trying to use under Wine. > Enrico > farmboy1(a)subdimension.com Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Martin Lexa

* Martin Lexa (mlexa(a)iol.cz) wrote: > wine --debugmsg +all 'C:\Program Files\3DO\Heroes3\HEROES3.EXE' > > Debug output: > > . > . > . > > 0806fa00:trace:reg:NtQueryValueKey (0x58,L"AppPath",2,0x40896ab4,256) > 0806fa00: get_key_value( hkey=88, name=L"AppPath" ) Get key \\Machine\\Software\\New World Computing\\Heroes of Might and Magic\xae III\\1.0 value "AppPath"="C:\\Program Files\\3DO\\" > 0806fa00: get_key_value() = 0 { type=1, total=44, data={43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,33,00,44,00,4f,00,5c,00,00,00} } > . > . > . Things, getting better and better... Please, look at the value of AppPath reg! I think it should be C:\\Program Files\\3DO\\HEROES3\\ not C:\\Program Files\\3DO\\. I run regedit and look at that value and yes, everytime I run wine with this game the reg AppPath will change to the actual path where I ran wine from. If I, for example run wine from C:\Program Files\3DO\HEROES3 directory the value of AppPath reg change to C:\\Program Files\\3DO\\HEROES3\\. I verified it with regedit. I think it's a bug or am I wrong? May be it's a Wine's feature ;) ? Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Martin Lexa

* Andreas Mohr (andi(a)rhlx01.fht-esslingen.de) wrote: > Actually GetFullPathName was known to have some trailing \\ issue. > So this had to be fixed somehow. > It just astonished me a bit to see some code part completely removed > instead of a "real" fix. > But he said that he can't think of any occasion where it breaks, > so it might be ok. And there is another strange thing... HOMAM III is installed in C:\Program Files\3DO\Heroes3 directory. If I run wine from this directory with HEROES3.EXE as parameter everything works ok, of course, after "fix". However, if I run wine from, for example C:\Program Files\3D0 directory, it gave me error "Unable to initialize resources - ...". wine --debugmsg +all 'C:\Program Files\3DO\Heroes3\HEROES3.EXE' Debug output: . . . 0806fa00:trace:reg:NtQueryValueKey (0x58,L"AppPath",2,0x40896ab4,256) 0806fa00: get_key_value( hkey=88, name=L"AppPath" ) Get key \\Machine\\Software\\New World Computing\\Heroes of Might and Magic\xae III\\1.0 value "AppPath"="C:\\Program Files\\3DO\\" 0806fa00: get_key_value() = 0 { type=1, total=44, data={43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,33,00,44,00,4f,00,5c,00,00,00} } . . . Call kernel32.GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,40896cac,40896c9c) ret=00599630 trace:dosfs:DOSFS_GetFullName . (last=0) trace:string:lstrcpynA (0x40896398, "/opt/c", 1024) trace:string:lstrcpynA (0x4089639f, "Program Files/3DO", 1017) trace:string:lstrcpynA (0x4089679b, "PROG~FBU\\3DO", 1021) trace:dosfs:DOSFS_GetFullName returning /opt/c/Program Files/3DO = C:\PROG~FBU\3DO trace:string:lstrcpynA (0x4089679a, "/Program Files/3DO", 1021) 0806fa00:trace:string:lstrcpynA (0x408967ad, ".\\DATA\\", 1003) 0806fa00:trace:dosfs:DOSFS_DoGetFullPathName got C:\Program Files\3DO\DATA\ 0806fa00:trace:string:lstrcpynA (0x40896cac, "C:\\Program Files\\3DO\\DATA\\", 260) 0806fa00:trace:dosfs:DOSFS_DoGetFullPathName returning 'C:\Program Files\3DO\DATA\' . . . Look at the final path, it's WRONG. It should be 'C:\Program Files\3DO\HEROES3\DATA\'. If I run wine from directory 'C:\Program Files' the final path is even worse -> 'C:\Program Files\DATA\'. And yes, same happen if try it without my fix - except that last backslash. What's going on here? I don't understand this. Looks like black magic to me ;) Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Francois Gouget

On Fri, 5 Apr 2002, Andreas Mohr wrote: [...] > Are you sure that simply completely removing code doesn't break anything > here in other cases ? The only way to handle that is to write a regression test involving GetFullPathName and a couple other related functions (like GetLongPathName (buggy) and GetShortPathName). Then we can check the behavior in Windows. If someone writes such a test I will run it on Win95, Win98, NT4 and WinXP and we will finally know. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

April 5, 2002

Re: [PATCH] HOMAM III fix

by Andreas Mohr

On Fri, Apr 05, 2002 at 01:16:11PM -0500, Vincent Béron wrote: > Enrico Horn a écrit : > > > > Hi > > > > On Friday 05 April 2002 19:06, Andreas Mohr wrote: > > > On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > > > > Hello! > > > > > > > > Function CreateFileA get this file path (just for example): > > > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > > > > > > > As you can see the correct path should be: > > > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > > > > > > > This lead to error message "Can't initialize resources.Possible disk > > > > problem." > > > > > > > > I see the problem in the function DOSFS_DoGetFullPathName(), which in > > > > the end removes the ending backslash from the path. The attached patch > > > > fixes it. > > > > > > > > Bye, Martin > > > > > > > > > > Yep, that might fix *your* problem, but don't you think that code snippet > > > might have been there for a purpose ? > > > > > To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" > > I sent to this list more than a week ago. Until now no real answer has been > > given. > > > Are you sure that simply completely removing code doesn't break anything > > > here in other cases ? > > I cant think of any situation where this might be needed. > > I may be wrong though. > > Yet so far I have no explanation for this piece of code and > > removing it seems to work fine. > > > > Enrico > > farmboy1(a)subdimension.com > > I tracked it to a patch by Uwe Bonnes, around the 2000/04/28. It brought > the dos_fs.c revision from 1.46 to 1.47. The CVS comment is: > "DOSFS_DoGetFullPathName: rewrite to return resulta like OSR2". > > Have you tried to run HOMAM III under OSR2? Or even just a call to the > proper Win32 API? > It might be just some different behaviours under different Windows > falvours... > > As to which of the two is what we want, I can't help you on that. Actually GetFullPathName was known to have some trailing \\ issue. So this had to be fixed somehow. It just astonished me a bit to see some code part completely removed instead of a "real" fix. But he said that he can't think of any occasion where it breaks, so it might be ok. Probably a candidate for regression testing, though ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 5, 2002

Re: [PATCH] HOMAM III fix

by Martin Lexa

Hi! * Andreas Mohr (andi(a)rhlx01.fht-esslingen.de) wrote: > Yep, that might fix *your* problem, but don't you think that code snippet > might have been there for a purpose ? > > Are you sure that simply completely removing code doesn't break anything > here in other cases ? Same thing came to my mind too. The only "thing" it breaks is the value of lastpart parameter. However, should somebody tell me what is the REAL purpose of the lastpart parameter, please? I don't see any, because it only returns value if the return path has no ending backslash. If ending backslash will not be present the error will came up again... There is not much room for fixing it elsewhere, because after end of GetFullPathNameA function, which call DOSFS_DoGetFullPathName, the function CreateFileA is called with "wrong" filename value, as I described in my previous e-mail. Bye, Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Vincent Béron

Enrico Horn a écrit : > > Hi > > On Friday 05 April 2002 19:06, Andreas Mohr wrote: > > On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > > > Hello! > > > > > > Function CreateFileA get this file path (just for example): > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > > > > > As you can see the correct path should be: > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > > > > > This lead to error message "Can't initialize resources.Possible disk > > > problem." > > > > > > I see the problem in the function DOSFS_DoGetFullPathName(), which in > > > the end removes the ending backslash from the path. The attached patch > > > fixes it. > > > > > > Bye, Martin > > > > > > > Yep, that might fix *your* problem, but don't you think that code snippet > > might have been there for a purpose ? > > > To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" > I sent to this list more than a week ago. Until now no real answer has been > given. > > Are you sure that simply completely removing code doesn't break anything > > here in other cases ? > I cant think of any situation where this might be needed. > I may be wrong though. > Yet so far I have no explanation for this piece of code and > removing it seems to work fine. > > Enrico > farmboy1(a)subdimension.com I tracked it to a patch by Uwe Bonnes, around the 2000/04/28. It brought the dos_fs.c revision from 1.46 to 1.47. The CVS comment is: "DOSFS_DoGetFullPathName: rewrite to return resulta like OSR2". Have you tried to run HOMAM III under OSR2? Or even just a call to the proper Win32 API? It might be just some different behaviours under different Windows falvours... As to which of the two is what we want, I can't help you on that. Bye, Vincent

April 5, 2002

Re: Removed sorting of registry key values

by Andriy Palamarchuk

Paul Millar wrote: > On Wed, 3 Apr 2002, Andriy Palamarchuk wrote: > >>The tests show that values are exported in the same >>order in which they are created. This means the values >>are stored not in any particular order. > > > That doesn't necessarily follow ... > > The export function(s) could map the sorted registry back into its > original order. At the cost of sizeof( void *) bytes per registry entry > (perhaps less, I haven't looked too closely at the registry code), you > could have the registry keys sorted (for fast access) and export back into > the original order in O(n) > > Is it worth the memory for that level of compatibility? All of you guys, thank you for the feedback. I had a doubt before submitting the patch. Andriy Palamarchuk

April 5, 2002

Re: [PATCH] HOMAM III fix

by Andreas Mohr

On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > Hello! > > Function CreateFileA get this file path (just for example): > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > As you can see the correct path should be: > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > This lead to error message "Can't initialize resources.Possible disk > problem." > > I see the problem in the function DOSFS_DoGetFullPathName(), which in the > end removes the ending backslash from the path. The attached patch fixes it. > > Bye, Martin > Index: dos_fs.c > =================================================================== > RCS file: /home/wine/wine/files/dos_fs.c,v > retrieving revision 1.103 > diff -u -u -r1.103 dos_fs.c > --- dos_fs.c 2 Apr 2002 02:46:27 -0000 1.103 > +++ dos_fs.c 5 Apr 2002 16:24:19 -0000 > @@ -1341,9 +1341,6 @@ > } > if (full_name.short_name[namelen-1]=='.') > full_name.short_name[(namelen--)-1] =0; > - if (!driveletter) > - if (full_name.short_name[namelen-1]=='\\') > - full_name.short_name[(namelen--)-1] =0; > TRACE("got %s\n",full_name.short_name); > > /* If the lpBuffer buffer is too small, the return value is the Yep, that might fix *your* problem, but don't you think that code snippet might have been there for a purpose ? Are you sure that simply completely removing code doesn't break anything here in other cases ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 5, 2002

[PATCH] HOMAM III fix

by Martin Lexa

Hello! Function CreateFileA get this file path (just for example): C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod As you can see the correct path should be: C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod This lead to error message "Can't initialize resources.Possible disk problem." I see the problem in the function DOSFS_DoGetFullPathName(), which in the end removes the ending backslash from the path. The attached patch fixes it. Bye, Martin

April 5, 2002

Re: SetCooperativeLevel

by Tels

-----BEGIN PGP SIGNED MESSAGE----- Moin, On 05-Apr-02 Jason Phillips carved into stone: > > > Well first are you confusing Transmeta with Transgaming? Transmeta is the Yes. Sorry, s/transmeta/transgaming/g; And transgaming has their own mailing list, and their own CVS, which I already synced and build (I don't know if it contains all source code parts, though, but I suppose yes - AFAIU transgaming gives you anything, you just redistribute it commercially - or something along these lines) [snip the rest] Cheers, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' greatly extend B2B architectures -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPK2/IXcLPEOTuEwVAQGsgQf+I97ziYy4ZbYODW7dkSNjXPp0nAg/jKlj q4rCBhcvV1adFbNZ7JBGZJrkHVKZjiLLq99kK244iE+SQXKBG6kr9zIWbd9iCYSB gXwdqc4lf8mmVKiZz+EEtV5hCT1Dyst+hY9fxAYBYso1ZjXD/wz59Ds8YE9oLEOe y5sHzbzzXFsyLfRb7EWDwgXLB3TTRx0LPsHKLrzyn4k+7NMTimx8F2zFY5bhWqOW huvcDZ0vF3ldh1XuGl13t/fN8kqRpQfdHe/8RgXEXM1g/j9490zPVpFFZ67LY8ZE RkxVd6IWOFaVlGDmuCz04hPoeBQqg51hzTSga0aNw6R/GDFI9tdMnQ== =F3SZ -----END PGP SIGNATURE-----

April 5, 2002

Re: [PATCH] async IO API, reworked

by Dimitrie O. Paun

On April 5, 2002 06:32 am, Martin Wilck wrote: > Added files: > include : async.h (structs and inline functions for ^^^^^^^ Shouldn't this file be added to include/wine dir, as it seems to be an internal Wine header. -- Dimi.

April 5, 2002

Re: Crossover/WINE Test In Large Rollout

by Dave Hawkes

Hi Dave, see comments below From: "Dave Richards" <drichard(a)largo.com> Subject: Crossover/WINE Test In Large Rollout > All- > ... > Here are the problems--> > > 1) Endian Bug. WINE is not able to detect that the runtime Endian > order might be different than the server. Our Xterminals are RISC based > and obviously WINE is running on Intel. All of the colors display > incorrectly because of this. This is probably straightforward to fix for a developer who has access to that type of Xterminal, although I don't know exactly where the problem lies. > > 2) Performance. On remote displays WINE is *much* slower than it is on > the console. The Lotus Notes client took over 5 minutes to run remotely > whereas on the console it comes up in about 20 seconds. I am assuming > that it is making use of some of the XFree extensions for performance > and that perhaps they have to timeout and drop through code in order to > run on our Xservers. Once it is running, performance is much better, > but the initial startup make it undeployable. This is more difficult and is usually worse on apps that make use of lots of window handles in their UI. I have attached a patch which can sometimes make a factor of 10 difference in this scenario. Another solution (to both problems) we have used is to use VNC as the Xserver, (which is effectively local) reducing the round trip problem. If you are using Xterminals you could run the VNC client on the application server you are connecting to (ie VNC client/server on the same machine) and use an Xsession just running the client connected to the VNC server running wine. Another advantage here is that the VNC java client can be used in a regular browser session so you don't necessarily need an Xterminal even. I'm not sure that I explained that very well, but if you want more details email me privately and I can explain some more. Dave Hawkes Cadlink Technology

April 5, 2002

Re: [PATCH] HOMAM III fix

by Enrico Horn

Hi, On Friday 05 April 2002 21:58, Martin Lexa wrote: > * Andreas Mohr (andi(a)rhlx01.fht-esslingen.de) wrote: > > Actually GetFullPathName was known to have some trailing \\ issue. > > So this had to be fixed somehow. > > It just astonished me a bit to see some code part completely removed > > instead of a "real" fix. > > But he said that he can't think of any occasion where it breaks, > > so it might be ok. > > And there is another strange thing... > HOMAM III is installed in C:\Program Files\3DO\Heroes3 directory. If > I run wine from this directory with HEROES3.EXE as parameter everything > works ok, of course, after "fix". However, if I run wine from, for > example C:\Program Files\3D0 directory, it gave me error "Unable to > initialize resources - ...". > > wine --debugmsg +all 'C:\Program Files\3DO\Heroes3\HEROES3.EXE' > [Debug output snipped] > Look at the final path, it's WRONG. It should be 'C:\Program > Files\3DO\HEROES3\DATA\'. If I run wine from directory 'C:\Program Files' > the final path is even worse -> 'C:\Program Files\DATA\'. > And yes, same happen if try it without my fix - except that last > backslash. > What's going on here? I don't understand this. Looks like black magic > to me ;) > That is understandable. it seems that HoMM3 assumes C:\Program Files\3DO\Heroes3 or wherever it was installed in as current path and wont check that it really is so. the GetFullPathNameA call with the relative path .\\DATA\\ will of course fail when this assumption isnt true. One solution could be to start the exe in path that it resides in but this might cause problems with other apps and is really not the right thing to do. I would assume that HoMM3 would fail on windows too if called like this, any one who can confirm this? Enrico farmboy1(a)subdimension.com

April 5, 2002

[PATCH] async IO API, reworked

by Martin Wilck

Hi, Here is a reworked version of the async API patch which I hope is now ready for being applied. Details see below. Regards, Martin PATCH: async-struct.diff Purpose: Modified API for asynchronous IO requests. - separate cleanly between async scheduling and file IO related issues, - make the API compatible with other types of async requests (e.g. for sockets), - remove exports of async IO related functions for DLL separation. ** This patch OBSOLETES these two patches I submitted: ** http://www.winehq.com/hypermail/wine-patches/2002/04/0020.html http://www.winehq.com/hypermail/wine-patches/2002/04/0034.html Note: the cancel_async server request that was in the previous patch (0020.html) was removed (unnecessary). Patch against: Wine CVS 2002/04/05 Test status: Compiles (no errors/warnings). Tested regular file async IO with ReadFile and ReadFileEx (ok). Added files: include : async.h (structs and inline functions for async requests) Modified files: server : protocol.def (add APC type APC_ASYNC_IO, remove func element of register_async request) async.h (remove func element in async struct) async.c (remove references to func element in async struct) thread.c (allow NULL function pointer for APC_ASYNC_IO requests) dlls/kernel : comm.c (use modified API) files : file.c (use modified API) include : file.h (move async stuff to async.h) scheduler : synchro.c (remove functions now inlined through async.h, call_apcs() calls check_async_list() for APC_ASYNC_IO APCs) diff -ruNX ignore CVS/wine/dlls/kernel/comm.c TMP/wine/dlls/kernel/comm.c --- CVS/wine/dlls/kernel/comm.c Wed Apr 3 19:32:56 2002 +++ TMP/wine/dlls/kernel/comm.c Fri Apr 5 11:19:40 2002 @@ -91,6 +91,53 @@ WINE_DEFAULT_DEBUG_CHANNEL(comm); +/*********************************************************************** + * Asynchronous I/O for asynchronous wait requests * + */ +#include "async.h" + +static DWORD commio_get_async_status (const async_private *ovp); +static DWORD commio_get_async_count (const async_private *ovp); +static void commio_set_async_status (async_private *ovp, const DWORD status); +static void CALLBACK commio_call_completion_func (ULONG_PTR data); + +static async_ops commio_async_ops = +{ + commio_get_async_status, /* get_status */ + commio_set_async_status, /* set_status */ + commio_get_async_count, /* get_count */ + commio_call_completion_func /* call_completion */ +}; + +typedef struct async_commio +{ + struct async_private async; + LPOVERLAPPED lpOverlapped; + char *buffer; +} async_commio; + +static DWORD commio_get_async_status (const struct async_private *ovp) +{ + return ((async_commio*) ovp)->lpOverlapped->Internal; +} + +static void commio_set_async_status (async_private *ovp, const DWORD status) +{ + ((async_commio*) ovp)->lpOverlapped->Internal = status; +} + +static DWORD commio_get_async_count (const struct async_private *ovp) +{ + return 0; +} + +static void CALLBACK commio_call_completion_func (ULONG_PTR data) +{ + HeapFree(GetProcessHeap(), 0, (void*) data); +} + +/***********************************************************************/ + #if !defined(TIOCINQ) && defined(FIONREAD) #define TIOCINQ FIONREAD #endif @@ -1558,12 +1605,13 @@ */ static void COMM_WaitCommEventService(async_private *ovp) { - LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_commio *commio = (async_commio*) ovp; + LPOVERLAPPED lpOverlapped = commio->lpOverlapped; TRACE("overlapped %p\n",lpOverlapped); /* FIXME: detect other events */ - *ovp->buffer = EV_RXCHAR; + *commio->buffer = EV_RXCHAR; lpOverlapped->Internal = STATUS_SUCCESS; } @@ -1579,8 +1627,8 @@ LPDWORD lpdwEvents, /* [out] event(s) that were detected */ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { - int fd,ret; - async_private *ovp; + int fd; + async_commio *ovp; if(!lpOverlapped) { @@ -1591,53 +1639,32 @@ 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_commio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_commio)); if(!ovp) { close(fd); return FALSE; } - ovp->event = lpOverlapped->hEvent; + + ovp->async.ops = &commio_async_ops; + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_WAIT; + ovp->async.func = COMM_WaitCommEventService; + ovp->async.event = lpOverlapped->hEvent; 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->InternalHigh = 0; + lpOverlapped->Offset = 0; + lpOverlapped->OffsetHigh = 0; - if (!ret) - SetLastError(ERROR_IO_PENDING); + if ( !register_new_async (&ovp->async) ) + SetLastError( ERROR_IO_PENDING ); return FALSE; } diff -ruNX ignore CVS/wine/files/file.c TMP/wine/files/file.c --- CVS/wine/files/file.c Wed Apr 3 19:32:56 2002 +++ TMP/wine/files/file.c Fri Apr 5 12:15:58 2002 @@ -64,6 +64,65 @@ WINE_DEFAULT_DEBUG_CHANNEL(file); +/*********************************************************************** + * Asynchronous file I/O * + */ +#include "async.h" + +static DWORD fileio_get_async_status (const async_private *ovp); +static DWORD fileio_get_async_count (const async_private *ovp); +static void fileio_set_async_status (async_private *ovp, const DWORD status); +static void CALLBACK fileio_call_completion_func (ULONG_PTR data); + +static 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 */ +}; + +typedef struct async_fileio +{ + struct async_private async; + LPOVERLAPPED lpOverlapped; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + char *buffer; + int count; +} async_fileio; + +static DWORD fileio_get_async_status (const struct async_private *ovp) +{ + return ((async_fileio*) ovp)->lpOverlapped->Internal; +} + +static void fileio_set_async_status (async_private *ovp, const DWORD status) +{ + ((async_fileio*) ovp)->lpOverlapped->Internal = status; +} + +static DWORD fileio_get_async_count (const struct 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); +} + +/***********************************************************************/ + #if defined(MAP_ANONYMOUS) && !defined(MAP_ANON) #define MAP_ANON MAP_ANONYMOUS #endif @@ -1344,30 +1403,6 @@ 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; w- 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.@) */ @@ -1377,16 +1412,11 @@ 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)) - { - TRACE("overlapped = %p\n",ovp->lpOverlapped); - finish_async(ovp, STATUS_CANCELLED); - } - ovp = t; + if ( ovp->handle == handle ) + cancel_async ( ovp ); } WaitForMultipleObjectsEx(0,NULL,FALSE,1,TRUE); return TRUE; @@ -1400,18 +1430,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))) { @@ -1429,9 +1460,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; @@ -1448,7 +1479,7 @@ LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine, HANDLE hEvent) { - async_private *ovp; + async_fileio *ovp; int fd; TRACE("file %d to buf %p num %ld %p func %p\n", @@ -1468,7 +1499,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"); @@ -1476,31 +1507,19 @@ close(fd); return FALSE; } - ovp->event = hEvent; + + 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->async.event = hEvent; 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; - 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; - } - - return TRUE; + return !register_new_async (&ovp->async); } /*********************************************************************** @@ -1510,7 +1529,6 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = 0; return FILE_ReadFileEx(hFile,buffer,bytesToRead,overlapped,lpCompletionRoutine, INVALID_HANDLE_VALUE); } @@ -1588,7 +1606,6 @@ } /* at last resort, do an overlapped read */ - overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = result; if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, NULL, overlapped->hEvent)) @@ -1646,18 +1663,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))) { @@ -1674,9 +1692,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; @@ -1693,7 +1711,8 @@ LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine, HANDLE hEvent) { - 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); @@ -1704,46 +1723,34 @@ 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" ); 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->event = hEvent; - ovp->func = FILE_AsyncWriteService; + ovp->async.event = hEvent; 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; - } - - /* 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; - - return TRUE; + return !register_new_async (&ovp->async); } /*********************************************************************** @@ -1753,7 +1760,6 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = 0; return FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine, INVALID_HANDLE_VALUE); diff -ruNX ignore CVS/wine/include/async.h TMP/wine/include/async.h --- CVS/wine/include/async.h Thu Jan 1 01:00:00 1970 +++ TMP/wine/include/async.h Fri Apr 5 12:24:13 2002 @@ -0,0 +1,124 @@ +/* + * Structures and static functions for handling asynchronous I/O. + * + * Copyright (C) 2002 Mike McCormack, Martin Wilck + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* + * This file declares static functions. + * It should only be included by those source files that implement async I/O requests. + */ + +#ifndef __WINE_ASYNC_H +#define __WINE_ASYNC_H + +struct async_private; + +typedef void (*async_handler)(struct async_private *ovp); +typedef void CALLBACK (*async_call_completion_func)(ULONG_PTR data); +typedef DWORD (*async_get_status)(const struct async_private *ovp); +typedef DWORD (*async_get_count)(const struct async_private *ovp); +typedef void (*async_set_status)(struct async_private *ovp, const 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; + +typedef struct async_private +{ + struct async_ops *ops; + HANDLE handle; + HANDLE event; + int fd; + async_handler func; + int type; + struct async_private *next; + struct async_private *prev; +} async_private; + +/* All functions declared static for Dll separation purposes */ + +inline static void finish_async( async_private *ovp ) +{ + if(ovp->prev) + ovp->prev->next = ovp->next; + else + NtCurrentTeb()->pending_list = ovp->next; + + if(ovp->next) + ovp->next->prev = ovp->prev; + + ovp->next = ovp->prev = NULL; + + close( ovp->fd ); + if( ovp->event != INVALID_HANDLE_VALUE ) + NtSetEvent( ovp->event, NULL ); + + QueueUserAPC( ovp->ops->call_completion, GetCurrentThread(), (ULONG_PTR)ovp ); +} + +inline static BOOL __register_async( async_private *ovp, const DWORD status ) +{ + BOOL ret; + + SERVER_START_REQ( register_async ) + { + req->handle = ovp->handle; + req->overlapped = ovp; + req->type = ovp->type; + req->count = ovp->ops->get_count( ovp ); + 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; +} + +#define register_old_async(ovp) \ + __register_async (ovp, ovp->ops->get_status( ovp )); + +inline static BOOL register_new_async( async_private *ovp ) +{ + ovp->ops->set_status ( ovp, STATUS_PENDING ); + + ovp->next = NtCurrentTeb()->pending_list; + ovp->prev = NULL; + if ( ovp->next ) ovp->next->prev = ovp; + NtCurrentTeb()->pending_list = ovp; + + return __register_async( ovp, STATUS_PENDING ); +} + +inline static BOOL cancel_async ( async_private *ovp ) +{ + /* avoid multiple cancellations */ + if ( ovp->ops->get_status( ovp ) != STATUS_PENDING ) + return 0; + ovp->ops->set_status ( ovp, STATUS_CANCELLED ); + return __register_async ( ovp, STATUS_CANCELLED ); +} + +#endif /* __WINE_ASYNC_H */ diff -ruNX ignore CVS/wine/include/file.h TMP/wine/include/file.h --- CVS/wine/include/file.h Wed Apr 3 19:32:56 2002 +++ TMP/wine/include/file.h Fri Apr 5 11:19:40 2002 @@ -46,27 +46,6 @@ int flags; } DOS_DEVICE; -/* overlapped private structure */ -struct async_private; -typedef void (*async_handler)(struct async_private *ovp); -typedef struct async_private -{ - LPOVERLAPPED lpOverlapped; - HANDLE handle; - HANDLE event; - 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_private; - -extern void WINAPI check_async_list(LPOVERLAPPED ov, DWORD status); -extern void finish_async(struct async_private *ovp, DWORD status); - /* locale-independent case conversion */ inline static char FILE_tolower( char c ) { @@ -99,7 +78,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 -ruNX ignore CVS/wine/include/wine/server_protocol.h TMP/wine/include/wine/server_protocol.h --- CVS/wine/include/wine/server_protocol.h Tue Apr 2 15:39:35 2002 +++ TMP/wine/include/wine/server_protocol.h Fri Apr 5 12:21:25 2002 @@ -502,7 +502,7 @@ int type; /* VARARG(args,ptrs); */ }; -enum apc_type { APC_NONE, APC_USER, APC_TIMER, APC_ASYNC }; +enum apc_type { APC_NONE, APC_USER, APC_TIMER, APC_ASYNC, APC_ASYNC_IO }; @@ -2278,7 +2278,6 @@ { struct request_header __header; handle_t handle; - void* func; int type; void* overlapped; int count; @@ -3184,6 +3183,6 @@ struct get_window_properties_reply get_window_properties_reply; }; -#define SERVER_PROTOCOL_VERSION 77 +#define SERVER_PROTOCOL_VERSION 78 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ diff -ruNX ignore CVS/wine/scheduler/synchro.c TMP/wine/scheduler/synchro.c --- CVS/wine/scheduler/synchro.c Wed Apr 3 19:32:56 2002 +++ TMP/wine/scheduler/synchro.c Fri Apr 5 12:35:35 2002 @@ -30,6 +30,7 @@ #include "thread.h" #include "winerror.h" #include "wine/server.h" +#include "async.h" /*********************************************************************** @@ -50,74 +51,32 @@ } } -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) - { - QueueUserAPC(call_completion_routine,GetCurrentThread(),(ULONG_PTR)ovp); - } - - /* remove it from the active list */ - if(ovp->prev) - ovp->prev->next = ovp->next; - else - NtCurrentTeb()->pending_list = ovp->next; - - if(ovp->next) - ovp->next->prev = ovp->prev; - - ovp->next=NULL; - ovp->prev=NULL; - - close(ovp->fd); - if(ovp->event!=INVALID_HANDLE_VALUE) - NtSetEvent(ovp->event,NULL); - if(!ovp->completion_func) HeapFree(GetProcessHeap(), 0, ovp); -} - /*********************************************************************** * check_async_list * * Process a status event from the server. */ -void WINAPI check_async_list(LPOVERLAPPED overlapped, DWORD status) +static void WINAPI check_async_list(async_private *asp, DWORD status) { async_private *ovp; + DWORD ovp_status; - /* fprintf(stderr,"overlapped %p status %x\n",overlapped,status); */ + for( ovp = NtCurrentTeb()->pending_list; ovp && ovp != asp; ovp = ovp->next ); - for(ovp = NtCurrentTeb()->pending_list; ovp; ovp = ovp->next) - if(ovp->lpOverlapped == overlapped) - break; - - if(!ovp) + if(!ovp) return; - if(status != STATUS_ALERTED) - ovp->lpOverlapped->Internal = status; + if( status != STATUS_ALERTED ) + { + ovp_status = status; + ovp->ops->set_status (ovp, status); + } + else ovp_status = ovp->ops->get_status (ovp); - if(ovp->lpOverlapped->Internal==STATUS_PENDING) - { - ovp->func(ovp); - FILE_StartAsync(ovp->handle, ovp->lpOverlapped, ovp->type, 0, ovp->lpOverlapped->Internal); - } + if( ovp_status == STATUS_PENDING ) ovp->func( ovp ); - if(ovp->lpOverlapped->Internal!=STATUS_PENDING) - finish_async(ovp,ovp->lpOverlapped->Internal); + /* This will destroy all but PENDING requests */ + register_old_async( ovp ); } @@ -200,6 +159,9 @@ /* convert sec/usec to NT time */ DOSFS_UnixTimeToFileTime( (time_t)args[0], &ft, (DWORD)args[1] * 10 ); proc( args[2], ft.dwLowDateTime, ft.dwHighDateTime ); + break; + case APC_ASYNC_IO: + check_async_list ( args[0], (DWORD) args[1]); break; default: server_protocol_error( "get_apc_request: bad type %d\n", type ); diff -ruNX ignore CVS/wine/server/async.c TMP/wine/server/async.c --- CVS/wine/server/async.c Wed Apr 3 19:32:56 2002 +++ TMP/wine/server/async.c Fri Apr 5 12:22:32 2002 @@ -64,7 +64,7 @@ { /* fprintf(stderr,"notifying %p!\n",async->overlapped); */ async->status = status; - thread_queue_apc(async->thread, NULL, async->func, APC_ASYNC, 1, 2, async->overlapped, status); + thread_queue_apc(async->thread, NULL, NULL, APC_ASYNC_IO, 1, 2, async->overlapped, status); } void destroy_async_queue( struct async_queue *q ) @@ -116,7 +116,7 @@ destroy_async(async); } -struct async *create_async(struct object *obj, struct thread *thread, void *func, +struct async *create_async(struct object *obj, struct thread *thread, void *overlapped) { struct async *async = (struct async *) malloc(sizeof(struct async)); @@ -128,7 +128,6 @@ async->obj = obj; async->thread = thread; - async->func = func; async->overlapped = overlapped; async->next = NULL; async->prev = NULL; @@ -165,7 +164,7 @@ if(req->status==STATUS_PENDING) { if(!async) - async = create_async(obj, current, req->func, req->overlapped); + async = create_async(obj, current, req->overlapped); if(async) { diff -ruNX ignore CVS/wine/server/async.h TMP/wine/server/async.h --- CVS/wine/server/async.h Tue Apr 2 15:39:41 2002 +++ TMP/wine/server/async.h Fri Apr 5 11:19:45 2002 @@ -30,7 +30,6 @@ { struct object *obj; struct thread *thread; - void *func; void *overlapped; unsigned int status; struct timeval when; @@ -51,7 +50,7 @@ struct async *find_async(struct async_queue *q, struct thread *thread, void *overlapped); void async_insert(struct async_queue *q, struct async *async); struct async *create_async(struct object *obj, struct thread *thread, - void *func, void *overlapped); + void *overlapped); void async_add_timeout(struct async *async, int timeout); static inline void init_async_queue(struct async_queue *q) { diff -ruNX ignore CVS/wine/server/protocol.def TMP/wine/server/protocol.def --- CVS/wine/server/protocol.def Wed Apr 3 19:32:56 2002 +++ TMP/wine/server/protocol.def Fri Apr 5 12:17:37 2002 @@ -412,7 +412,7 @@ int type; /* function type */ VARARG(args,ptrs); /* function arguments */ @END -enum apc_type { APC_NONE, APC_USER, APC_TIMER, APC_ASYNC }; +enum apc_type { APC_NONE, APC_USER, APC_TIMER, APC_ASYNC, APC_ASYNC_IO }; /* Close a handle for the current process */ @@ -1615,10 +1615,9 @@ #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; int type; void* overlapped; int count; diff -ruNX ignore CVS/wine/server/thread.c TMP/wine/server/thread.c --- CVS/wine/server/thread.c Tue Apr 2 15:39:42 2002 +++ TMP/wine/server/thread.c Fri Apr 5 11:19:45 2002 @@ -959,8 +959,9 @@ } /* Optimization: ignore APCs that have a NULL func; they are only used * to wake up a thread, but since we got here the thread woke up already. + * Exception: for APC_ASYNC_IO, func == NULL is legal. */ - if (apc->func) break; + if (apc->func || apc->type == APC_ASYNC_IO) break; free( apc ); } size = apc->nb_args * sizeof(apc->args[0]); diff -ruNX ignore CVS/wine/server/trace.c TMP/wine/server/trace.c --- CVS/wine/server/trace.c Wed Apr 3 19:32:56 2002 +++ TMP/wine/server/trace.c Fri Apr 5 12:21:25 2002 @@ -1846,7 +1846,6 @@ static void dump_register_async_request( const struct register_async_request *req ) { fprintf( stderr, " handle=%d,", req->handle ); - fprintf( stderr, " func=%p,", req->func ); fprintf( stderr, " type=%d,", req->type ); fprintf( stderr, " overlapped=%p,", req->overlapped ); fprintf( stderr, " count=%d,", req->count );

April 5, 2002

Re: [PATCH] async IO APCs call check_async_list() directly

by Martin Wilck

Hi Mike, > I think this is a better way to do things, but it might be better to > submit this patch against the current CVS rather than against > CVS+previous patch. I chose this way because it shows the changes more clearly. I can easily send the "combined" patch if this is desired. Do you have any other issues/criticisms wrt to the stuff I sent? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 5, 2002

Re: [PATCH] HOMAM III fix

by 520007368975-0001＠t-online.de

Hi On Friday 05 April 2002 19:06, Andreas Mohr wrote: > On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > > Hello! > > > > Function CreateFileA get this file path (just for example): > > > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > > > As you can see the correct path should be: > > > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > > > This lead to error message "Can't initialize resources.Possible disk > > problem." > > > > I see the problem in the function DOSFS_DoGetFullPathName(), which in > > the end removes the ending backslash from the path. The attached patch > > fixes it. > > > > Bye, Martin > > > > Yep, that might fix *your* problem, but don't you think that code snippet > might have been there for a purpose ? > To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" I sent to this list more than a week ago. Until now no real answer has been given. > Are you sure that simply completely removing code doesn't break anything > here in other cases ? I cant think of any situation where this might be needed. I may be wrong though. Yet so far I have no explanation for this piece of code and removing it seems to work fine. Enrico farmboy1(a)subdimension.com

April 5, 2002