wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

[latest cvs] Another GTA3 error
by erwin wolff 15 May '03

15 May '03

Hi, When testing GTA3 I discovered another error. This time it is a directx input error: fixme:dinput:JoystickAImpl_GetDeviceState len 272 is not sizeof(DIJOYSTATE), unsupported format. It is a rather strange error since I haven't got a joystick connected to my computer. :? I also can't move my mouse. (USB Logitech mouse) I almost know for certain that this error is the cause of it.

2 1

Re: Resend - PATCH - Cleanup cygwin shortcuts when doing make clean
by Alexandre Julliard 15 May '03

15 May '03

Steven Edwards <Steven_Ed4153(a)yahoo.com> writes: > Changelog: Make "make clean" on cygwin remove .lnk files I don't think we want to remove all .lnk files, only the ones we created. I added a clean: target in the dlls dir, please let me know if you notice left over files in other directories too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Crash on imm32
by Raphaël Junqueira 15 May '03

15 May '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, today when i run warcraft3 demo, i have a crash in imm32! here are the traces: - -=(FeniX as fenix@DarkBluE)-(on tty1)-(at 10:00:12)=- -={$:'/usr/src/wine/Program Files/Warcraft III Demo'}=->wine --debugmsg +imm War3Demo.exe trace:imm:DllMain 0x42120000, 1, (nil) trace:imm:DllMain 0x42120000, 2, (nil) trace:imm:DllMain 0x42120000, 2, (nil) fixme:d3d:IDirect3D8Impl_CreateDevice Requested full screen support not implemented, expect windowed operation fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x404309b8)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 21) trace:imm:DllMain 0x42120000, 2, (nil) trace:imm:DllMain 0x42120000, 2, (nil) trace:imm:DllMain 0x42120000, 2, (nil) trace:imm:DllMain 0x42120000, 2, (nil) fixme:win32:CreateIoCompletionPort (0xffffffff, (nil), 00000000, 00000000): stub. trace:imm:DllMain 0x42120000, 2, (nil) trace:imm:DllMain 0x42120000, 2, (nil) fixme:imm:ImmGetContext (0x10021): stub fixme:imm:ImmGetOpenStatus ((nil)): semi-stub looking a the code i can see: /*********************************************************************** * ImmGetContext (IMM32.@) */ HIMC WINAPI ImmGetContext(HWND hWnd) { FIXME("(%p): stub\n", hWnd); return (HIMC)root_context; } /*********************************************************************** * ImmGetOpenStatus (IMM32.@) */ BOOL WINAPI ImmGetOpenStatus(HIMC hIMC) { InputContextData *data = (InputContextData*)hIMC; FIXME("(%p): semi-stub\n", hIMC); return data->bOpen; } with the debugger attached, i can see that data is NULL; Why ? Because root_context is a static var init to NULL!!!! And it can be only valued by ImmAssociateContext (who isn't called as seen in traces) Anyone have an idea why its broken today ? Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+wfllp7NA3AmQTU4RAqHkAJ0cwjkFganWJfl1/I5zPxw83Wn+rACghKCz wEG3EUf9KONNQucVLO3wfT4= =kX2/ -----END PGP SIGNATURE-----

4 5

cvs broken ?
by Stefan Leichter 15 May '03

15 May '03

Hello, building wine from current cvs fails for me with: gcc -c -I../../../wine/dlls/d3d8 -I. -I../../../wine/include -I../../include -I/usr/X11R6/include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o cubetexture.o ../../../wine/dlls/d3d8/cubetexture.c ../../../wine/dlls/d3d8/cubetexture.c: In function `IDirect3DCubeTexture8Impl_PreLoad': ../../../wine/dlls/d3d8/cubetexture.c:132: `GL_TEXTURE_CUBE_MAP' undeclared (first use in this function) ../../../wine/dlls/d3d8/cubetexture.c:132: (Each undeclared identifier is reported only once ../../../wine/dlls/d3d8/cubetexture.c:132: for each function it appears in.) make[2]: *** [cubetexture.o] Error 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Error 2 I am building on SuSE 7.3. The closes matches for the missing constant are ? /usr/include/GL/glext.h:#define GL_TEXTURE_CUBE_MAP_ARB 0x8513 /usr/include/GL/glext.h:#define GL_TEXTURE_CUBE_MAP_EXT 0x8513 My current glext.h is from the package mesa-devel-3.4.2-42. Am I right so far? Bye Stefan

2 1

Debugging quick question
by Ann and Jason Edmeades 15 May '03

15 May '03

I know I should know this, but can you programatically turn tracing on and off for a specific channel? (Alternatively except using winedbg is there any way of activating trace for a running process)? Regards, Jason

2 1

Re: edit - fix WantReturns (Win BUG)
by Rein Klazes 14 May '03

14 May '03

On Sun, 11 May 2003 20:20:55 -0600, you wrote: > It looks like Windows has an old BUG in Edit control when handling WM_GetDlgCode message. > It always returns 0x8D no mater what the style and and properties of a window is. > Interesting enough, Delphi relays on this behavior. > > Vitaliy Margolen > > changelog: > - controls/edit.c > fix problem with capturing [return] keys in multi-line edits > Vitaliy, This is not right. A edit-listboxcombo, used in Newsbin to enter filter expressions, gives this result in spy++: | <00706> 0002022C P WM_KEYDOWN nVirtKey:VK_RETURN cRepeat:1 ScanCode:1C fExtended:0 fAltDown:0 fRepeat:0 fUp:0 [wParam:0000000D lParam:001C0001 time:14:25:17.823] | <00707> 0002022C S WM_GETDLGCODE wParam:0000000D lParam:0012FD88 | <00708> 00020230 S .CB_GETDROPPEDSTATE wParam:00000000 lParam:00000000 | <00709> 00020230 R .CB_GETDROPPEDSTATE fDropped:False [lResult:00000000] | <00710> 0002022C R WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089] | <00711> 0002022C S WM_GETDLGCODE wParam:00000000 lParam:00000000 | <00712> 0002022C R WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089] Needless to say this stopped working properly when updating with CVS:(( It is not the CB_GETDROPPEDMESSAGE but the return value that matters here. Attached I revert your patch for this special case. I hope that it still solves your problem and that you got the other cases right. Changelog: controls/ : edit.c Revert the previous patch for capturing keys in an edit-listbox combo. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

dvdshrink103
by hal-9000-＠t-online.de 14 May '03

14 May '03

wine: main.c:572: DDRAW_width_bpp_to_pitch: Assertion `bpp != 0' failed. got this error when trying to run dvdshrink103 completely! what does it mean, hoe could i solve this problem! thanks in advance - thorsten

2 1

Re: winedos / Migrate current drive routines and add date conversions
by Jukka Heinonen 14 May '03

14 May '03

György 'Nog' Jeney wrote: > Could someone please explain to me why it is not possible to reimplement > DRIVE_GetCurrentDrive in winedos like this, it looks quite simple and > straight forward: > > int GetCurrentDrive() > { > char root[MAX_PATH]; > GetCurrentDirectoryA(MAX_PATH, root); > return toupper(*root) - 'A'; > } > > and the same question for DRIVE_SetCurrentDrive: > > void SetCurrentDrive(int drive) > { > char drive[] = "A:"; > *drive += drive; > SetCurrentDirectoryA(drive); > } Well, I thought SetCurrentDirectory didn't work like that, but if it does then there is no reason why that implementation couldn't be used. GetCurrentDrive ought to verify that second character is indeed ':' (preparing for UNC names) but that should work, too. Using wide character versions would be preferred, though. So, I guess those routines should work. Perhaps I should rewrite my patch in order to make use of this kind of routines instead of exporting stuff from ntdll. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Re: Crash on imm32
by fenix＠club-internet.fr 14 May '03

14 May '03

Hi, >You could just protect it with a > >if (!data) return FALSE; ok, it's what i tought but not sure. i'll try it when i back home :) >If I had CVS access at work (stupid corporate politics) ... i have the same problem here, it's really boring :( Thx, Raphael

1 0

[latest cvs] GTA 3 is almost perfect
by erwin wolff 14 May '03

14 May '03

I tested GTA3 again, but this time with the latest cvs. GTA3 runs much faster now and produces only one error: fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402fc60) : stub Again, no in-game textures are being shown, only polygons and colors. The only texture that is being shown is the title of the game in the game menu.

1 0

int21 testing
by Ferenc Wagner 14 May '03

14 May '03

Hello, is there a way to incorporate DOS interrupt testing in the conformance testing framework? I recall that I saw some comments that Win32 applications should not be able to call DOS interrupts. But it should be testable at least... Now I have separate DOS16 programs for that. Feri.

1 0

Wine Window Sizing
by wine＠baker-net.org.uk 14 May '03

14 May '03

I noticed (when playing freecell) that wine doesn't respect maximum window sizes defined by the application and doesn't flash the title bar when using the KDE window manager (it works fine using Desktop=... in the config file) This seemed as though it might be a reasonably straight forward area for a wine newbie to try to fix so I've started by writing a test program that calls the relevant methods. My program behaves as I believe it should when run on Windows NT or XP or in Desktop mode and exhibits the same problems as freecell when using the KDE window manager. (Code is available at www.baker-net.org.uk/wine if anyone is interested). Anyway it looks as though wine doesn't attempt to make any ICCCM calls with the ptMaxTrackSize value in the structure obtained with WM_GETMINMAXINFO or for FlashWindow. Before I look into how I could implement this, is there a reason it isn't done or is anyone else working on it?

3 2

developoing windows resources for wine
by Patrick Griffin 14 May '03

14 May '03

I've been trying to generate some mock-up UI panes for winecfg, and I'd like to use real win32 resources to do it. However, I'm not sure how resources are usually generated for use in wine programs. I see 3 options at this point: 1. write it up by hand: icky but everybody can do it 2. use msdev in Windows and then port it 3. use some other program I don't know about Any suggestions as to where to go from here? And does anyone know how the resources currently in CVS were generated? Thanks- Patrick -- Patrick Griffin <griffinp(a)mit.edu>

2 1

_thiscall Calling Convention as Specfile option or via register
by Uwe Bonnes 14 May '03

14 May '03

Hallo, as Jason noticed, in MSVCRT there is a _thiscall calling convention that uses the ECX register for the 'this' pointer. Should we have another Specfile keyword in our spec files or should the _thiscall calling convention be implemented via the 'register" keyword? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Wine Release 20030508 cvs dirs?
by Philipp Wollermann 14 May '03

14 May '03

Hi, I just downloaded Wine 20030508 source and couldn't find the matching cvsdirs package (it's not on ftp.winehq.com and sourceforge is down at the moment).. Does anyone know where I can find them or when they will be available? Philipp

2 1

[dx8-21] Viewport fix
by Ann and Jason Edmeades 13 May '03

13 May '03

FYI With the attached patch on top of the wine cvs tree, a no-cd install (requires native msvcrt until I fix the 'thiscall' issue) and running 'wine war3' warcraft 3 now appears to be pretty much right!!! (No more screen distortion / misplaced faces etc). Thanks to everyone who has helped get this far, especially Raphael and Lucho. Changelog Make sure the viewport is from the GL (bottom left) not the DirectX (top left). Jason

2 1

winedbg unimplemented function broken
by Andreas Mohr 13 May '03

13 May '03

Hi all, I just had: Unhandled exception: unimplemented function kernel32.dll.GetDaylightFlag called in 32-bit code (0x4086f052). In 32-bit mode. 0x4086f052 (__wine_unimplemented+0x52 [kernel32.spec.c:42] in kernel32.dll.so): jmp 0x4086f04c (__wine_unimplemented+0x4c [kernel32.spec.c:42] in kernel32.dll.so) 50 void __wine_stub_kernel32_dll_19(void) { __wine_unimplemented("ThunkTheTemplateHandle"); } since this is called from applet TIMEDATE.CPL, I assume it's NOT ThunkTheTemplateHandle(). In other words, we've got a function lookup problem. I've also had wrong information in one other case. Breakage from recent ntdll loader work? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 3

Re: Re: Valgrind for WINE tarball now available
by fenix＠club-internet.fr 13 May '03

13 May '03

Hi >$ valgrind `which wine` >==221== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. >==221== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. >==221== Using valgrind-1.9.6-wine, a program instrumentation system for x86-linux. >==221== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. >==221== Estimated CPU clock rate is 334 MHz >==221== For more details, rerun with: -v >==221== >==221== Warning: segment-override prefix encountered, but thread has no LDT >==221== Warning: segment access: virtual addr 24 exceeds segment limit of 0 >==221== Invalid read of size 4 >==221== at 0x4029FCC4: __pthread_getspecific (../../include/winnt.h:1619) >==221== by 0x403035DF: dlopen_dll (loader.c:156) >==221== by 0x40303E02: wine_init (loader.c:427) >==221== by 0x3C000612: main (main.c:32) >==221== Address 0x18 is not stack'd, malloc'd or free'd >Segmentation fault hmmm, are you trying with valgrind with nvidia opengl ? Regards, Raphael

2 1

Re: little site update
by Dimitrie O. Paun 13 May '03

13 May '03

On Tue, 13 May 2003, puoti(a)inwind.it wrote: > I've added a link to digilander.libero.it/winehqitalia, it hosts Mandrake 9.1 > (glibc 2.3) RPMs of wine, updated at each release, maintained by Ivan Leo Murray > Smith (me). It would be way better if you uploaded those files to the SourceForge instead, like all the other packages. Apart from the fact that it's less confusing (and more convenient) for the users, we get centralized download statistics, better ranking in the top downloads, and so forth. If you are interested, I can give you permissions to upload the files under the Mandrake package (which is there already, it's just hidden since we have no files for it ATM). -- Dimi.

1 0

Perfect graphics?
by Mike Hearn 13 May '03

13 May '03

Can anybody explain what this option does? I'm trying to solve a bug where a BitBlt and a PatBlt seem to race each other for control of the screen, and am wondering if this might affect timing. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: Dependancies question ?
by Pouech Eric DMI AEI CAEN 13 May '03

13 May '03

> Surprisingly, after this "make depend && make" recompiles EveryThing in > my tree. > I dont understand why, almost no program relies on twain_32.dll.so, > so could someone shed some light here ? because it changed the include/config.h file, which contains all configuration specific information (libraries you have or you don't...). Since config.h is quite heavily included in Wine source, it implied the whole recompilation. HTH A+

1 0

Dependancies question ?
by Sylvain Petreolle 13 May '03

13 May '03

Hi, Today I removed my sane binaries (scanner program) since my CVS repository is too old. I made a "./configure" to disable the sane support in Wine. Surprisingly, after this "make depend && make" recompiles EveryThing in my tree. I dont understand why, almost no program relies on twain_32.dll.so, so could someone shed some light here ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

DCE RPC documentation fund is collecting dust...
by Gregory M. Turner 13 May '03

13 May '03

My apologies for not announcing this sonner, but it seems that the DCE RPC documentation package, which many of you kindly donated funds for, is a no-go. I've spent some time researching what, if anything, we need from OpenGroup, and unfortunately, I've never been able to get a coherent answer, even from OpenGroup's sales people. Part of the problem seems to be that the DCE standard is "discontinued" by OpenGroup as a project. We wouldn't care if we knew what documents had relevance to wine. But it turns out that DCE covers a lot more than just RPC, most of which is not of interest to wine's RPC implementation. The RPC part of the standard, as far as I can tell, is freely available for download, including the fascinating "DCOM/ActiveX" standard (which refers to a separate ORPC standards document I have been unable to find, I'm afraid, to document the ORPC wire protocol :(; btw, I think Microsoft let their similar document fall of the 'net as well, you'll see links to it in various places... but I digress....) So, insofar as I have questions about whether or not there's anything useful in there, OpenGroup's sales lady is unable to help -- she don't even seem able to give me the information thats available on the website, much less elaborate on it. That leaves me with no choice but to guess what is useful based on the information available to me: which seems to indicate that we don't need anything we can't get for free from OpenGroup. So, the obvious question is, where does everyone's hard-earned money go? I've confirmed with Jeremy that refunds are an option; if you want your money back, let Jeremy know, and presumably he will make arrangements with you in private to get your money returned. For those of you who would rather have your donations go to some other wine-releated cause, the matter is open for discussion. One idea which has been tossed around in private discussions between myself, Jeremy and Dimi is to rededictae these funds to the Wine Party Fund or some other wine conference fund. Another would be to find some other documentation we need to buy and use it for that. But, it's your money, and since every contributor essentially has veto power over their own portion of the funds, we obviously want to build some kind of consensus. Sorry it took me so long to break this news, I spend a fair amount of time trying to salvage the original plan to buy the DCE doc's but it just didn't seem right to spend it on something which potentially has no value to wine... and then the guilt and procrastination set in... ;) Thanks for your patience on this matter. -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

5 4

Re: toolbar - get rid of direct ImageList access hacks
by Vitaliy Margolen 13 May '03

13 May '03

Looks like resizing ToolBar buttons doesn't work this way. Needs more work. For a time being revert this change: Vitaliy Margolen changelog: - dlls/comctrl32/toolbar.c revert change for resizing buttons Index: dlls/comctl32/toolbar.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/toolbar.c,v retrieving revision 1.131 diff -u -r1.131 toolbar.c --- dlls/comctl32/toolbar.c 13 May 2003 03:36:54 -0000 1.131 +++ dlls/comctl32/toolbar.c 13 May 2003 06:03:24 -0000 @@ -29,7 +29,6 @@ * * * TODO: - * - A little bug in TOOLBAR_DrawMasked() * - Button wrapping (under construction). * - Messages. * - Notifications (under construction). @@ -67,6 +66,7 @@ #include "winuser.h" #include "wine/unicode.h" #include "commctrl.h" +#include "imagelist.h" #include "comctl32.h" #include "wine/debug.h" @@ -3952,8 +3952,12 @@ infoPtr->nBitmapWidth = (INT)LOWORD(lParam); infoPtr->nBitmapHeight = (INT)HIWORD(lParam); - if (himlDef) - ImageList_SetIconSize(himlDef, infoPtr->nBitmapWidth, infoPtr->nBitmapHeight); + + /* uses image list internals directly */ + if (himlDef) { + himlDef->cx = infoPtr->nBitmapWidth; + himlDef->cy = infoPtr->nBitmapHeight; + } return TRUE; }

1 0

Re: DOSVM_Int31Handler/DOSVM_CallRMInt crash
by Jukka Heinonen 13 May '03

13 May '03

Andreas Mohr wrote: > when running Win98 explorer.exe, I finally get this crash: ... > Backtrace: > 0 0x406cb9a3 (DOSVM_GetRMHandler+0x7(intnum=0x21) [interrupts.c:455] in winedos.dll.so) (ebp=41052560) > 1 0x406c7b8c (DOSVM_CallRMInt+0x28(context=0x4105290c) [int31.c:462] in winedos.dll.so) (ebp=41052850) > =>2 0x406c9b63 (DOSVM_Int31Handler+0x15f7(context=0x4105290c) [int31.c:1067] in winedos.dll.so) (ebp=410528dc) > 3 0x406cafc5 (DOSVM_IntProcRelay+0x9(context=0x4105290c, data=0x406c856c) [interrupts.c:121] in winedos.dll.so) (ebp=410528e8) > 4 0x406cd1ca (RELAY_RelayStub+0xe(proc=0x406cafbc, args=0x4038fcae, context=0x4105290c) [relay.c:116] in winedos.dll.so) (ebp=410528f8) > 5 0x400b57f0 (KERNEL32.DLL.__wine_call_from_16_regs+0x144 in libntdll.dll.so) ... > I assume it's because the DOS memory area hasn't been unprotected/set up > (grrr, this kind of problem *again*!) > > Where should this call sequence have activated the DOS memory area properly? Well, I was expecting this kind of problems, nice to finally have a test program. If we assume that we want to keep the lowest 64k protected for as long as possible, the first fix is to make DOSVM_GetRMHandler and DOSVM_SetRMHandler update interrupt vector in upper memory if DOS memory has not been unprotected. However, either DOSVM_CallRMInt or DOSVM_Int31Handler must unprotect memory because we are about to enter VM86. I have actually had some plans to keep the lowest 1 megabyte protected when process starts up and only unprotect and initialize DOS/BIOS stuff if it really is needed (and unprotect low 64k only after first access to it from VM86 mode). In this case we could push initialization code to winedos and we really would keep null pointer protection active for as long as possible. But, anyway, simple solution would be to add unprotect call to DOSVM_Int31Handler just before calling to DOSVM_CallRMInt. This would also fix DOSVM_GetRMHandler call in DOSVM_CallRMInt. Nice comment about why this is needed would also be fine. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel