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 5, 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 5, 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 5, 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