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

Windows 2000 conformance test update

by Dave Miller

Here are three updates for the status page. I think user32/sysparams passed for me previously. C:\winetests>kernel32_test.exe path path.c:514: Test failed: GetLongPathNameA: wrong return code, 97 instead of 42 path.c:881:TMP=C:\DOCUME~1\davidm\LOCALS~1\Temp path.c:892:TMP=C:\WINNT path.c:902:TMP=C:\ path.c:912:TMP=C: path: 1730 tests executed, 0 marked as todo, 1 failure. C:\winetests>urlmon_test generated generated: 4 tests executed, 0 marked as todo, 0 failures. C:\winetests>user32_test sysparams sysparams.c:184:testing SPI_{GET,SET}BEEP sysparams.c:306:testing SPI_{GET,SET}MOUSE sysparams.c:374:testing SPI_{GET,SET}BORDER sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=1, value= sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=0, value= sysparams.c:139: Test failed: Missed a message: change_counter=2 sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=7, value= sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=20, value= sysparams.c:406:testing SPI_{GET,SET}KEYBOARDSPEED sysparams.c:139: Test failed: Missed a message: change_counter=2 sysparams.c:440:testing SPI_ICONHORIZONTALSPACING sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=101, value= sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=32, value= sysparams.c:480:testing SPI_{GET,SET}SCREENSAVETIMEOUT sysparams.c:515:testing SPI_{GET,SET}SCREENSAVEACTIVE sysparams.c:555:testing SPI_{GET,SET}KEYBOARDDELAY sysparams.c:590:testing SPI_ICONVERTICALSPACING sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=101, value= sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=32, value= sysparams.c:635:testing SPI_{GET,SET}ICONTITLEWRAP sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=1, value= sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=0, value= sysparams.c:670:testing SPI_{GET,SET}MENUDROPALIGNMENT sysparams.c:707:testing SPI_SETDOUBLECLKWIDTH sysparams.c:738:testing SPI_SETDOUBLECLKHEIGHT sysparams.c:770:testing SPI_SETDOUBLECLICKTIME sysparams.c:817:testing SPI_SETMOUSEBUTTONSWAP sysparams.c:880:testing SPI_{GET,SET}DRAGFULLWINDOWS sysparams.c:915:testing SPI_{GET,SET}WORKAREA sysparams.c:953:testing SPI_{GET,SET}SHOWSOUNDS sysparams.c:997:testing SPI_{GET,SET}DESKWALLPAPER sysparams: 318 tests executed, 0 marked as todo, 12 failures.

Jan. 10, 2003

Re: Help with /?? stuff

by John K. Hohm

> > Alberto Massari wrote: > > I guess Wine is converting the NULL into \?? to be able to store it as > > a string. Shachar Shemesh wrote: > You guessed wrong. The leading \?? is there under both Wine and Windows > 2000, and in both cases there is ALSO a NULL. As neither Wine nor > Windows 2000 then accepts that as a valid path, I'll just remove it. I > was just wondering whether anyone knows why Windows 2000 puts that extra > stuff in (it's obvious why wine does that - to be compatible). I'm not sure about \??, but see this excerpt from MSDN Re CreateFile: lpFileName [in] Pointer to a null-terminated string that specifies the name of the object to create or open. In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path. For more information, see Naming a File. Windows 95/98/Me: This string must not exceed MAX_PATH characters.

Jan. 10, 2003

Re: wine/dlls/comcat regsvr.c comcat_main.c

by John K. Hohm

Quoting "Dimitrie O. Paun" <dpaun(a)rogers.com>: > On January 10, 2003 12:48 am, John K. Hohm wrote: > > + CLSID const *clsid; /* NULL for end of list */ > [...] > > + { NULL } /* list terminator */ > > Why not terminate the list with a NULL pointer to the struct instead, > it's simpler and more idiomatic... It is because I am using a list of structures, not a list of pointers to structures. How would you create a static list of pointers to structures, without naming each one?

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Roderick Colenbrander

Forgot to include an url to the safari developer page containing the usefull source code. I rechecked the license of the qt wrapper (kwq) and it looks a lot like a BSD license. It also seems possible to easily compile the wrapper to work on for example Linux. (only new makefiles are needed) I hope this helps, Roderick Colenbrander On Friday 10 January 2003 21:57, Roderick Colenbrander wrote: > Why don't look at the stuff Apple made for their khtml wrapper? They made > two components to interact with khtml. One javascript wrapper > (JavascriptCore) and another component containing some sort of QT wrapper > called WebCore. The license of WebCore looks LGPL compatible (not 100% > sure), so perhaps it is possible to reuse the stuff they made. > > When khtml gets an update they can plug it in this framework and it should > work. (theoraticly) > > On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote: > > On January 10, 2003 06:45 am, Ender wrote: > > > The current state of my local tree, besides being a mess, is that it > > > has most QT dependencies removed. Currently it uses a lot of QT stub's > > > around WinAPI functions that I wish to remove before doing much more > > > work with it. > > > > Ender, you may be right that we might have to integrate something into > > the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year > > down the road? KHTML is very much a work in progress, who's gonna track > > it? We don't have any richedit control, heck even our bog standard edit > > box is not finished! And for how many years now?!? Just for curiosity's > > sake, can you give us a wc -l of the KHTML stuff? > > > > If we do have to integrate something, I think we *have* to have a way to > > track the KHTML development. Just throwing something in the tree may > > actually be detrimental, if it remains unmaintained. To be able to track > > the KHTML development, we need to keep track of the revisions we worked > > off of, and we have to avoid touching their sources. To this end, I think > > we are much better off by implementing a QT subset: > > -- It should be a lot stabler than the KHTML stuff. It seems to > > me QT hasn't change that much from the 1.0 days, now it should > > be close to a libc in terms of interface stability. > > -- I haven't looked, but I assume KHTML can't use that many > > difficult to implement QT features > > -- Having a free QT/Windows implementation is generally useful to > > a lot of people, so we're likely to get more people to help > > If our changes to the KHTML source are minor, I am certain the KDE people > > will help us by integrating them upstream. If in time we can work off of > > the same code base, we can simply delete our copy from the Wine tree. > > > > There might be another way. Now that Safari is out and it's deQTfied, > > and having more and more people interested in KHTML, the KDE folk may > > decide to officially switch to a QT-free KHTML version, in which case > > we'll be saved the trouble of implementing a WQT (pronounced wicked :)).

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Dimitrie O. Paun

On January 10, 2003 05:15 pm, Roderick Colenbrander wrote: > Forgot to include an url to the safari developer page containing the > usefull source code. Funny thing is, you forgot the second time as well... :) -- Dimi.

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Roderick Colenbrander

Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made. When khtml gets an update they can plug it in this framework and it should work. (theoraticly) On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote: > On January 10, 2003 06:45 am, Ender wrote: > > The current state of my local tree, besides being a mess, is that it has > > most QT dependencies removed. Currently it uses a lot of QT stub's around > > WinAPI functions that I wish to remove before doing much more work with > > it. > > Ender, you may be right that we might have to integrate something into > the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year > down the road? KHTML is very much a work in progress, who's gonna track > it? We don't have any richedit control, heck even our bog standard edit > box is not finished! And for how many years now?!? Just for curiosity's > sake, can you give us a wc -l of the KHTML stuff? > > If we do have to integrate something, I think we *have* to have a way to > track the KHTML development. Just throwing something in the tree may > actually be detrimental, if it remains unmaintained. To be able to track > the KHTML development, we need to keep track of the revisions we worked > off of, and we have to avoid touching their sources. To this end, I think > we are much better off by implementing a QT subset: > -- It should be a lot stabler than the KHTML stuff. It seems to > me QT hasn't change that much from the 1.0 days, now it should > be close to a libc in terms of interface stability. > -- I haven't looked, but I assume KHTML can't use that many > difficult to implement QT features > -- Having a free QT/Windows implementation is generally useful to > a lot of people, so we're likely to get more people to help > If our changes to the KHTML source are minor, I am certain the KDE people > will help us by integrating them upstream. If in time we can work off of > the same code base, we can simply delete our copy from the Wine tree. > > There might be another way. Now that Safari is out and it's deQTfied, > and having more and more people interested in KHTML, the KDE folk may > decide to officially switch to a QT-free KHTML version, in which case > we'll be saved the trouble of implementing a WQT (pronounced wicked :)).

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Dan Kegel

Francois Gouget wrote: > On Fri, 10 Jan 2003, Dan Kegel wrote: >>The g++ ABI will *not* change on a regular basis. It is rapidly >>converging on the portable C++ ABI shared by several vendors, >>and defined in a standards document. > > That's good news. especially if multiple vendors use the same ABI it > seems all the more likely to actually be stable. Yes. Too bad Microsoft isn't one of those vendors :-) -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 10, 2003

Readfile on a duplicated pipe hangs

by Uwe Bonnes

Hallo, Marcus sent me patches that made Altera quartus install. Thanks. Now running the package hangs in the way it communicates with created processes. Here is what happens in my understanding: M: Masterprocess C: Childprocess M: CreatePipe -> handle_read + handle_write M: DuplicateHandle handle_read -> handle_read_dup M: CloseHandle (handle_read) M: Call CreateProcessA with handle_write as hstderr M: Return Createprocess M: CloseHandle (handle_write) M: Call Readfile (handle_read_dup) C: initializes, executes and exit M: Return Readfile retval=00000001 M: Endless loop of Call Readfile (handle_read_dup) retval=00000001 MSDN says, that ReadFile should fail on an anonymous pipe, if the othe end has close. With following patch, the application starts up. Feedback welcome. Index: wine/server/pipe.c =================================================================== RCS file: /home/wine/wine/server/pipe.c,v retrieving revision 1.24 diff -u -r1.24 pipe.c --- wine/server/pipe.c 30 May 2002 20:12:58 -0000 1.24 +++ wine/server/pipe.c 10 Jan 2003 20:28:43 -0000 @@ -141,6 +141,13 @@ static int pipe_get_info( struct object *obj, struct get_file_info_reply *reply, int *flags ) { + struct pipe *pipe = (struct pipe *)obj; + assert( obj->ops == &pipe_ops ); + if (!pipe->other) + { + set_error( STATUS_PIPE_BROKEN ); + return -1; + } if (reply) { reply->type = FILE_TYPE_PIPE; -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Francois Gouget

On Fri, 10 Jan 2003, Dan Kegel wrote: [...] > The g++ ABI will *not* change on a regular basis. It is rapidly > converging on the portable C++ ABI shared by several vendors, > and defined in a standards document. That's good news. especially if multiple vendors use the same ABI it seems all the more likely to actually be stable. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Dan Kegel

Francois Gouget wrote: > On Fri, 10 Jan 2003, Dan Kegel wrote: >>(There was one little ABI tweak between 3.2 and 3.3, >>and there may be more later, but they probably >>won't break many apps.) > > That too seems incompatible with something declared 'stable'. > > Not that I have anything against C++, I like OO programming. But these > g++ compatibility issues have been like a cold shower. Yes, indeed. But things are looking *much* better. As I mentioned in my links, there's now an ABI standard that all c++ compilers can conform to, and at least Intel, SGI, and Gnu are all trying very hard to conform to it. gcc 3.0 was the first gcc to try to conform; gcc 3.2 fixed a bunch of conformance problems; gcc 3.3 fixed a couple tiny ones that became evident after 3.2 was released. > <rant class="my opinion only"> >>From the point of vue of an ISV, distributing a Wine binary is already > enough trouble with the C library changing their internal implementation > (which of course they are absolutely free to do since it's *internal*) > and FreeType breaking backwards compatibility in minor releases, but if > ISVs also have to deal with g++ changing their ABI on a regular basis... > Well, I guess ISVs could always compile these libraries with Visual C++ > and ship them as Windows dlls and thus benefit from a stable and Wine > compatible ABI... > </rant> The g++ ABI will *not* change on a regular basis. It is rapidly converging on the portable C++ ABI shared by several vendors, and defined in a standards document. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 10, 2003