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

win3.1 printer drivers

by Ivan Leo Murray-Smith

Are win3.1 printer driver still supported by wine? Ivan.

Jan. 15, 2004

Re: More Vacation backlog

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> appended patch opens the devicefile connected to a drive as connected >> by the user in ~/.wine/config [Drive X] "Device" = "/dev/yyy". The >> appropriate action on that file ( read, write, set_file_pointer, ...) >> succeed according the the righte the user has on that device. Alexandre> The device should be opened like a normal file, using the Alexandre> create_file request. Then there wouldn't be any need to Alexandre> change the server device object (which is a nasty hack that Alexandre> should be removed). Alexandre: Do I understand your last sentence right? server/device.c should disapear? It will probably take some time until I understand the implications. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 15, 2004

Re: Better cpuid support

by Robert Lunnon

On Friday 16 January 2004 04:16, Alexandre Julliard wrote: > Robert Lunnon <bobl(a)optushome.com.au> writes: > > This is true, but it is not very time consuming. I had considered > > caching the cpuid results which would eliminate the multiple handling but > > didn't feel it was worth the effort. This function does not tend to get > > called often in windows programs (Usually once) but If you like I'll add > > the caching. > > All that extra work is simply because you are adding abstractions > where none are necessary. It looks like a bad case of Not Invented > Here syndrome: you have already submitted that code a number of times, > and I have already explained that it's way too complex for what we > need, so I didn't put it in. Now someone else has done a simple > implementation that works fine, and you are trying to replace it all > once again with your original code that I already rejected. If you > want to improve the cpuid support, please improve the existing code; > as long as you keep pushing your all singing all dancing new > implementation you won't get anywhere. This is an incorrect charaterisation, but since you hold the keys to the cvs do as you wish. BTW: As a side note to the maintainers of rewind, the rewind project is welcome to use all my patches also. Bob

Jan. 15, 2004

Re: winecfg: a patch to review

by Kirk Ruff

On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote: > On Thu, 15 Jan 2004, Robert van Herk wrote: > > > We (me and cmorgan) were thinking about dropping that tabsheet :-)... > > That's a good idea, the current UI for app-specific settings is terrible. I agree it is horrible, but I wanted to try to implement something. I also agree that that tab should be dropped and all handeled within 1 tab. At least I didn't put a lot of effort in to this. If you guys have any up coming patches, any idea how long before you will be ready to send them in?

Jan. 15, 2004

Re: Oleaut32 tests fail

by Jon Griffiths

Hi, >Running the oleaut32 tests shows that vartype and vartest are >failing. >Has someone an idea about these ? Your (presumably early) version of oleaut32.dll doesn't support the VT_DECIMAL type. I'll update the tests shortly. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 15, 2004

Re: winecfg: a patch to review

by Dimitrie O. Paun

On Thu, 15 Jan 2004, Robert van Herk wrote: > We (me and cmorgan) were thinking about dropping that tabsheet :-)... That's a good idea, the current UI for app-specific settings is terrible. -- Dimi.

Jan. 15, 2004

Re: winecfg: a patch to review

by Robert van Herk

Hi... I understand that you changed something about the app-specific tab-sheet? We (me and cmorgan) were thinking about dropping that tabsheet :-)... So I am not sure to what extend your changed are useful in the long term...

Jan. 15, 2004

Re: winecfg: a patch to review

by Mike Hearn

On Thu, 15 Jan 2004 12:43:33 -0500, Kirk Ruff wrote: > I forgot about that and I had wondered what those functions were, well > now I know. I will try to make it work with that later today if I have > some free time. Yeah. In order to implement unlimited undo you need to operate in terms of transactions. > Also, one thing that I have a question about; If I remove an application > from the 'Applications' tab, shouldn't it not show up in the 'Libraries' > tab? This is something I tried to look into but I didn't get too far. Blah, appdefaults are kind of a mess. I had it working but you had to set the app on one tab then alter settings on another which wasn't great UI. Someone else submitted a patch which started moving appdefaults into each relevant tab separately. I guess we haven't removed the old one first. I'm still not convinced about the ui for this yet.... thanks -mike

Jan. 15, 2004

activate window

by Shiming Dong

Hi there: I met with one problem. I try to send a simulated keystroke to another application (such as Notepad) to invoke one of its functions, but when I minimize the window of "Notepad", the message cannot be received even I used the SetFocus() and SetActiveWindow() function. When it is maximized, it works. Anyone can help? Here are my codes: int main( ) { HWND hwnd = FindWindow(NULL, "Untitled - Notepad"); short f3_key = VK_F3; UINT scancode = MapVirtualKey(f3_key, 0); if (hwnd!=NULL){ printf("Notepad is running!\n"); SetActiveWindow(hwnd); SetFocus(hwnd); } PostMessage(hwnd, WM_SYSKEYDOWN, f3_key, scancode); PostMessage(hwnd, WM_SYSCHAR, f3_key, scancode); PostMessage(hwnd, WM_SYSKEYUP, f3_key, scancode); return 0; } --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Jan. 15, 2004

CVS problem: stale lock?

by Sami Aario

Hi all, I'm getting this message over and over while attempting an update from the wine cvs repository: "cvs server: [13:31:41] waiting for wineowner's lock in /home/wine/wine" I'm guessing a CVS process has died and left a stale lock in the repository. Could someone check it out?

Jan. 15, 2004

signing off -- good luck

by Jeremy Shaw

Hello, I am unsubscribing from wine-devel since I am no longer actively doing any wine development work. However, if any question arise about the patches I submitted recently, please feel free to email me. Good luck and have fun at wineconf! Jeremy Shaw.

Jan. 15, 2004

Re: Add iccvid.spec to winapi_check

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > After DLL separation is complete, adding these will no > longer be necessary, right? Well, it's really winapi_check that needs to be made smarter. 99% of the contents of that file are redundant already and could be determined automatically. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2004

Re: Better cpuid support

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > This is true, but it is not very time consuming. I had considered caching the > cpuid results which would eliminate the multiple handling but didn't feel it > was worth the effort. This function does not tend to get called often in > windows programs (Usually once) but If you like I'll add the caching. All that extra work is simply because you are adding abstractions where none are necessary. It looks like a bad case of Not Invented Here syndrome: you have already submitted that code a number of times, and I have already explained that it's way too complex for what we need, so I didn't put it in. Now someone else has done a simple implementation that works fine, and you are trying to replace it all once again with your original code that I already rejected. If you want to improve the cpuid support, please improve the existing code; as long as you keep pushing your all singing all dancing new implementation you won't get anywhere. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2004

Re: winecfg: a patch to review

by Kirk Ruff

(sent this to the wrong email address, sorry) On Thu, 2004-01-15 at 07:08, Mike Hearn wrote: > Why do you explicitly null terminate this string? It shouldn't be needed, > right? Not sure what the deal was but I was getting segfaults unless I null terminated it myself. Now, it doesn't, so must have been something stupid that I had done. > Ideally of course this stuff would go via the transaction system (so in > the hypothetical future users can undo it, and we can delay it until the > user hits apply in explicit-apply mode). I forgot about that and I had wondered what those functions were, well now I know. I will try to make it work with that later today if I have some free time. Also, one thing that I have a question about; If I remove an application from the 'Applications' tab, shouldn't it not show up in the 'Libraries' tab? This is something I tried to look into but I didn't get too far. I switched to SHDeleteKey, and once I figure out the transaction system I will get that going. Thanks for your time to review it, I hope to add some more functionality soon. This patch seems to be mostly a copy-paste from another function.

Jan. 15, 2004

Re: Need help debugging ...

by Mike Hearn

On Thu, 15 Jan 2004 15:36:17 +0200, Boaz Harrosh wrote: > Just a long shot. I had a problem with my own program. where I would > crush on a bug as so: > > in the code at global scope I had: > > SomeStruct table[] = { > {1,2,3,4} > {1,2,3,4} > ..... > {1,2,3,4} > } ; > // Note that the the last null record is missing > > now the startup code will load this table until seeing null in first > field. That never crashed on windows (5 years old code). But on Linux it > would (same PE binary). Is it possible that static uninitialized data > (in a data segment) is set to 0 on Windows and is untouched in Linux/wine? That sounds like the sort of bug it might be. I'm pretty sure Linux initializes static data to zero, but anyway, it shouldn't matter right because even if ELF binaries are different in this regard we are loading keeper.exe - a PE binary. One thing it could be is if we load the data segments in a different way to Windows I guess..... something like that

Jan. 15, 2004

Re: Build error in current cvs.

by Ivan Leo Murray-Smith

Patches http://www.winehq.com/hypermail/wine-patches/2004/01/0201.html and http://www.winehq.com/hypermail/wine-patches/2004/01/0202.html fix the problem. Ivan.

Jan. 15, 2004

Re: Add iccvid.spec to winapi_check

by Hans Leidekker

On Thursday 15 January 2004 16:07, Vincent Béron wrote: > Changelog: > Yet another new spec file added to winapi_check/modules.dat, this time > iccvid.spec. After DLL separation is complete, adding these will no longer be necessary, right? -Hans

Jan. 15, 2004

Partial MDI rewrite

by Dmitry Timoshkov

Hello all, here is a result of my work aimed to merge MDI child creation with common window creation code. The rewrite allows MDI children to have WS_EX_MDICHILD style set on WM_CREATE and therefore properly get lParam from MDICREATESTRUCT. MDICREATESTRUCT is now gets A<->W translated (translation 16-bit windows is still missing). Please give it a try with your favorite MDI application and report the results you get. The patch includes a simple test case, which passes on win9x and win2000 SP4. Thanks. -- Dmitry.

Jan. 15, 2004

dropped mouse movement when playing CS while running another application with Wine

by Jan Brunner

Hello guys. I got CS running quite playable with and without Steam but with Steam mouse movement gets dropped sometimes (the sensitivity feels much lower). I experimented a bit and found out that this problem happens whenever Wine is running more than just hl.exe (e.g. CS + Winamp). In case this helps: Probably a bit of movement gets dropped while running CS only, too: Sensitivity 4.1 with Wine is about the same as 4.0 in Windows. It's constant though, so it doesn't matter. Any ideas on what causes the problem and how to fix it? -- Best regards, Jan Brunner <brunner(a)intergga.ch>

Jan. 15, 2004

Fwd: Congratulations with your wine product.

by Dimitrie O. Paun

Some good words for a happy user... ---------- Forwarded Message ---------- Subject: Congratulations with your wine product. Date: January 15, 2004 09:28 am From: Pascal Pype <pascal.pype(a)skynet.be> To: wine-faq(a)winehq.org Hello maintainers and developers of wine, The performance and configuartion of your product have been tremendously enhanced with respect to an experimental version I used nearly three years ago. There were two win3.1 applications that were written with turbo pascal for windows quite some time ago. When I tried to run those from within a wine environment , the performance of wine was so poor that the applications were useless when run in a *NIX environment. (linux , freeBSD) In a linux user & developer edition , I read an article about wine and its team leader Alexandre Julliard. The article have me a good impression , so I decided to give wine another try. Here are the conclusions: 1. outstanding documentation, 2. flawless install and configuration, 3. one out of the two windows applications works exactly as it did on win3.1 whilst the other does its job for about 60% of the total functionality without any fine tuning of the wine configuration. CONGRATULATIONS AND KEEP UP THE EXECELLENT WORK!!! Yours scincerely, Pype pascal. ------------------------------------------------------- -- Dimi.

Jan. 15, 2004

Re: Need help debugging ...

by Boaz Harrosh

Mike Hearn wrote: >IIRC keeper makes only one or two API calls before crashing, both of those >calls are trivial and succeed (setting a timer or something I think) so >it's more likely to be to do with the layout of an in memory struct or >something. Remember that the TEB is stored in %fs, if you see references >to that register. > > Just a long shot. I had a problem with my own program. where I would crush on a bug as so: in the code at global scope I had: SomeStruct table[] = { {1,2,3,4} {1,2,3,4} ..... {1,2,3,4} } ; // Note that the the last null record is missing now the startup code will load this table until seeing null in first field. That never crashed on windows (5 years old code). But on Linux it would (same PE binary). Is it possible that static uninitialized data (in a data segment) is set to 0 on Windows and is untouched in Linux/wine?

Jan. 15, 2004

Build error in current cvs.

by Ivan Leo Murray-Smith

After a cvs update, there is this lovely build error, while building gdi, is it a problem with the recent gdi patches that have just got in or am I doing something wrong? make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o dispdib.spec.c --main-module gdi32.dll --spec dispdib.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o dispdib.spec.o dispdib.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -o gdi.exe.spec.c --heap 65520 --main-module gdi32.dll --res version16.res --spec ./gdi.exe.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi.exe.spec.o gdi.exe.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o wing.spec.c --main-module gdi32.dll --spec wing.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.spec.o wing.spec.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi16.o bidi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi16.o gdi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.o wing.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/bitblt.o ../../graphics/bitblt.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/dispdib.o ../../graphics/dispdib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/env.o ../../graphics/env.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/escape.o ../../graphics/escape.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/fontengine.o ../../graphics/fontengine.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/mapping.o ../../graphics/mapping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/painting.o ../../graphics/painting.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/path.o ../../graphics/path.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/bitmap.o ../../objects/bitmap.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/brush.o ../../objects/brush.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/clipping.o ../../objects/clipping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dc.o ../../objects/dc.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dcvalues.o ../../objects/dcvalues.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dib.o ../../objects/dib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/enhmetafile.o ../../objects/enhmetafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/font.o ../../objects/font.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/gdiobj.o ../../objects/gdiobj.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/metafile.o ../../objects/metafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/palette.o ../../objects/palette.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/pen.o ../../objects/pen.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/region.o ../../objects/region.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/text.o ../../objects/text.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi.o bidi.c bidi.c: In function `BIDI_Reorder': bidi.c:75: error: `WINE_GCPW_DIR_MASK' undeclared (first use in this function) bidi.c:75: error: (Each undeclared identifier is reported only once bidi.c:75: error: for each function it appears in.) bidi.c:77: error: `WINE_GCPW_FORCE_LTR' undeclared (first use in this function) bidi.c:80: error: `WINE_GCPW_FORCE_RTL' undeclared (first use in this function) bidi.c:83: error: `WINE_GCPW_LOOSE_LTR' undeclared (first use in this function) bidi.c:86: error: `WINE_GCPW_LOOSE_RTL' undeclared (first use in this function) make[2]: *** [bidi.o] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls' make: *** [dlls] Error 2 [ivan(a)localhost wine]$

Jan. 15, 2004

Re: Need help debugging ...

by Mike Hearn

On Thu, 15 Jan 2004 01:00:32 +0100, Frank Schruefer wrote: > Hey list, > > I like to learn how to fix wine problems myself and am trying to track down an exception > occuring while starting good old 'Dungeon Keeper'. Good luck! Please don't be discouraged if you can't crack this one though, both me and Lionel have looked at Dungeon Keeper (1 and 2) and couldn't figure out why it doesn't work. Lionel has been a Wine hacker for 5+ years now! If you can't get DK to work, or are finding it too frustrating, perhaps move on to another program and see if it's any easier? > For now I have two problems: > 1. When I invoke the game with 'wine' and with 'winedbg' I get different exception messages > (traces see below), why? You don't, you get the same crash: from just wine: > Unhandled exception: page fault on write access to 0x00000000 in 32-bit > code (00406062). from winedbg: > First chance exception: page fault on write access to 0x00000000 > in 32-bit code (0x00406062). Unhandled vs first chance, hmm, how to explain this. Well in the debugger you can trap *all* exceptions, even if the program itself may in turn catch that exception and deal with it. So it's called a first-chance because you the debugger get the first chance to deal with it. Unhandled just means there was an exception and the program didn't do anything with it, so it falls back to the debugger (in Windows you would see the crash dialog). Notice how the numbers are the same, and the fault (writing to null) is the same. You can disassemble this code to see what caused the crash using "disas 0x406062" but I seem to remember the results were inconclusive - as they often are with disassembly. > 2. How to compile debug information into the 32bit DLL's so I don't get > 'No debug information in 32bit DLL' anymore and maybe some better info? > I tried 'configure --enable-debug && make depend && make && su -c "make install"' to > no avail. They have debugging info in, but unfortunately there has been breakage in the debugger recently which has not yet been fixed in CVS. This is very bad :( EricP sent a patch here which works great for me and fixed all my debugger problems, try looking in the archives for Jan and December looking for it (it was sent to wine-devel not wine-patches iirc). For now try setting WINELOADER to the path to your actual wine binary (wine-pthread) Eric, could you please submit that patch? Even if it's not correct, having the debuggers out of action like this is causing big problems. > I compiled 'fixme's into the 'SetThreadExecutionState' and 'VerSetConditionMask' funcs to > see where the exceptions occure but it seems the methods aren't even called at all because > the messages don't get printed out (or need the fixme messages switched on somewhere for > that particular dll?). No, they aren't called, they just happen to be the closest exported symbols the debugger could find. In general the names given to you when there are no debug symbols are useless. Look: 1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL2.DLL) see the +0x17fd here? That means the crash occurred in some code a long way from the start of that function, who knows where without debug symbols though. > I also tried to start with --debugmsg +all in which case the output is overwriting the > winedbg command line interface and crashing it when trying to exit with CTRL-C > and CTRL-D. Only killall -9 wine-pthread helps then. Redirect the output to a logfile: wine --debugmsg +all keeper.exe 2>log Useful channels are +relay which show every API call, +snoop which does the same but between non-wine DLLs (so it's a bit crashy but should be fine here) and so on. IIRC keeper makes only one or two API calls before crashing, both of those calls are trivial and succeed (setting a timer or something I think) so it's more likely to be to do with the layout of an in memory struct or something. Remember that the TEB is stored in %fs, if you see references to that register. > The wine I'm using is fresh from CVS as of 15. Jan. 2004 but I had the problem with earlier > versions too. Yes, keeper has never worked for me :( thanks -mike

Jan. 15, 2004

Re: winecfg: a patch to review

by Mike Hearn

Yo, The patch looks good except for this bit. On Wed, 14 Jan 2004 18:20:44 -0500, Kirk Ruff wrote: > + sprintf(key, WINE_KEY_ROOT "\\AppDefaults\\%s\0", currentApp); Why do you explicitly null terminate this string? It shouldn't be needed, right? > + return_if_fail( > + RegDeleteKey(HKEY_LOCAL_MACHINE, key) == ERROR_SUCCESS You can't use RegDeleteKey to recursively delete subkeys, it's not that intuitive. You need to use SHDeleteKey. See MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… It's in shlwapi so you may need to do add that to the link line in the Makefile. Ideally of course this stuff would go via the transaction system (so in the hypothetical future users can undo it, and we can delay it until the user hits apply in explicit-apply mode). Once you fixed that, please do submit this to wine-patches! :) thanks -mike (who wrote most of winecfg last September so feel free to ask him questions :-)

Jan. 15, 2004

Re: Unicode and CP_SYMBOL question. [?? Probable Spam]

by Dmitry Timoshkov

"Rein Klazes" <rklazes(a)xs4all.nl> wrote: > [?? Probable Spam] > > Your spam filter needs to be educated about wine-devel ;-) That's not my spam filter (it behaves differently), some host in e-mail chain marks every e-mail from you on this list with that addition in the subject line. > > Apparently Windows uses something different. Probably we have to change > > our internal map for Symbol encoding > > I will try a few other Windows versions first. It looks to me that > Symbol encoding is not a real encoding at all apart from the 0xf000 > offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably > for that reason.. Sounds like a good idea. Please test and report here what you will find. -- Dmitry.

Jan. 15, 2004