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

[RFC] Wine headers
by Dimitrie O. Paun Nov. 30, 2002

Nov. 30, 2002

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. 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 :)), 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? -- Dimi.

2 1

Partial success report: Toshiba 220CDS electronic manual
by Dan Kegel Nov. 30, 2002

Nov. 30, 2002

http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe is an "online manual" for the Toshiba 220CDS laptop. I unzipped it with Linux unzip, then ran its setup and the app itself with Wine20020605-2 from Red Hat 8. Both ran acceptably well, although I did get a few warnings like: err:ntdll:RtlpWaitForCriticalSection section 0x4011a4a8 "../../scheduler/syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) tid=08078300 fixme:scroll:ScrollBarWndProc Unimplemented style SBS_SIZEBOX. and there were display anomolies (mostly, areas of the window not being cleared, so old text piled up). Also, I had to grep through the registry for 'toshiba' to see where the darn thing installed itself. I'm looking forward to trying with a more modern wine, but don't have time at the moment. - Dan

2 2

[RFC] Winelib enhancements
by Dimitrie O. Paun Nov. 29, 2002

Nov. 29, 2002

Folks, You are probably familiar with the Winelib page: http://www.dssd.ca/wine/Winelib-Apps.html where I describe what one needs to do to compile a Win32 application under Winelib. My original motivation for doing the work was to better understand what inconveniences one has to go through to do the port, and what we can do to eliminate them. Here are my thoughts on the subject, in the build order: Compilation This step require the addition of some flags, and the potential removal of others. Simple to do, and if there is a configure script, quite doable. However, these tweaks are really annoying in the initial stages of the port, and would be so nice if we had a nice compiler wrapper (call it wcc) that would do that behind the scenes, so that the only modification to the makefile would be: -CC=gcc +CC=wcc Q: Alexandre, would you accept such a utility in the tree? Resources These ones are nasty. Programs typically use the windres compiler that compiles a .rc file into a .o file directly, which is later simply linked into the application. We go a different route, by sticking the resources in the .spec.c files, and this entails non-trivial modifications to the makefiles. The ideal option would be to provide a windres compatible command line mode for wrc, so that we can do: -RC=windres +RC=wrc This would mean moving the resources out of the .spec.c file, and exporting the resources variable so we can link it into the .spec.c file. Q: Alexandre, is this acceptable? Does it warrant discussion? Linking Another tricky step, with multiple problems 1. We are missing import libraries. As a result, we can not link with -lwinspool, we need to link with -lwinspool.drv Small change, but it can present nasty problems if you want to submit the patch upstream, to the application maintainers. I understand this one is already on Alexandre's TODO, so we should have a solution to it not before too long. 2. Our linking process is quite different from the "standard" one which uses gcc/ld to do the linking. We generate intermediate files (.spec.c files), and use different flags. Again, the solution for this (to at least help initial porting efforts) would be a wrapper script that does this, that can be used instead of ld. And so the question comes back again, to haunt us: is this needed/wanted/acceptable? Running This is a new step in the process that we introduce. Currently we produce a shared library that requires a wrapper script to start it up. Many considers this (and I might say rightfully so) ugly/bloat/etc. The ideal situation would be to generate regular executables, like all well behaved libraries. Here are a few solutions: 1. An interim step is to improve the wineapploader script so that it can be used by all apps. This is a simple thing to do at the moment, but does not solve the root cause, it just ease the pain a bit. This way you don't need to fight the application maintainers to get such script included in their tree, and having to answer the eternal questions: "WTF is this? I thought that compiling under Winelib would yield an executable that did not need wine. What's the difference as compared to running the Win32 binary directly?" 2. Fix the build process so that we can actually generate regular executables. Thing is, I don't know what's involved in doing so, and I'm afraid only Alexandre knows the answer (hint, hint :)). So a discussion on this topic is needed, just to figure where we want to go from here. Now, this message is meant to elicit discussion on these topics, so that at the end of the day I can gather the conclusions, and track them on TODO page. So do not hesitate to send in your comments. :))) Thanks for your attention, and sorry for the long message. -- Dimi.

5 14

ppdebug
by Michael Sauer Nov. 29, 2002

Nov. 29, 2002

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).

2 1

RE: Janitorial Projects
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

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

1 0

RE: Wine conformance tests with MSVC headers
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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.

1 0

Wine conformance tests with MSVC headers
by Vincent Béron Nov. 29, 2002

Nov. 29, 2002

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

1 0

ppdebug
by Michael Sauer Nov. 29, 2002

Nov. 29, 2002

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

1 0

RE: msvcmaker
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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.

1 0

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
by Dan Kegel Nov. 29, 2002

Nov. 29, 2002

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

1 0

msvcmaker
by Vincent Béron Nov. 29, 2002

Nov. 29, 2002

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

1 0

RE: Janitorial Projects
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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.

1 0

RE: Winapi_check warnings
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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.

1 0

Re: somebody help me identify this bug please
by Jeff Smith Nov. 29, 2002

Nov. 29, 2002

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

1 0

RE: Winapi_check warnings
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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

2 1

Winapi_check warnings
by Dimitrie O. Paun Nov. 29, 2002

Nov. 29, 2002

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.

1 0

RE: [RFC] Wine headers
by Patrik Stridvall Nov. 29, 2002

Nov. 29, 2002

> 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...

2 1

wglCreateLayerContext?
by Mike Hearn Nov. 29, 2002

Nov. 29, 2002

Hi, This OpenGL method is currently a stub, looking at the MSDN documentation I can't see why this is the case given the fairly complete GL implementation Wine has. Is it that we cannot handle layering properly in X or something? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 4

somebody help me identify this bug please
by ezra daniel Nov. 29, 2002

Nov. 29, 2002

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. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: final int21 move
by Jukka Heinonen Nov. 29, 2002

Nov. 29, 2002

This patch series starts to look more like what it should be. Previous bugs seem to have been fixed and dependencies between winedos and other dlls have been reduced close to minimum. However, I still find some things that I don't particularly like: - The series is actually one big patch divided into multiple files and not a series of incremental changes. The first patch in series breaks DOS3Call and error reporting of some functions and these are only fixed in later patches. - Old int21 functions contain some obvious bugs that really should be fixed at the same time the code is migrated to winedos. - Move to winedos should not only migrate code but it should also try to rewrite code so that it has better comments, it is more readable and it uses simpler constructs. This patch series really messes up already complicated code. Intendations are irregular and weird. Many newlines are missing. Some internal functions use INT21_ prefixes and some don't. Functions that were implemented as separate helper functions are moved inside int21 main switch case. Three nested levels of switches are used without even proper indentation. And that comment about shooting people is tasteless and really doesn't belong to Wine. I just don't find the quality of this patch acceptable. I don't decide these things but my personal opinion is that I would rather rewrite this patch series than see it accepted in its current state. I wouldn't mind if Nog or someone else works on int21 migration (that's why I haven't posted int21 patches already) but I don't see why I ought to lower my quality requirements due to this fact. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: cabinet.dll broken?
by Tapio Kautto Nov. 29, 2002

Nov. 29, 2002

Could cabinet be set to: "cabinet" = "native,builtin" automatically by wineinstall as long as it does not work the way expected? Tapio On Thursday 28 November 2002 12:59, Patrik Stridvall wrote: > > I'm trying to install MS Office 2000 on wine-20021125. > > > > I get an error from Office installer: > > > > Internal error 2352. Please contact Product support. > > > > I found an advice to repair my cabinet.dll in Microsoft Support pages. > > > > The file is in ~/c/windows/system, and it's readable. Does > > anyone else have > > problem with this? > > Well. It might be that since very recently, Wine has builtin > stub implementation of cabinet.dll. > > Of course it shouldn't be used automatically if have a cabinet.dll, > since I guess most people (including you) have a: > > [DllOverrides] > ; default for all other dlls > "*" = "native, builtin, so" > > entry in their config file. > > You can force cabinet to native with > wine --dll cabinet=n > though.

1 0

Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
by Dustin Navea Nov. 29, 2002

Nov. 29, 2002

Vincent, Alexandre, and Dimi Grrr, Im really starting to not like Linux's PPPoE support... I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that they fix problems with my setup... so until next Wednesday I will probably just lurk on the lists -Dustin

2 2

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch Nov. 29, 2002

Nov. 29, 2002

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

Re: Last one for today :-)
by Vincent Béron Nov. 28, 2002

Nov. 28, 2002

Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit : > re-reHi... > > This patch implements the 'GetRenderTarget' method for the IDirect3DDevice > COM object. It is independant from all previously submitted patches (but to > prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix). > > With this series of patch, the Boids demo from the DX6 SDK is now running > (it's not working because we are lacking some D3D code, but at least it does > not crash :-) ). > > Changelog: > - implement GetRenderTarget A bit too much work on your part I bet, as you forgot to attach the patch ;-) Vincent

1 0

wine & preempt patch (fwd)
by Matthias Rieber Nov. 28, 2002

Nov. 28, 2002

Hi, is there are known issue with the preempt patch for the kernel? When I apply that patch, non-open-gl games doesn't run smooth, without the patch they run nearly smooth (especially StarCraft & BaldursGate). OpenGL games are alway fine. matthias

1 0