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

Re: strcat+strcat+strcat == baaad

by Joerg Mayer

On Sat, Nov 30, 2002 at 10:49:34AM -0800, Alexandre Julliard wrote: > > It's more efficient to do: > > > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); In case you cannot be 100% sure of the lengths, it might still be worth it with snprintf, but otherwise, it's a matter of taste. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Nov. 30, 2002

Reopened a bug

by Dustin Navea

I have reopened bug #15 due to the fact that the bug still exists to a certain extent and in a different form. When sending an IM in AIM with any recent version of wine (including a couple of days before the latest cvs snapshot), I can resize the window and when the buttons go to reposition themselves, they move much slower than the border of the window, and you can see them updating their position. Would there be any debug traces I could post to the bug to help resolve this? -Dustin

Nov. 30, 2002

Re: Janitorial Projects

by Dustin Navea

Sorry if this hits the list twice im not sure if i typed wine-devel into the to line or not ;) That is a good question, either that or i will need borrow a copy of msvc from a friend.. -Dustin ----- Original Message ----- From: "Tony Lambregts" <tony_lambregts(a)telusplanet.net> To: <dpaun(a)rogers.com> Cc: "Wine devel" <wine-devel(a)winehq.com> Sent: Saturday, November 30, 2002 1:09 PM Subject: Re: Janitorial Projects > Dimitrie O. Paun wrote: > > >On November 29, 2002 03:06 pm, Francois Gouget wrote: > > > > > >>Here's a proposed addition to the Janitorial projects: > >> > >> > > > >Added: > > http://www.dssd.ca/wine/Wine-Fun.html#tests > > > >Let me know if you want anything changed. > > > > > > > Well since I have Windows 98 on my computer I would like to volunteer to > run the tests. I however do not have Visual C++ (or any other windows > compiler). That leads me to the following question. Would someone place > the compiled tests somewhere on the web so that I can download them. > > I suppose that another solution would be to use MinGW (right?) If this > is a Good Idea (tm) then some tips on how to do this (or a pointer to > some relevant documentation) would be appreciated. > > -- > > Tony Lambregts > > > >

Nov. 30, 2002

Re: Adding support for xxx_test.exe all

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So I propose the following patch which makes it possible to run > 'xxx_test.exe all' which runs all the tests implemented by that > executable. > > Do others find this patch acceptable? Useful? The drawback I see is that with this change the tests do not start with a clean process state, which could cause problem for some of them. Or we need to require that all tests cleanup properly after them, which may be a bit painful. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2002

Re: Janitorial Projects

by Tony Lambregts

Dimitrie O. Paun wrote: >On November 29, 2002 03:06 pm, Francois Gouget wrote: > > >>Here's a proposed addition to the Janitorial projects: >> >> > >Added: > http://www.dssd.ca/wine/Wine-Fun.html#tests > >Let me know if you want anything changed. > > > Well since I have Windows 98 on my computer I would like to volunteer to run the tests. I however do not have Visual C++ (or any other windows compiler). That leads me to the following question. Would someone place the compiled tests somewhere on the web so that I can download them. I suppose that another solution would be to use MinGW (right?) If this is a Good Idea (tm) then some tips on how to do this (or a pointer to some relevant documentation) would be appreciated. -- Tony Lambregts

Nov. 30, 2002

RE: strcat+strcat+strcat == baaad

by Medland, Bill

> -----Original Message----- > From: wine-patches-admin(a)winehq.com > [mailto:wine-patches-admin(a)winehq.com]On Behalf Of Francois Gouget > Sent: Friday, November 29, 2002 10:11 PM > To: wine-patches(a)winehq.com > Subject: strcat+strcat+strcat == baaad > > > > I don't like pieces of code that go: > > strcpy(foo, bar1); > strcat(foo, bar2); > strcat(foo, bar3); > strcat(foo, bar4); > strcat(foo, bar5); > strcat(foo, bar6); > > It's really inefficient: the cost increases quadratically > with the size > of the resulting string. It's more efficient to do: > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); > > Here the cost is proportional to the size of the resulting string. And surely when the opportunity arises it would be better to use snprintf (i.e. when you know the size of the buffer). (I doubt that the code has already checked the size of the strings being pasted together) > > For for various reasons I came accross a couple of instances of > strcat+strcat badness and replaced them with a sprintf. So here's the > patch. > > Changelog: > > * memory/environ.c, > tools/makedep.c > > Use sprintf rather than calling strcat over and over > > > Index: memory/environ.c > =================================================================== > RCS file: /home/wine/wine/memory/environ.c,v > retrieving revision 1.38 > diff -u -r1.38 environ.c > --- memory/environ.c 9 Oct 2002 18:35:02 -0000 1.38 > +++ memory/environ.c 30 Nov 2002 05:20:12 -0000 > @@ -641,12 +641,7 @@ > > /* Set the new string */ > > - if (value) > - { > - strcpy( p, name ); > - strcat( p, "=" ); > - strcat( p, value ); > - } > + if (value) sprintf( p, "%s=%s", name, value ); > current_envdb.env = new_env; > ret = TRUE; > > Index: tools/makedep.c > =================================================================== > RCS file: /home/wine/wine/tools/makedep.c,v > retrieving revision 1.13 > diff -u -r1.13 makedep.c > --- tools/makedep.c 17 Aug 2002 18:28:43 -0000 1.13 > +++ tools/makedep.c 30 Nov 2002 06:10:17 -0000 > @@ -192,9 +192,7 @@ > if (SrcDir) > { > pFile->filename = xmalloc( strlen(SrcDir) + > strlen(pFile->name) + 2 ); > - strcpy( pFile->filename, SrcDir ); > - strcat( pFile->filename, "/" ); > - strcat( pFile->filename, pFile->name ); > + sprintf( pFile->filename, "%s/%s", SrcDir, pFile->name ); > } > else pFile->filename = xstrdup( pFile->name ); > > @@ -218,9 +216,7 @@ > for (path = firstPath; path; path = path->next) > { > char *filename = xmalloc(strlen(path->name) + > strlen(pFile->name) + 2); > - strcpy( filename, path->name ); > - strcat( filename, "/" ); > - strcat( filename, pFile->name ); > + sprintf( filename, "%s/%s", path->name, pFile->name ); > if ((file = fopen( filename, "r" ))) > { > pFile->filename = filename; > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > >

Nov. 30, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I don't like pieces of code that go: > > strcpy(foo, bar1); > strcat(foo, bar2); > strcat(foo, bar3); > strcat(foo, bar4); > strcat(foo, bar5); > strcat(foo, bar6); > > It's really inefficient: the cost increases quadratically with the size > of the resulting string. Well, no, the cost is linear. It would only be quadratic if the number of strcat calls depended on the length of the string. > It's more efficient to do: > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); I seriously doubt that sprintf would be faster that a couple of strcats. And I don't think we need to worry about this kind of micro-optimizations right now... -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2002

Re: somebody help me identify this bug please

by ezra daniel

that I have tried and needed yes, only valves with "acute accent" like you call it, excuse my english.. :) And I dont understand what you mean by dead key... but anyway... in every linux app I can type that right, only the new wine version breaks that, but I know it was fixed on 20021031 cause it worked great. To make an example of what I can't type : canción = in the wine version appears as cancion without the ó In my language this is very important or they will think I dont know how to write my language, hehehe Thanks :) -daniel http://www.debian-gnu.com >From: "Jeff Smith" <whydoubt(a)hotmail.com> >To: ezra_daniel(a)hotmail.com, wine-devel(a)winehq.com >Subject: Re: somebody help me identify this bug please >Date: Fri, 29 Nov 2002 13:31:46 -0600 > >Is it only characters with the acute accent? Is it that your are >attempting this using 'dead key' entry on a Spanish keyboard? > >If this is the case, the problem may be in a recent correction to >the Spanish keyboard layout. > >I will work on this some more when I get a chance, but hopefully >someone else will find something sooner. > > -- Jeff S > > >>From: "ezra daniel" <ezra_daniel(a)hotmail.com> >> >>Hello, >> >>At work I use Lotus Notes under Wine. >> >>I downloaded compiled and installed the new wine version 20021125 and I am >>no longer able to type accecented valves, like á é í ó ú. >> >>Ñ can be typed though correctly. >> >>With the other version 20021031 I could type accented valves.In fact I >>went back to using the older version and worked again so it is obvious it >>is a problem in the new wine version. >> >>Though I am a newbie and know nothing of developing, but I would like to >>submit the bug to the proper person so it fixes it back again but I dont >>know which section of wine or person deals with this character typing >>problem. >> >>Can anyone point me in the right direction? Thanks in advance. >> >>-daniel >>http://www.debian-gnu.com > _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx

Nov. 30, 2002

Re: Yet another D3D patch....

by Christian Costa

Lionel Ulmer wrote: >>This patch breaks the TWIST demo that was working fine. >>I think the changes in d3ddevice_create are responsible of that. >> > >Strange, it works fine here.. A bit slow when statistics are displayed (due >to the locking of the D3DEVICE surface and thus needing a slow GL call like >glReadPixels / glDrawPixels) but as fast as before when disabling them. > > >But well, my tree has patches up to number 13 so maybe I broke something >that was fixed later on (although I wonder what). > I applied your next patches (until 13) and it has been fixed. Cool... :-) Statistics are not displayed for me and the 565 texture format looks strange. But appart from that it's fine. Thanks.

Nov. 30, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On November 29, 2002 03:06 pm, Francois Gouget wrote: > Here's a proposed addition to the Janitorial projects: Added: http://www.dssd.ca/wine/Wine-Fun.html#tests Let me know if you want anything changed. -- Dimi.

Nov. 30, 2002

DPMI_CallRMProc trouble

by György 'Nog' Jeney

I realy need help with this. Whenever I call a DOSDEV_ function then that function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc. Now that function call DOSMEM_GetBlock( 64, (UINT16 *)&(context->SegSs) ) to try and allocate a stack. This fails for some reason but I dont understand why because it succeds if called from int21/48. Anyone know whats going on? nog.

Nov. 30, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On November 29, 2002 06:10 pm, Rolf Kalbermatter wrote: > But what the heck do the errors about AW functions calling Unicode > mean? Isn't that the actual idea about the AW functions? Good catch. I've updated the list, there were 52 AW functions, which leaves us 142 cross calls to deal with... :) -- Dimi.

Nov. 30, 2002

Re: Yet another D3D patch....

by Lionel Ulmer

> This patch breaks the TWIST demo that was working fine. > I think the changes in d3ddevice_create are responsible of that. Strange, it works fine here.. A bit slow when statistics are displayed (due to the locking of the D3DEVICE surface and thus needing a slow GL call like glReadPixels / glDrawPixels) but as fast as before when disabling them. But well, my tree has patches up to number 13 so maybe I broke something that was fixed later on (although I wonder what). Do you have more precise debug output ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Re: Yet another D3D patch....

by Christian Costa

Lionel Ulmer wrote: >Hi all, > >This patch should not be dependant of any others... But to prevent line >number errors, better to commit it after the 5 -> 9 series (yeah, the >attachements are numbered to ease tracking :-) ). > >Changelog: > - start of support for device locking / unlocking via glReadPixels / > glDrawPixels interface (slow but should be enough for a start) > - implement one vertex case for the D3D3/7 DrawPrimitive functions > - fix a missing \n in a TRACE call > > Lionel > This patch breaks the TWIST demo that was working fine. I think the changes in d3ddevice_create are responsible of that.

Nov. 30, 2002

MIDI Mapper fix

by Jeff Smith

I'm so happy, I just had to share it with everyone :-D Changelog: Fix for MIDI Mapper. Notes: Finally found it! This was the last thing keeping sound from working in Auralia. With just this simple patch, it now works. Auralia still has a few problems, but they are minor in comparison. It *is* kind of important for sound to work in an ear training program ;-) BTW, Thanks to Eric P. for his help getting me off to a running start with his fixes to the OSS MIDI driver a couple of weeks back. (patch is attached - Hotmail has not been kind to my inlined patches the past few days) _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

Nov. 30, 2002

Where to use dosdev

by György 'Nog' Jeney

In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.

Nov. 30, 2002

Re: Texture problems under Wine - more info

by Lionel Ulmer

> So, the question is "What is the difference between the WineX OpenGL > library and the Wine OpenGL library?" Well, for me, the only possible difference would be that : '> This begs the question: > Does the Linux implementation of pthread really work anyway? Works in WineX (though we needed some more hacks in it to make it interact well with the nvidia opengl drivers), and it'd surprise me if it doesn't still work in Wine, as the OpenGL deployed by most linux distros wouldn't work *at all* under Wine if it didn't, and people currently seem to be working on Wine as if it did work.' (copy pasted from one of Ove's mail). Because well, I did not look at WineX's OpenGL code but I doubt that it could be vastly different from Wine's one (you cannot write thunks a lot of different ways :-) ) so the only possible difference would be a bug in the pthread 'emulation' that would somehow break the drivers. By the way, what drivers are you using ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Re: valgrind and wine

by Lionel Ulmer

> ==6476== Valgrind detected that your program requires > ==6476== the following unimplemented functionality: > ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. > ==6476== This may be because the functionality is hard to implement, > ==6476== or because no reasonable program would behave this way, > ==6476== or because nobody has yet needed it. In any case, let me know > ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Which version of Valgrind is this ? According to the web page, 1.1.0 should support this system call : 'Specifically, valgrind can now deal with x86 segment registers, segment override prefixes and the modify_ldt system call'. But well, for it to really be useful, we would need then also to override in Valgrind (or in Wine) all the Threading and Heap functions. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Adding support for xxx_test.exe all

by Francois Gouget

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Nov. 30, 2002

Texture problems under Wine - more info

by David D. Hagood

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

Nov. 30, 2002

valgrind and wine

by Dan Kegel

valgrind wine reports: ==6476== Valgrind detected that your program requires ==6476== the following unimplemented functionality: ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. ==6476== This may be because the functionality is hard to implement, ==6476== or because no reasonable program would behave this way, ==6476== or because nobody has yet needed it. In any case, let me know ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Dang. - Dan

Nov. 30, 2002

The conformance tests need you!

by Francois Gouget

Hi, I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms. That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine). You can see things more graphically at the following URL: http://fgouget.free.fr/wine/tests-en.shtml Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Nov. 30, 2002

Re: [RFC] Wine headers

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers I think everything should be under wine/ otherwise we risk conflicts with other packages. So I'd suggest something like this: ${prefix}/include/wine/windows -- standard Windows headers ${prefix}/include/wine/msvcrt -- MS Visual C Runtime library ${prefix}/include/wine -- Wine specific headers It means the Windows headers are a bit buried instead of being directly under wine/, but it's not too bad. As long as you don't change anything in the source tree I could be convinced to go along with that... -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2002

Case of Guiness offered (was: Re: Partial success report: Toshiba 220CDS electronic manual)

by Dan Kegel

Dimitrie O. Paun wrote: > On November 26, 2002 12:39 pm, Dan Kegel wrote: >> http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe >>I unzipped it with Linux unzip, then ran its setup and >>the app itself with Wine20020605-2 from Red Hat 8. > > ^^^^^^^^ > Wow, that is ancient. It seems like such a long time ago... :) > (But I don't mean to say that the test is not relevant) OK, I tried the same app with a freshly compiled Wine20021125. The results are no better. The commandline to run the program is cd c/docs wine toshdoc.EXE With either version of Wine, clicking around for a while locks the app up. (e.g. clicking on the big red Right Arrow 10-15 times locks it up). Plus the display artifacts (text being overwritten without being cleared) are still there. Wow, I'm really striking out running either the 16 bit or 32 bit version of this old app (see my other post today). Both are freely downloadable... I'd gladly buy a case of Guiness for anyone who contributed patches to the Wine tree that got either of these apps running cleanly. I sadly don't have time to do much more than test. - Dan

Nov. 30, 2002

Failure running 1998-era online manual

by Dan Kegel

I grabbed Wine-20021125 and built it on my Red Hat 7.3 box. Its behavior installing http://enduser:enduser(a)bbs.toshiba.co.uk/file/area128/S22D95UM.ZIP (the Windows 95 version of the user manual for my 1998-era Toshiba laptop) seems much improved over May/June 2002 wine, cool! However, running the app does no better. To run the app, you do cd 'c/Program Files/DOC' wine edoc32.exe TOSHIBA.M14 On Windows, it works fine. On Wine, it displays a splash screen, then exits. Here's a partial log: 08074e50:Ret kernel32.lstrcpyA() retval=406d2dc0 ret=01643c25 08074e50:Call winmm.mmioInstallIOProcA(2034314d,01643b30,10010000) ret=01643c54 trace:mmio:MMIO_InstallIOProc (540291405, 0x1643b30, 10010000, 1) fixme:mmio:MMIO_InstallIOProc Global procedures not implemented ... 08074e50:Ret winmm.mmioInstallIOProcA() retval=01643b30 ret=01643c54 08074e50:Ret PE DLL (proc=0x1641030,module=0x1640000,type=1,res=0x1) retval=1 ... 08074e50:Starting process C:\Program Files\DOC\edoc32.exe (entryproc=0x41c9b0) ... 08074e50:Call winmm.mmioOpenA(406d2cfc "+init",00000000,00000000) ret=00405fd6 trace:mmio:MMIO_Open ('+init', (nil), 00000000, 1); 08074e50:Call ntdll.RtlAllocateHeap(40380000,00000008,0000005c) ret=40c3e59b 08074e50:Ret ntdll.RtlAllocateHeap() retval=403c42b8 ret=40c3e59b trace:mmio:MMIO_ParseExtA ("+init") err:mmio:MMIO_ParseExtA + but no . in szFileName: "+init" It sounds like mmioOpen's documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… is incomplete; it doesn't describe what the function does when there's no filename, just a +init, in the string passed to mmioOpen. I tried patching the source for MMIO_ParseExtA to assume an extension of "" in this case, but it didn't help, the program still exits. Any suggestions? - Dan

Nov. 30, 2002

Re: [RFC] Winelib enhancements (Compiler)

by Acke Carlsson

On Thursday 28 November 2002 08:00 pm, Dimitrie O. Paun wrote: > On November 28, 2002 01:35 pm, Alexandre Julliard wrote: > > > -CC=gcc > > > +CC=wcc > > > > > > Q: Alexandre, would you accept such a utility in the tree? > > > > I don't know, I don't think you can write a one-size-fits-all script, > > different apps will require different options, and then it will get > > even more confusing IMO if you have two different ways of doing it > > depending on your options. Maybe we should simply have a script > > example in the documentation that people can adapt and ship with their > > app if the makefile really makes it hard to set options. > > Sorry, maybe I was unclear. This wrapper will probably be a small C > program that understands gcc's options. It needs to do the following: > -- add the include dirs first > -- add -fshort-wchar > -- add -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" > -- remove cygwin options not recognized by the Linux gcc > > If you think about them, it kindda makes sense, as under a Windowish > environment these options are _implied_ in the invocation of gcc, > just like -I /usr/include is implied when you invoke gcc under Linux. > > So to be honest, I don't see why it would be confusing, and second, > why we can not have a one-size-fits-all wrapper. > > As I said, this is more a porting tool, to help you with the initial port. > If the app has a configure script, you would want to instrument it to > generate the correct flags for the compiler, and use gcc directly. But this > is time consuming, and you have to worry about so many things at the > beginning, I find it so much easier to have something working, and tweak > only one thing at a time. Some small ide from uClibc.

Nov. 29, 2002

Re: ppdebug

by Duane Clark

Michael Sauer wrote: > ... > P.S.: sorry if this mail reaches the list twice, but the first one i send > with some private e-mail address and the list moderator will (hopefully) > erase it (as he does it every time). > Hmmm... since I am the moderator, I am a bit puzzled by that. On rare occasions I will reject a post, but always supply a reason. The only ones I "erase" are spam. In any case, starting Saturday afternoon for about a week, I will be gone. Hopefully some of the other folks with moderator access will fill in, otherwise moderated posts are going to get stuck in moderator limbo for quite awhile.

Nov. 29, 2002

RE: Janitorial Projects

by Patrik Stridvall

> "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > >I have updated the Janitorial section: > > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > > > >with the list of cross calls from 32->16, and W->A. > > > >There are currently 13 cross calls from 32->16 bit code, > >and 194 cross calls from Unicode to ASCII. [snip] > But what the heck do the errors about AW functions calling Unicode > mean? It means that winapi_check has a bug. Fixed in my tree. > Isn't that the actual idea about the AW functions? Yes. :-)

Nov. 29, 2002

RE: Wine conformance tests with MSVC headers

by Patrik Stridvall

> I tried to compile the various conformance tests with MSVC 6.0. There > are two different configurations for each project: with MSVC or Wine > headers. With the MSVC headers configuration, it doesn't find > "wine/test.h" (since wine/include is not in the include > path). Is it a > known behavior? With the Wine headers configuration, I don't > get those > errors It is bug. Fixed in my tree. Patch comming soon. > (but there are a bunch of warnings concerning signed/unsigned > comparisons, for which I'll try to send a patch tonight). OK.

Nov. 29, 2002

Re: Janitorial Projects

by Rolf Kalbermatter

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: >I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > >with the list of cross calls from 32->16, and W->A. > >There are currently 13 cross calls from 32->16 bit code, >and 194 cross calls from Unicode to ASCII. I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version. But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions? Rolf Kalbermatter

Nov. 29, 2002

Wine conformance tests with MSVC headers

by Vincent Béron

Hello, I tried to compile the various conformance tests with MSVC 6.0. There are two different configurations for each project: with MSVC or Wine headers. With the MSVC headers configuration, it doesn't find "wine/test.h" (since wine/include is not in the include path). Is it a known behavior? With the Wine headers configuration, I don't get those errors (but there are a bunch of warnings concerning signed/unsigned comparisons, for which I'll try to send a patch tonight). Vincent

Nov. 29, 2002

ppdebug

by Michael Sauer

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2 mIc P.S.: sorry if this mail reaches the list twice, but the first one i send with some private e-mail address and the list moderator will (hopefully) erase it (as he does it every time).

Nov. 29, 2002

ppdebug

by Michael Sauer

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2

Nov. 29, 2002

RE: msvcmaker

by Patrik Stridvall

> program/winetest doesn't exist anymore. Creating it empty is > enough for > msvcmaker to work, but is not the proper fix. I don't have the time > right now to check all the winetest references in msvcmaker > (there are > more than i thought). Working on it.

Nov. 29, 2002

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)

by Dan Kegel

Sylvain wrote: >> Thanks! >> It works fine with the version 2.96 I use. > Do you know RedHat's gcc 2.96 has SERIOUS bugs and that its support has > been totally dropped ? Support has been dropped by whom? Not Red Hat; they are still releasing updates for gcc-2.96-RH. The latest was 18 days ago, https://rhn.redhat.com/errata/RHBA-2002-200.html > It's update time. I agree, gcc 3.2[.1] is a better choice than gcc-2.96-RH these days. It is very close to compliance with the C++ ABI, and it's an official Gnu release rather than a vendor snapshot. (I'm building wine for the first time with gcc3.2 today, I hope I'm right about it being a better choice :-) - Dan

Nov. 29, 2002

msvcmaker

by Vincent Béron

Hi all, program/winetest doesn't exist anymore. Creating it empty is enough for msvcmaker to work, but is not the proper fix. I don't have the time right now to check all the winetest references in msvcmaker (there are more than i thought). Vincent

Nov. 29, 2002

RE: Janitorial Projects

by Patrik Stridvall

> What we need next: > 1. a way to run all tests. A batch file would do the job nicely. > Patrik, can that be added to msvcmaker? Planned but not done. However, since you asked for it, I will look into it right away.

Nov. 29, 2002

RE: Winapi_check warnings

by Patrik Stridvall

> On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > > Not really, you haven't run ./configure on that tree have you? > > winapi_check assumes that this is done, but I can fix it if > > it irritates you. > > Oh, I have separate src/build trees, and I was running it in > the source tree. In fact, I _have_ to run it in the source > tree, and then I get the errors... OK. I will fix winapi_check to support that.

Nov. 29, 2002

Re: Janitorial Projects

by Dustin Navea

----- Original Message ----- From: "Francois Gouget" <fgouget(a)free.fr> To: "Dimitrie O. Paun" <dpaun(a)rogers.com> Cc: "Wine Devel" <wine-devel(a)winehq.com> Sent: Friday, November 29, 2002 2:06 PM Subject: Re: Janitorial Projects > > Here's a proposed addition to the Janitorial projects: > > Fix the conformance tests wo that they pass on Windows!!! > > > Rationale: Running just the kernel tests on NT4 I could not help bu > notice that: > * drive crashed and then was would not run unattended and then had many > failures > * environ crashed and then had many failures > * file has one failure > * path has 133 failures! > * process has 4 failures > > Testing on Windows 98 also yielded a crash for environ, followed with 20 > failures, followed with failures for pretty much every Unicode test out > there. > > So according to our tests Windows 98 and NT4 do not conform to the > Windows behavior! > > In other words many of our tests are plain incorrect. I strongly suspect > they were written and tested with Wine and never run on Windows > (actually when I tried compiling them some time ago most of them would > not even compile). > > Now we have a way to pretty easily compile them on Windows. Here's the > procedure: > > * get the Wine source > * run ./tools/winapi/msvcmaker --no-wine > (it's a perl script so you might even be able to do it on Windows) > * make those source accessible by a Windows machine (e.g. export them > via Samba) > * load winetest.dsw in Visual C++ > * hit that build button > > What we need next: > 1. a way to run all tests. A batch file would do the job nicely. > Patrik, can that be added to msvcmaker? > 2. people to fix the tests so that they actually pass on *all* Windows > platforms > 3. volunteers who will run the tests their Windows platform of choice > on a regular basis so that we quickly fix incorrect tests > > The people doing 2 could definitely use the help of a couple of people > doing 3 since they will probably not have access to all Windows > platforms. > > Once the initial fixing is done we will really need people doing 3 to > prevent bad tests from comming back. > Are we going to divide this up by Major (Win98/NT4/2k) or Major and Minor (SP1, SR1, SE, etc)? I can volunteer for Win2k (SP3 if Major and Minor) -Dustin P.S. If needed I could probably find some free space or an old drive to install Win98 Regular on and run some tests...

Nov. 29, 2002

Re: Janitorial Projects

by Francois Gouget

Here's a proposed addition to the Janitorial projects: Fix the conformance tests wo that they pass on Windows!!! Rationale: Running just the kernel tests on NT4 I could not help bu notice that: * drive crashed and then was would not run unattended and then had many failures * environ crashed and then had many failures * file has one failure * path has 133 failures! * process has 4 failures Testing on Windows 98 also yielded a crash for environ, followed with 20 failures, followed with failures for pretty much every Unicode test out there. So according to our tests Windows 98 and NT4 do not conform to the Windows behavior! In other words many of our tests are plain incorrect. I strongly suspect they were written and tested with Wine and never run on Windows (actually when I tried compiling them some time ago most of them would not even compile). Now we have a way to pretty easily compile them on Windows. Here's the procedure: * get the Wine source * run ./tools/winapi/msvcmaker --no-wine (it's a perl script so you might even be able to do it on Windows) * make those source accessible by a Windows machine (e.g. export them via Samba) * load winetest.dsw in Visual C++ * hit that build button What we need next: 1. a way to run all tests. A batch file would do the job nicely. Patrik, can that be added to msvcmaker? 2. people to fix the tests so that they actually pass on *all* Windows platforms 3. volunteers who will run the tests their Windows platform of choice on a regular basis so that we quickly fix incorrect tests The people doing 2 could definitely use the help of a couple of people doing 3 since they will probably not have access to all Windows platforms. Once the initial fixing is done we will really need people doing 3 to prevent bad tests from comming back. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Nov. 29, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Francois Gouget

`On Fri, 29 Nov 2002, Dimitrie O. Paun wrote: > On November 25, 2002 05:39 pm, Francois Gouget wrote: > > However there is no wrapper involved in the above. if you have a > > wrapper, then the load sequence is: wine loads mfcapp.exe.so which is > > the wrapper, and then mfcapp.exe.so then loads mfcapp.dll.so which > > contains the actual application. > > But we have a wrapper already, why do we need two of them? It seems to > me one should be enough, if we can instruct wine to load said libs > before loading the app, no? If you modify wine itself then you should be able to remove the wrapper. However, how will you instruct Wine to load just the right libraries? Note that Wine should not load extra libraries, especially not GDI and stuff, unless it's needed. So you need a way to instruct Wine to do that just for this application. You could do that by writting a wrapper script around Wine (hmm, a wrapper again, different level but still a wrapper), or by having Wine get that information from the .so without dlopening it. > > I say 'mfcapp' because it's a typical case where you need the arapper. > > The reason for this one is that because of C++ you need to link to the > > mfc library in the Unix sense (Winelib does not know how to import > > virtual table pointers because they are variables, not functions). But > > this causes MFC static initializers to run before the dlls it depends on > > have been loaded and initialized. > > Sorry, I have to admit: this linking, importing, etc. is all Chinese to me. > Is this ignorance of importing variables a limitation of Winelib that we > can fix (import libraries?), or is it something fundamentally unfixable? Linking in the unix sense is the act of doing 'gcc -lfoo'. Unix will take care of loading the library foo. Importing is the act of telling winebuild that you want to import a WineLib library, and the act of loading the library is done by Wine using dlopen just before calling the 'WinMain' of your application (i.e. it's done after all the libraries you link with 'in the Unix sense' have been loaded and initialized). For instance you 'import' gdi32, you don't link with it: you never use '-lgdi32' when compiling a WineLib application. However, you have to link with Unix libraries like opengl or curses and you cannot import them (because they don't have the required 'PE' information that winebuild adds in the .spec.c file). So how does it work when you call something like CreateFileA? My understanding of it is that winebuild creates a strampoline for it in the .spec.c file. Then at load time Wine does a dlsym on the appropriate symbol and sets the trampoline to point to the right address. Thus when you call CreateFileA, your code jumps to the trampoline which jumps to the actual CreaFileA implementation. But you cannot create trampolines for variables. When your code tries to access a variable it accesses a specific address. You cannot store a 'jmp' at that address to force it to read stuff from another address. To solve this problem it seems like we would need to replace all variable declarations with code that looks like '*get_variable()' which besides the compilation issues is impossible if the variable access is generated by the compiler itself which is what happens with class virtual tables. > BTW, can you please take a look here: > http://www.dssd.ca/wine/Winelib-Apps.html#visual-mingw > It seems I'm running in the same problem. > > The way I understand it though is a bit different (or so it seems to me): > -- wine calls PROCESS_InitWine (first thing it does in main()) > -- PROCESS_InitWine -> open_builtin_exe_file -> wine_dll_load_main_exe > -- wine_dll_load_main_exe -> dlopen_dll > So this one loads the .so, and this triggers the static initializers to > run, thus calling the statically constructed classes, right? And here > the problem happens. Why? Because the kernel & friends have not yet been > loaded? Yes, I believe the problem is that dlopening your application exe causes all the libraries it is linked with in the Unix sense to be loaded and initialized immediately. Then your exe's static initializers are run which registers with Wine the list of dlls that your application wants to load. So when the CCriticalSection constructor tries to call a Wine function it is likely that the corresponding library has not yet been loaded or initialized. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Nov. 29, 2002

Janitorial Projects

by Dimitrie O. Paun

Folks, I have updated the Janitorial section: http://www.dssd.ca/wine/Wine-Fun.html#janitorial with the list of cross calls from 32->16, and W->A. There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII. Any takers? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.

Nov. 29, 2002

Re: somebody help me identify this bug please

by Jeff Smith

Is it only characters with the acute accent? Is it that your are attempting this using 'dead key' entry on a Spanish keyboard? If this is the case, the problem may be in a recent correction to the Spanish keyboard layout. I will work on this some more when I get a chance, but hopefully someone else will find something sooner. -- Jeff S >From: "ezra daniel" <ezra_daniel(a)hotmail.com> > >Hello, > >At work I use Lotus Notes under Wine. > >I downloaded compiled and installed the new wine version 20021125 and I am >no longer able to type accecented valves, like á é í ó ú. > >Ñ can be typed though correctly. > >With the other version 20021031 I could type accented valves.In fact I went >back to using the older version and worked again so it is obvious it is a >problem in the new wine version. > >Though I am a newbie and know nothing of developing, but I would like to >submit the bug to the proper person so it fixes it back again but I dont >know which section of wine or person deals with this character typing >problem. > >Can anyone point me in the right direction? Thanks in advance. > >-daniel >http://www.debian-gnu.com _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Nov. 29, 2002

Re: Winapi_check warnings

by Dimitrie O. Paun

On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > Not really, you haven't run ./configure on that tree have you? > winapi_check assumes that this is done, but I can fix it if > it irritates you. Oh, I have separate src/build trees, and I was running it in the source tree. In fact, I _have_ to run it in the source tree, and then I get the errors... -- Dimi.

Nov. 29, 2002

RE: Winapi_check warnings

by Patrik Stridvall

> Hi Patrik, > > I get these hundreds of warnings about "config.h": [snip] > First of all, I think they are bogus. Not really, you haven't run ./configure on that tree have you? winapi_check assumes that this is done, but I can fix it if it irritates you. > Second, if I specify the > --cross-call-win32-win16 flag, I expect to see only the problems > I am asking for, no? Shouldn't we silence all other warnings, if > we ask for something in particular? There is a --none option. winapi_check --none --cross-call-win32-win16 It doesn't always work though. Beware. However I fixed --cross-call-win32-win16 to support with my last patch, since I assumed somebody would ask. I was right it seems. Presumably you want the --progress option on as well: winapi_check --none --progress --cross-call-win32-win16

Nov. 29, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

Nov. 29, 2002

Winapi_check warnings

by Dimitrie O. Paun

Hi Patrik, I get these hundreds of warnings about "config.h": [dimi(a)dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16 dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include controls/desktop.c: #include "config.h": file not found controls/desktop.c: #include "config.h" is not a local include controls/edit.c: #include "config.h": file not found controls/edit.c: #include "config.h" is not a local include controls/icontitle.c: #include "config.h": file not found controls/icontitle.c: #include "config.h" is not a local include controls/menu.c: #include "config.h": file not found controls/menu.c: #include "config.h" is not a local include dlls/advapi32/advapi.c: #include "config.h": file not found First of all, I think they are bogus. Second, if I specify the --cross-call-win32-win16 flag, I expect to see only the problems I am asking for, no? Shouldn't we silence all other warnings, if we ask for something in particular? -- Dimi.

Nov. 29, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

On November 29, 2002 01:03 pm, Patrik Stridvall wrote: > With your suggestion above we can, so I like it. :-) Yay!!! I guess the problem is that we the current setup we can not include wine specific headers without having *our* win32 headers in the include path. Bad. Cool thing (me thinks) about my proposal is that it doesn't complicate Winelib use at all. Right now apps need to have a -I$(prefix)/include/wine now that will change to -I$(prefix)/include/win32 The only thing I don't like in my proposal is the win32 name, namely the 32. I guess Win64 will go in the same namespace, as well as win16. This is confusing. What about winxx or even better winapi? > > plus a bunch of other things (like making it easy to use other > > headers for the Win32 API, etc). And best of all, it seems to > > be easily implementable, no? > > "mv" is your friend however the CVS versioning doesn't like it though... We don't have to move anything in the tree, just modify where we install stuff. Of course, this means that you will not be able to use your tree include files in all cases, but I think it's good as a start. -- Dimi.

Nov. 29, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> Alexandre, > > Patrik brought up the header location sometime ago, in this thread: > http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 > > At the time, I thought it is a bit premature, that we have other > things to do. Now I realize that this is one of those highly visible > external things, that would be a _lot_ better to fix before people > start using Winelib. Otherwise will piss people off when we change, > or we will not change because people are already using the headers. True. > Both versions are not good, and I think we can fix them now without > too much pain. > > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers > > It is simple (to understand & implement), clean, and pretty. > And I think it solved Patrik's problem (even if I can't quite > understand what the problem is from the first message :)), It not easy to mix different flavours of the Win32 headers because of include problems. The problem is that is you have since we include wine specific files like: #include "wine/debug.h" we need to have a include path like -I${prefix}/include However now since the Wine version of the standard Win32 header are in ${prefix}/include we get them included as well if we do -I${prefix}/include So if we do for example -I/opt/microsoft/windows/include we get header include collisions. Sure with GNU C on Linux (and presumably) on Windows we can fix that by specifing a correct include order. However with Microsoft C++ we can't do it in a portable way. With your suggestion above we can, so I like it. :-) > plus a bunch of other things (like making it easy to use other > headers for the Win32 API, etc). And best of all, it seems to > be easily implementable, no? "mv" is your friend however the CVS versioning doesn't like it though...

Nov. 29, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dimitrie O. Paun

On November 25, 2002 05:39 pm, Francois Gouget wrote: > However there is no wrapper involved in the above. if you have a > wrapper, then the load sequence is: wine loads mfcapp.exe.so which is > the wrapper, and then mfcapp.exe.so then loads mfcapp.dll.so which > contains the actual application. But we have a wrapper already, why do we need two of them? It seems to me one should be enough, if we can instruct wine to load said libs before loading the app, no? > I say 'mfcapp' because it's a typical case where you need the arapper. > The reason for this one is that because of C++ you need to link to the > mfc library in the Unix sense (Winelib does not know how to import > virtual table pointers because they are variables, not functions). But > this causes MFC static initializers to run before the dlls it depends on > have been loaded and initialized. Sorry, I have to admit: this linking, importing, etc. is all Chinese to me. Is this ignorance of importing variables a limitation of Winelib that we can fix (import libraries?), or is it something fundamentally unfixable? BTW, can you please take a look here: http://www.dssd.ca/wine/Winelib-Apps.html#visual-mingw It seems I'm running in the same problem. The way I understand it though is a bit different (or so it seems to me): -- wine calls PROCESS_InitWine (first thing it does in main()) -- PROCESS_InitWine -> open_builtin_exe_file -> wine_dll_load_main_exe -- wine_dll_load_main_exe -> dlopen_dll So this one loads the .so, and this triggers the static initializers to run, thus calling the statically constructed classes, right? And here the problem happens. Why? Because the kernel & friends have not yet been loaded? -- Dimi.

Nov. 29, 2002