- Wine-Devel - list.winehq.org

[dx8-21] Viewport fix
by Ann and Jason Edmeades May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

> 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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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 May 13, 2003

May 13, 2003

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