April 2001 - Wine-Devel - list.winehq.org

Re: InstallShield and ole question...
by juergen.schmied＠debitel.net May 1, 2001

May 1, 2001

> As for doing the 10k+ lines of coding myself, I have experience in > (de)marshalling and network coding, spent many years doing it, it's more a > matter of available time and learning the com wire protocols, neither of which > are currently available to me. Here's to hoping someone is already working on > it ;). For local marshalling we could use our own protocol and even our own way of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one? For networking - the dcom protocoll is documented (IMHO). juergen

5 4

Quickbooks 5 and printing
by Sean A. Walberg May 1, 2001

May 1, 2001

After a long break, I'd like to figure out why quickbooks 5 can't print. wineps works, ie I can print in notepad, but QB seems to implement its own printing mechanism. --debugmsg +psdrv,+print,+winspool produces no output. Adding +font spits out a lot, but no errors that I can see. This all used to work until wineps was moved from graphics to a dll about a year ago. I can see from +dosfs that it's accessing some files (WPR.DAT/WPR.INI) which contain information on printers. There is also a QBWPR.DLL file that gets loaded. Any hints on where to start would be appreciated. Thanks, Sean -- Sean A. Walberg <sean(a)ertw.com> http://www.ertw.com *updated!* Join the weekly brainbuzz.com Linux newsletter for news and resources! Send a blank email to: join-linuxnews(a)list.brainbuzz.com

5 8

TrueType font metrics for PostScript driver
by Ian Pilcher April 30, 2001

April 30, 2001

And the verdict is . . . Everyone seems to feel that using FreeType 2.x directly from the Post- Script driver is the right thing to do, so that's what I'll do. This does mean that I'm going to have to learn autoconf, so expect some stupid questions on that subject. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

msvcrt error
by Chris Morgan April 30, 2001

April 30, 2001

I'm getting this error: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: err:win32:PE_FindExportedFunction function not found for forward 'ntdll._iswctype' used by 'msvcrt.dll'. If you are using builtin 'msvcrt.dll', try using the native one instead. err:win32:fixup_imports No implementation for MSVCRT.dll.636(iswctype) imported from C:\program files\notepad.exe, setting to 0xdeadbeef ~/program files$ when running notepad.exe using builtin msvcrt.dll. Any ideas on what might be causing this? Thanks, Chris

2 1

Re: TrueType font metrics for PostScript driver
by Alexandre Julliard April 30, 2001

April 30, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > With a separate program, FreeType is only required for people who want > to print TrueType fonts. If I put FreeType calls directly into the > driver, FreeType will be required to build/run Wine at all, even for > users that derive no benefit from it. You can have an autoconf check and #ifdef the code out if possible. We will have to use FreeType at some point anyway, so we might as well start now. Besides it seems it will be easier to use if everything is built-in instead of having to run a separate tool. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: TrueType font metrics for PostScript driver
by Alexandre Julliard April 30, 2001

April 30, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > Absolutely nothing. I just don't think the immediate benefit of getting > at TrueType encodings justifies creating the dependency at this time. But doesn't your solution also require FreeType anyway? Linking it into Wine or into a separate program is not really different for the user, he still needs to install it. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: TrueType font metrics for PostScript driver
by Marcus Meissner April 30, 2001

April 30, 2001

On Mon, Apr 30, 2001 at 02:03:48PM -0500, Ian Pilcher wrote: > Alexandre Julliard wrote: > > > > But doesn't your solution also require FreeType anyway? Linking it > > into Wine or into a separate program is not really different for the > > user, he still needs to install it. > > > > With a separate program, FreeType is only required for people who want > to print TrueType fonts. If I put FreeType calls directly into the > driver, FreeType will be required to build/run Wine at all, even for > users that derive no benefit from it. Umm, use autoconf checks and fall back methods, also for ft1 vs ft2 checks. Ciao, Marcus

1 0

STATUS_* codes
by David Howells April 30, 2001

April 30, 2001

Can someone pin numbers on the following codes: STATUS_FILE_IS_A_DIRECTORY STATUS_INVALID_EXECUTABLE_IMAGE At least I think that's what they're called (unfortunately, my book's at home where I can't check it). They're listed in my NT native API book (though that's no guarantee that they exist), but not in the Wine header files, and I don't have a copy of the DDK installed on top of MSDEV. David

3 2

edit control problem
by Mike McCormack April 30, 2001

April 30, 2001

Hi, Wine-20010418 seems to have a (serious) problem in the edit control. The problem occurs when i press the backspace key, and there is text after the cursor. (eg. when i am writing a reply to an email on my web-based email). Text following the cursor is not draw correctly... it appears that there are many characters missing at the beginning of the line, but the text is only drawn correctly. Perhaps one of the recent optimizations of the edit control missed something?? i don't know if this is fixed in the latest CVS... but the problem didn't exist in previous wine releases. Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

2 1

TrueType font metrics for PostScript driver
by Ian Pilcher April 29, 2001

April 29, 2001

In order to Unicode-enable the PostScript driver, it needs information about about font encodings that isn't present in Adobe's AFM file format (glyph names for character encodings greater than 256). For Type 1 fonts with a standard encoding, the driver can use the encoding in the Adobe Glyph List. (There's no other choice.) TrueType font designers, however, seem to regard glyph naming as an opportunity to express their creativity. Besides, the information is present in the TrueType font files, so the driver might as well use it. The driver could read this information directly from the font files, but this would make Wine dependant on the FreeType libraries, and that doesn't strike me as a wonderful idea. Instead, I have cobbled together a small program which reads a TrueType font file and creates a "TrueType Font Metrics" file, which is very similar to an AFM file. (This program does use the FreeType library.) Anyone have any objections to using this approach as a interim measure? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 2

Problem in DIB section / bitblt
by Marcus Meissner April 29, 2001

April 29, 2001

Hi, Following trace has a BadMatch error related to DIB and XShm. Strangely, if I do: --- bitblt.c 2001/01/15 22:30:51 1.28 +++ bitblt.c 2001/04/29 17:06:14 @@ -1461,7 +1461,8 @@ sDst = X11DRV_LockDIBSection( dcDst, DIB_Status_None, FALSE ); sSrc = X11DRV_LockDIBSection( dcSrc, DIB_Status_None, FALSE ); - if ((sSrc == DIB_Status_AppMod) && (rop == SRCCOPY)) { + if (0 && (sSrc == DIB_Status_AppMod) && (rop == SRCCOPY)) { + FIXME("in fast branch\n"); /* do everything ourselves; map coordinates */ xSrc = dcSrc->DCOrgX + XLPTODP( dcSrc, xSrc ); ySrc = dcSrc->DCOrgY + YLPTODP( dcSrc, ySrc ); it no longer does crash, but proceeds happily. So something is broken in the fast path, but what :/ Ciao, Marcus Call user32.GetDesktopWindow() ret=60cb02ca tid=08063358 Ret user32.GetDesktopWindow() retval=0000008c ret=60cb02ca tid=08063358 Call user32.GetDC(0000008c) ret=60cb02d4 tid=08063358 Call x11drv.GetDC(0000008c,00000088,00000000,0001001a) ret=40783118 tid=08063358 Ret x11drv.GetDC() retval=00000001 ret=40783118 tid=08063358 Ret user32.GetDC() retval=00000088 ret=60cb02d4 tid=08063358 Call gdi32.CreateDIBSection(00000088,40454704,00000000,4a9a94a0,00000000,00000000) ret=60cb02e7 tid=08063358 trace:bitmap:X11DRV_DIB_CreateDIBSection format (16,16), planes 1, bpp 24, size 768, colors 0 (RGB) trace:bitmap:CreateCompatibleBitmap (0ce4,16,16) = trace:bitmap:CreateBitmap 16x16, 65536 colors returning 00000ce8 trace:bitmap:CreateCompatibleBitmap 0ce8 trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 2 Ret gdi32.CreateDIBSection() retval=00000ce8 ret=60cb02e7 tid=08063358 Call user32.ReleaseDC(0000008c,00000088) ret=60cb02f6 tid=08063358 Ret user32.ReleaseDC() retval=00000001 ret=60cb02f6 tid=08063358 Call kernel32.IsBadReadPtr(4ad30000,00000001) ret=60cb08f2 tid=08063358 Ret kernel32.IsBadReadPtr() retval=00000000 ret=60cb08f2 tid=08063358 Call ntdll.RtlEnterCriticalSection(60cc1298) ret=60c9d188 tid=08063358 Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=60c9d188 tid=08063358 Call kernel32.CreateFileA(4a8aafb0 "Y:\\programme\\Mindjet\\MindManager\\sys\\codes\\code6.bmp",80000000,00000001,00000000,00000003,00000080,00000000) ret=60c9e56a tid=08063358 Ret kernel32.CreateFileA() retval=00000068 ret=60c9e56a tid=08063358 Call kernel32.ReadFile(00000068,405b6adc,0000000e,405b6aec,00000000) ret=60c9dfbd tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9dfbd tid=08063358 Call kernel32.ReadFile(00000068,405b6ab4,00000028,405b6aec,00000000) ret=60c9dfed tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9dfed tid=08063358 Call kernel32.CloseHandle(00000068) ret=60c9e0b4 tid=08063358 Ret kernel32.CloseHandle() retval=00000001 ret=60c9e0b4 tid=08063358 Call kernel32.CreateFileA(4a8aafb0 "Y:\\programme\\Mindjet\\MindManager\\sys\\codes\\code6.bmp",80000000,00000001,00000000,00000003,00000080,00000000) ret=60c9e56a tid=08063358 Ret kernel32.CreateFileA() retval=00000068 ret=60c9e56a tid=08063358 Call kernel32.SetFilePointer(00000068,00000036,00000000,00000000) ret=60c9d217 tid=08063358 Ret kernel32.SetFilePointer() retval=00000036 ret=60c9d217 tid=08063358 Call kernel32.HeapAlloc(4a260000,00000000,00018010) ret=60cb15a0 tid=08063358 Ret kernel32.HeapAlloc() retval=4a26546c ret=60cb15a0 tid=08063358 Call kernel32.ReadFile(00000068,4a26546c,00018000,405b6ad0,00000000) ret=60c9d4ff tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9d4ff tid=08063358 trace:bitmap:X11DRV_DIB_Lock Locking 0x40455ea8 from thread 08063358 trace:bitmap:X11DRV_DIB_Coerce AppMod requested in status InSync trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 4 trace:bitmap:X11DRV_DIB_Unlock Unlocking in status AppMod trace:bitmap:X11DRV_DIB_Unlock Unlocked 0x40455ea8 Call kernel32.ReadFile(00000068,4a26549c,00017fd0,405b6ad0,00000000) ret=60c9d4ff tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9d4ff tid=08063358 Call ntdll.RtlEnterCriticalSection(60cc17d0) ret=60cb3773 tid=08063358 Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=60cb3773 tid=08063358 Call ntdll.RtlLeaveCriticalSection(60cc17d0) ret=60cb3789 tid=08063358 Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=60cb3789 tid=08063358 Call kernel32.HeapFree(4a260000,00000000,4a26546c) ret=60cb1124 tid=08063358 Ret kernel32.HeapFree() retval=00000001 ret=60cb1124 tid=08063358 Call kernel32.CloseHandle(00000068) ret=60c9d22f tid=08063358 Ret kernel32.CloseHandle() retval=00000001 ret=60c9d22f tid=08063358 Call ntdll.RtlLeaveCriticalSection(60cc1298) ret=60c9d236 tid=08063358 Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=60c9d236 tid=08063358 Call ntdll.RtlEnterCriticalSection(60cc1298) ret=60c9d91d tid=08063358 Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=60c9d91d tid=08063358 Call kernel32.CreateFileA(4a8aafb0 "Y:\\programme\\Mindjet\\MindManager\\sys\\codes\\code6.bmp",80000000,00000001,00000000,00000003,00000080,00000000) ret=60c9e56a tid=08063358 Ret kernel32.CreateFileA() retval=00000068 ret=60c9e56a tid=08063358 Call kernel32.ReadFile(00000068,405b6a90,0000000e,405b6aa0,00000000) ret=60c9dfbd tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9dfbd tid=08063358 Call kernel32.ReadFile(00000068,405b6a68,00000028,405b6aa0,00000000) ret=60c9dfed tid=08063358 Ret kernel32.ReadFile() retval=00000001 ret=60c9dfed tid=08063358 Call kernel32.CloseHandle(00000068) ret=60c9e0b4 tid=08063358 Ret kernel32.CloseHandle() retval=00000001 ret=60c9e0b4 tid=08063358 Call ntdll.RtlLeaveCriticalSection(60cc1298) ret=60c9d9db tid=08063358 Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=60c9d9db tid=08063358 Call gdi32.CreateCompatibleDC(00000000) ret=0040fcda tid=08063358 Ret gdi32.CreateCompatibleDC() retval=00000cec ret=0040fcda tid=08063358 Call gdi32.CreateCompatibleDC(00000000) ret=0040fce2 tid=08063358 Ret gdi32.CreateCompatibleDC() retval=00000cf0 ret=0040fce2 tid=08063358 Call gdi32.CreateBitmap(00000010,00000010,00000001,00000001,00000000) ret=0040fcf5 tid=08063358 trace:bitmap:CreateBitmap 16x16, 2 colors returning 00000cf4 Ret gdi32.CreateBitmap() retval=00000cf4 ret=0040fcf5 tid=08063358 Call gdi32.SelectObject(00000cec,00000cf4) ret=0040fd02 tid=08063358 Ret gdi32.SelectObject() retval=00000044 ret=0040fd02 tid=08063358 Call gdi32.SelectObject(00000cf0,00000ce8) ret=0040fd0c tid=08063358 Ret gdi32.SelectObject() retval=00000044 ret=0040fd0c tid=08063358 Call gdi32.SetBkColor(00000cf0,00c080ff) ret=0040fd1b tid=08063358 Ret gdi32.SetBkColor() retval=00ffffff ret=0040fd1b tid=08063358 Call gdi32.BitBlt(00000cec,00000000,00000000,00000010,00000010,00000cf0,00000000,00000000,00cc0020) ret=0040fd33 tid=08063358 trace:bitblt:BitBlt hdcSrc=0cf0 0,0 16 bpp->hdcDest=0cec 0,0 16x16x1 rop=cc0020 trace:bitmap:X11DRV_DIB_Lock Locking 0x40455ea8 from thread 08063358 fixme:bitblt:X11DRV_BitBlt in fast branch trace:bitmap:X11DRV_DIB_CopyDIBSection (0x4045610c,0x40455ee8,0,0,0,0,16,16) trace:bitmap:X11DRV_DIB_DoCopyDIBSection Copying from DIB bits to Pixmap trace:bitmap:X11DRV_DIB_SetImageBits XPutImage(0x8054790,29361387,0x8074680,0x808bbe8,0,0,0,0,16,16) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 147 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Serial number of failed request: 5544 Current serial number in output stream: 5545 [

1 0

InstallShield and ole question...
by Mike Bond April 27, 2001

April 27, 2001

Quick brief, I've been lurking for quite some time around WineHQ and the wine project, but don't really have time for putting a lot of devel into it. It seems wine is finally getting close enough to working for most things that I can put some time into tracking problems without gobbling up many hours. All that said, I've been trying to get some InstallShield v6 based installers to work with wine without much success. I've tried various combinations of builtin and native versions of the ole related dlls, each configuration with it's own hitches. With a mostly 'native' configuration, I get the 0x80070008 (ERROR_NOT_ENOUGH_MEMORY) error when trying to load IKernel.exe. I did not spend a lot of time with this as 'builtin' really is the prefered method anyway. With a completely 'builtin' configuration for the various ole dlls, I get the dreaded 0x80070005 (ERROR_ACCESS_DENIED) when trying to load IKernel.exe that others have reported on the list in the past. After persuing this a bit, I found that the problems seems to lie in the fact that CoGetClassObject in compobj.c does not have CLSCTX_LOCAL_SERVER implemented, which InstallShield is trying to use when starting up the "InstallShield setup kernel" via CoCreateInstance. My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration. -- TTFN MikeB

9 11

AVI resource in shell32.dll
by Stefan Leichter April 27, 2001

April 27, 2001

Hi all, during debugging an installer (of Wiso Homebanking Try&Buy Version from Buhl Data) i found that native shell32.dll contains at least one AVI resource (the magnifier that is spinning in front of a computer) that is not implemented in the buildin shell32.dll. I have looked around in the source tree of wine but i did not find any resource from typ AVI. Now my questions: Is someone working on an implementation of avi resources into the buildin dlls? If not, what needs to be done to start implementing avi resources into the dlls? Bye Stefan

2 2

fault handling - oof
by lawson_whitney＠juno.com April 26, 2001

April 26, 2001

Good day! One or all of these 3 patches has somehow broken fault hanlding for my mail app. As I seem to have it sort of working again, I wanted to get out a warning, and sorry I can't be more specific yet. The app also doesn't like to be forced to use a local phone number that is not in its current list but still works. I can't blame it, but I am damned if I will have it adding $.05 to my phone bill every time I send or get mail. I got what looked like a recursive page fault somewhere in startup/fixup_imports until I reverted all 3. It _might_ be a local misconfiguration, so don't waste too much time on it, but if you spot something that could be a bit wrong in one of these patches, please let me know. N 1 Apr 23 Alexandre Julliard (2,414) wine/dlls/msvcrt time.c N 2 Apr 23 Alexandre Julliard (2,089) wine/include/msvcrt stddef.h N 3 Apr 23 Alexandre Julliard (2,071) wine/debugger types.c I can't see how it could be any of them, but I guess it must be stddef.h. The app insists so far on native msvcrt. I keep hoping that will change. Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

3 7

Re: InstallShield and ole question...
by Mike Bond April 26, 2001

April 26, 2001

On Thu, Apr 26, 2001 at 12:55:30PM -0400, Gavriel State wrote: > The fix we put into the TransGaming tree was from Andreas Mohr, and it > fixed some problems related to previous versions of InstallSheild. We > haven't made any progress on v6. > > We'd certainly like to see it get done, but our resources are somewhat > limited at the moment, and we're concentrating on the DirectX work. I understand how that works. > Something that's interesting about the InstallShield objects is this: > They seem to expose a fair amount of their interfaces through OLE > Automation. I don't know for certain, but I have a recollection that > some work was done to support Automation for WordPerfect. I can't > remember whether that work was actually completed, or bypassed through > the use of dde for scripting instead. Hmm, would be interesting to get more details of what became of that work. > If automation does work, then perhaps it's enough to simply run the > InstallShield ikernel.exe and see if the user-side of the installer > works through automation rather than requiring marshalling. Unfortunately I had already tried that, first thing that came to mind once I realized what was going on. -- TTFN MikeB

1 0

dll-separated lzexpand doesn't work
by Ove Kaaven April 25, 2001

April 25, 2001

At least not on debian unstable... I've tracked the problem down to: lzexpand_main.c, function LZCopy, line 525: xread=(_readfun)LZRead; assembles as: movl LZRead(a)GOT(%ebx),%edx movl %edx,-1012(%ebp) so it reads out the address of LZRead out of the GOT. The final result in liblz32.so becomes: 5eb7: 8b 93 44 00 00 00 mov 0x44(%ebx),%edx 5ebd: 89 95 0c fc ff ff mov %edx,0xfffffc0c(%ebp) but because of the -symbolic linker switch, there's no such GOT entry. CRASH! The GOT entry for LZRead should be at 00007d64 in the dynamic relocation table, as far as I can tell from objdump and peeking at the GOT, but in the relocation table there's only this... ... 00007d60 R_386_GLOB_DAT __dso_handle 00007d68 R_386_GLOB_DAT __deregister_frame_info ... What can be done about this? Submit bug reports on ld?

1 0

Using config.status to recreate current setup
by Matthew Cline April 25, 2001

April 25, 2001

According to the comments at the start of config.status, I can run that file to recreate the current setup. However, if I use it, it appears to delete the makefile in wine/dlls/wintrust, causing "make depend" to fail; if I just copy the configure command that config.status has and run that on the command line, everything works fine. Am I doing something wrong? Thanks in advance. -- Matthew Cline | Suppose you were an idiot. And suppose that matt(a)nightrealms.com | you were a member of Congress. But I repeat | myself. -- Mark Twain

2 1

Re: Trouble with VirtualQuery()
by gerard patel April 25, 2001

April 25, 2001

At 02:07 PM 25/04/2001 +0200, you wrote: >Do you mean >http://support.microsoft.com/support/kb/articles/Q171/7/93.ASP >? Yes Gerard

1 0

Re: New breakages
by gerard patel April 25, 2001

April 25, 2001

At 09:30 AM 25/04/2001 +0200, I wrote: >There may be other problems, I have not the time to search for them all just now. Also several apps are not erasing parts of the screen : among others the word viewer 97 (freeware downloadable). A few other strange crashes. Gerard

1 0

Re: PATCH: drop relay stuff
by Andreas Mohr April 25, 2001

April 25, 2001

On Tue, Apr 24, 2001 at 09:33:16PM +0200, Marcus Meissner wrote: > Hi, > > Changelog: > Drop SYSLEVEL checks from relay debugging, since they break debugging > builtin GDI dlls. Hmm, do we really want to do this ? (I know it's already been applied) Shouldn't we create a different SYSLEVEL_CheckNotLevel_unenforced() function instead which simply doesn't call DebugBreak() ? That way we don't lose the important information about possible syslevel violations. Syslevel violations are an *ongoing* problem. They are not simply "solved". OTOH I could take Alexandre's cvs commit as his firm promise to go through every future patch line by line to check for syslevel mishaps/omissions ;-) Oh yeah, and in case you didn't notice: it's me again complaining about yet another silencing ;-) This patch is not even "too early", it's simply "wrong" IMHO, as it is an ongoing problem (I did mention this before, didn't I ? :). Sorry for me being of such an opposing nature ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

2 3

Re: Trouble with VirtualQuery()
by Uwe Bonnes April 25, 2001

April 25, 2001

>>>>> "Gerald" == <<gerard.patel(a)asi.fr>@s5.asi.fr> writes: Gerard > ... Gerard > Possibly I'll send a new patch if I find where is the flag Gerard > in the exe to handle the 3 gig memory space but as I am not Gerard > actively searching for it, you are welcome to do it yourself Gerard > :-) Do you mean http://support.microsoft.com/support/kb/articles/Q171/7/93.ASP ? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

New breakages
by gerard patel April 25, 2001

April 25, 2001

Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40a39b1b). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40a39b1b (X11DRV_WND_SetGravity+0x1f [wnd.c:414]): cmpl $0,0x0(%edx) 414 if (data->window && data->bit_gravity != value ) Wine-dbg>bt bt Backtrace: =>0 0x40a39b1b (X11DRV_WND_SetGravity+0x1f(wnd=0x40367b80, value=0x1) [wnd.c:414]) (ebp=40c56b8c) 1 0x40a149dc (X11DRV_SetWindowPos+0x678(winpos=0x40c56c54) [winpos.c:1076]) (ebp=40c56c3c) 2 0x406acb69 (SetWindowPos+0x51(hwnd=0x1a20, hwndInsertAfter=0x0, x=0xdd, y=0xcf, cx=0x172, cy=0xef, flags=0x80000015) [winpos.c:2176]) (ebp=40c56c70) 3 0x40a3481e (EVENT_ConfigureNotify+0x1a6(hWnd=0x1a20, event=0x40c56d90) [event.c:983]) (ebp=40c56ccc) 4 0x40a33b0f (EVENT_ProcessEvent+0x49b(event=0x40c56d90) [event.c:438]) (ebp=40c56d70) 5 0x40a335ec (EVENT_ProcessAllEvents+0x68(arg=0x0) [event.c:209]) (ebp=40c56df0) 6 0x400c9b7f (SERVICE_Loop+0xbf(dummy=0x0) [services.c:76]) (ebp=40c56f1c) Hacked away by --- wnd.c.orig Wed Apr 25 01:43:41 2001 +++ wnd.c Wed Apr 25 09:28:52 2001 @@ -411,7 +411,7 @@ { X11DRV_WND_DATA *data = wnd->pDriverData; - if (data->window && data->bit_gravity != value ) + if (data && data->window && data->bit_gravity != value ) { XSetWindowAttributes win_attr; win_attr.bit_gravity = value; Another problem : now in the file open window, the tooltips for the toolbar buttons are appearing as managed windows (in managed mode of course) There may be other problems, I have not the time to search for them all just now. Gerard

1 0

Re: GDI syslevel held during psdrv init ... bad
by Alexandre Julliard April 24, 2001

April 24, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Now the reason is, that pCreateDC is always called with the GDI syslevel (3) > held, so _any_ call to relaying here will dump. > > How do we fix this? We could probably get rid of the check. Syslevel locking is reasonably stable now, and dll separation will cause more and more false alarms here. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fault handling - oof
by Alexandre Julliard April 24, 2001

April 24, 2001

lawson_whitney(a)juno.com writes: > I got what looked like a recursive page fault somewhere in > startup/fixup_imports until I reverted all 3. A fixup_imports crash sounds a bit like what other people reported seeing with the shared sections fix. Did you run two instances of the application by any chance? -- Alexandre Julliard julliard(a)winehq.com

2 1

GDI syslevel held during psdrv init ... bad
by Marcus Meissner April 24, 2001

April 24, 2001

Hi, While trying to debug something I come across this problem: Call gdi32.CreateICA(405b59eb "WINEPS",405b59d4 "Wine PostScript Driver",405b59f 2 "LPT1:",00000000) ret=007a6674 tid=08063338 trace:relay:PE_InitDLL CallTo32(entryproc=0x4bef3270,module=4beeb000,type=1,res= (nil)) err:psdrv:PSDRV_AFMGetCharMetrics missing ;, failed. [C 0 ; WX 600 ; N null] fixme:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' Call kernel32.MultiByteToWideChar(00000000,00000000,4c057534 "Wine PostScript Dr iver",ffffffff,00000000,00000000) ret=40953fd4 tid=08063338 err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 3! Now the reason is, that pCreateDC is always called with the GDI syslevel (3) held, so _any_ call to relaying here will dump. How do we fix this? Ciao, Marcus

1 0

Re: problem with native dll's.
by Alexandre Julliard April 23, 2001

April 23, 2001

Rein Klazes <rklazes(a)xs4all.nl> writes: > Since the cvs commits early this week or the last (I could be more > precise but that will take a while) I have noticed a problem with some > native dlls. > If I start one app that uses such a dll and then another using the > same dll may crash. If this second app is started as the first process > it runs fine. Most likely my shared sections fix: 2001-04-13 Alexandre Julliard <julliard(a)winehq.com> * server/file.c, server/mapping.c, server/object.h: Repaired shared PE data sections. The fix itself should be OK, but it probably reveals other bugs that were hidden by the fact that the sections were not shared properly before. For instance if a dll stores window handles in the shared area it will break since window handles are not shared yet (working on it...) In your case it doesn't seem to be window handles though, so it may be worth investigating a bit more. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: Virtual memory under Win95
by Alexandre Julliard April 23, 2001

April 23, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps applications which use assumptions about Win95 virtual memory > management should be considered as broken? Or it is worth to support them? What should be considered broken is the memory management of Win95 ;-) But yes, we should probably forget about making this kind of things work, we cannot possibly support the Win95 memory model 100% right anyway. Especially since the app works with -winver nt40, I think that's a reasonable work-around. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Msvcrt fixes
by Andreas Mohr April 23, 2001

April 23, 2001

On Mon, Apr 23, 2001 at 12:27:58AM -0700, François Gouget wrote: > Btw, the Linux localtime documentation sucks. It's even worse than > the MS one!!! Err, fix it ? ;-) Really, what is an Open Source programmer supposed to do when he realizes that something sucks ? Food for thought, -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

3 3

Virtual memory under Win95
by Dmitry Timoshkov April 23, 2001

April 23, 2001

Hello all. Could anybody with access to a Win95 machine run this simple program and report the result? void test(void) { HANDLE hMapping; void *p; MEMORY_BASIC_INFORMATION info; DWORD dwRet; hMapping = CreateFileMappingA(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE | SEC_RESERVE, 0, 0x0400f000, NULL); printf("hMapping = %04x\n", hMapping); p = MapViewOfFile(hMapping, FILE_MAP_READ ,0, 0, 0x00010000); printf("p = %p\n", p); UnmapViewOfFile(p); dwRet = VirtualQuery(p, &info, sizeof(info)); printf("VirtualQuery(%p) ret=0x%lx\n" "BaseAddress = %p\n" "AllocationBase = %p\n" "AllocationProtect = 0x%08lx\n" "RegionSize = 0x%08x\n" "State = %08lx\n" "Protect = %08lx\n" "Type = %08lx\n", p, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type); } Thanks in advance.

4 6

Re: Virtual memory under Win95
by Alexandre Julliard April 23, 2001

April 23, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > From http://msdn.microsoft.com/library/psdk/winbase/filemap_79wn.htm > > --- cut --- > "To fully close a file-mapping object, an application must unmap all mapped views > of the file-mapping object by calling UnmapViewOfFile, and close the file-mapping > object handle by calling CloseHandle. The order in which these functions are called > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > does not matter. The call to UnmapViewOfFile is necessary because mapped views of > ^^^^^^^^^^^^^^^ > a file-mapping object maintain internal open handles to the object, and a file-mapping > object will not close until all open handles to it are closed." > --- cut --- > > My patch is WRONG. MSDN says that until both CloseHandle and UnmapViewOfFile are called > the file-mapping object still exists. This is wrong for NT but true for Win9x. Why do you say it's wrong for NT? It seems perfectly correct: the mapping object exists as long as you have a handle to it, or some view of it is mapped (which keeps a handle internally, just like we do under Wine). Do not confuse the file mapping object with mapped views; the doc only talks about the mapping object. Specific views of the object are unmapped by UnmapViewOfFile (at least under NT), even if this may not cause the mapping object to be deleted. This doesn't contradict the doc at all. -- Alexandre Julliard julliard(a)winehq.com

3 2

DDraw,DGA bug?
by wine＠henkis.net April 22, 2001

April 22, 2001

Hello, I seem to have a problem running Direct Draw under wine, when changing screens is a game i get to keep the old screen and the new screen is being drawed under the old screen. (Seen it by manualy changing resolution). It worked ok earlier, with a a month or so older version of wine. Anyone knows anything about this? Regards Henrik

2 1

problems while using yahoo! messenger
by K.Shyam April 22, 2001

April 22, 2001

hello; i am getting the following error message while running yahoo messenger using linux. can someone help me.i am new to wine as such and it might take some time for me to understand how it exactly works... thank you K.Shyam fixme:win32:DeviceIo_MMDEVLDR (5,(nil),0,0x40394dbc,4,0x405a6ab8,(nil)): stub fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1ee8,0x0000000d): stub fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1e00,0x0000000d): stub fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1d10,0x0000000d): stub fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1b18,0x0000000d): stub err:shell:IShellFolder_fnBindToObject can't bind to a file this is my config file : WINE REGISTRY Version 2 ;; All keys relative to \\Machine\\Software\\Wine\\Wine\\Config ;; ;; MS-DOS drives configuration ;; ;; Each section has the following format: ;; [Drive X] ;; Path=xxx (Unix path for drive root) ;; Type=xxx (supported types are 'floppy', 'hd', 'cdrom' and 'network') ;; Label=xxx (drive label, at most 11 characters) ;; Serial=xxx (serial number, 8 characters hexadecimal number) ;; Filesystem=xxx (supported types are 'msdos'/'dos'/'fat', 'win95'/'vfat', 'unix') ;; This is the FS Wine is supposed to emulate on a certain ;; directory structure. ;; Recommended: ;; - "win95" for ext2fs, VFAT and FAT32 ;; - "msdos" for FAT16 (ugly, upgrading to VFAT driver strongly recommended) ;; DON'T use "unix" unless you intend to port programs using Winelib ! ;; Device=/dev/xx (only if you want to allow raw device access) ;; [Drive A] "Path" = "/mnt/floppy" "Type" = "floppy" "Label" = "Floppy 0" "Device" = "/dev/fd0" [Drive C] "Path" = "/win" "Type" = "hd" "Label" = "MS-DOS 0" "Filesystem" = "win95" [Drive D] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "CD-ROM 0" "Filesystem" = "win95" "Device" = "/dev/cdrom" [Drive E] "Path" = "/tmp" "Type" = "hd" "Label" = "Tmp Drive" "Filesystem" = "win95" [Drive F] "Path" = "/" "Type" = "network" "Label" = "Root" "Filesystem" = "win95" [Drive G] "Path" = "${HOME}" "Type" = "network" "Label" = "Home" "Filesystem" = "win95" [wine] "Windows" = "C:\\windows" "System" = "C:\\windows\\system" "Path" = "C:\\windows;C:\\windows\\system;E:\\;G:\\" "Profile" = "C:\\windows" "Temp" = "E:\\" "GraphicsDriver" = "x11drv" "ShellLinker" = "wineshelllink" # <wineconf> [DllDefaults] "EXTRA_LD_LIBRARY_PATH" = "${HOME}/wine/cvs/lib" "DefaultLoadOrder" = "native, builtin, elfdll, so" [DllOverrides] "kernel32" = "builtin" "gdi32" = "builtin" "user32" = "builtin" "krnl386" = "builtin" "kernel" = "builtin" "gdi" = "builtin" "user" = "builtin" "toolhelp" = "builtin" "comdlg32" = "elfdll, builtin, native" "commdlg" = "elfdll, builtin, native" "version" = "elfdll, builtin, native" "ver" = "elfdll, builtin, native" "shell32" = "builtin, native" "shell" = "builtin, native" "lz32" = "builtin, native" "lzexpand" = "builtin, native" "commctrl" = "builtin, native" "comctl32" = "builtin, native" "wsock32" = "builtin" "winsock" = "builtin" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "ntdll" = "builtin, native" "mpr" = "builtin, native" "winspool" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "winmm" = "builtin" "w32skrnl" = "builtin" "msvfw32" = "builtin" "mmsystem" = "builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "midimap.drv" = "builtin, native" "w32skrnl" = "builtin" "wnaspi32" = "builtin" "wow32" = "builtin" "system" = "builtin" "display" = "builtin" "wprocs" = "builtin" "wineps" = "builtin" "icmp" = "builtin" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;ScreenDepth = 16 ; Name of X11 display to use ;;Display = :0.0 ; Allow the window manager to manage created windows "Managed" = "Y" ; Run Wine windows in desktop. Contains "N" or something like "800x600". ; Note Wine currently supports this option only on command line. ; So this option has currently no effect. Hope this will change. "Desktop" = "N" ; Use XFree86 DGA extension if present "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" [fonts] ;Read documentation/fonts before adding aliases "Resolution" = "96" "Default" = "-adobe-times-" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/modem,38400" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [spooler] "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;read=0x779,0x379,0x280-0x2a0 ;write=0x779,0x379,0x280-0x2a0 [spy] "Exclude" = "WM_SIZE;WM_TIMER;" [registry] ; Paths must be given in /dir/dir/file.reg format. ; Wine will not understand dos file names here... ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Use new file format "UseNewFormat" = "Y" ; Registry periodic save timeout in seconds ; PeriodicSave=600 ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; WineLook=xxx (supported styles are 'Win31'(default), 'Win95', 'Win98') "WineLook" = "Win95" [programs] "Default" = "" "Startup" = "" [Console] ;Drivers=tty ;XtermProg=nxterm ;InitialRows=25 ;InitialColumns=80 ;TerminalType=nxterm [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" # </wineconf>

1 0

notes2paper
by Ralf Schwarzmaier April 21, 2001

April 21, 2001

after the last configuration change, i've become an error message, but i don't kno what to do with it, this message sad nothing to me ;-))) thank you bye ralf fixme:mpr:WNetGetUserA ((null), 0x2aa100dc, 0x408d6d38): mostly stub err:listview:LISTVIEW_WindowProc unknown msg be10 wp=04500001 lp=00000450 err:listview:LISTVIEW_WindowProc unknown msg b029 wp=00000000 lp=00000000 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=04500002 lp=00000450 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=04500001 lp=00000450 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=06880001 lp=00000688 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=06880002 lp=00000688 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=06880001 lp=00000688 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=07a80001 lp=000007a8 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=07a80002 lp=000007a8 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=07a80001 lp=000007a8 fixme:system:SystemParametersInfo16 Unknown option 4104. fixme:treeview:TREEVIEW_WindowProc Unknown msg be10 wp=0ab40001 lp=00000ab4 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=0cf00001 lp=00000cf0 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=0cf00002 lp=00000cf0 err:listview:LISTVIEW_WindowProc unknown msg be10 wp=0cf00001 lp=00000cf0 fixme:heap:HeapCreate Shared Heap requested, returning system heap. fixme:crtdll:CRTDLL___dllonexit stub fixme:crtdll:CRTDLL___dllonexit stub fixme:mpr:WNetGetUserA ((null), 0x2a1eb560, 0x408d66fc): mostly stub fixme:mpr:WNetGetUserA ((null), 0x2a34789c, 0x408d6754): mostly stub fixme:system:SystemParametersInfo16 Unknown option 4104. err:statusbar:StatusWindowProc unknown msg be10 wp=1a7c0001 lp=00001a7c err:statusbar:StatusWindowProc unknown msg be10 wp=1b980001 lp=00001b98 fixme:string:GetLocaleInfoA 'SENGLANGUAGE' is not defined for your language (0007). Please define it in dlls/kernel/nls/YourLanguage.nls and submit patch for inclusion into the next Wine release. fixme:toolhelp:CreateToolhelp32Snapshot flags 1 not implemented FATAL: No handler for Win32 routine kernel32.Heap32ListFirst (called from 0x6c252073) fixme:toolhelp:CreateToolhelp32Snapshot flags 1 not implemented FATAL: No handler for Win32 routine kernel32.Heap32ListFirst (called from 0x6c252073) fixme:toolhelp:CreateToolhelp32Snapshot flags 1 not implemented FATAL: No handler for Win32 routine kernel32.Heap32ListFirst (called from 0x6c252073) fixme:toolhelp:CreateToolhelp32Snapshot flags 1 not implemented FATAL: No handler for Win32 routine kernel32.Heap32ListFirst (called from 0x6c252073) fixme:heap:HeapDestroy attempt to destroy system heap, returning TRUE!

1 0

Notes2Paper with wine
by ralf schwarzmaier April 21, 2001

April 21, 2001

hi @ll i have an problem with notes2paper under wine .... i need this for some databases of Notes. my lotus notes client runs perfect, but the additional programm notes2paper not, i can install notes2paper without any problems, direct in wine, but when i start it, it crash with non error message. what can i do, or what are teh parameters for an development debuging log ? thank you bye ralf

1 0

GDB remote debugging for wine
by Ove Kaaven April 21, 2001

April 21, 2001

As we all know, gdb isn't very compatible with wine, since gdb makes so many assumptions about the operating environment that isn't true in wine. But lately it occurred to me that perhaps it's possible to use gdb's remote debugging features to solve these issues. So recently, I've been secretly experimenting with writing gdb-server code in the wineserver. It goes something like this... ./configure --enable-remote-gdb [...blah...] $ wine stuff gdb socket ready at: target remote localhost:1234 $ gdb wine (gdb) target remote localhost:1234 and you're currently able to look at registers, backtrace, list all the threads, change thread, and read process memory... neato. But its usefulness might be quite limited since gdb doesn't know about the dynamically-loaded dlls so it doesn't automatically load their symbols... does anyone have ideas on how to solve that? It doesn't appear that the standard remote protocol have a command to tell gdb, and I don't know how gdb ordinarily does it. I've pondered making wine generate a file full of "add-symbol-file" commands or something that could be executed by gdb, but I don't know how to do that cleanly... preferably hacks for loading symbols should be transparent to the developer, and new symbols loaded automatically after new dlls are loaded. Hmm...

2 1

Crash due to some fixme messages in CreateProcessA
by Lionel Ulmer April 20, 2001

April 20, 2001

Hi all, While running a program, I got a crash in the CreateProcessA, in the following debug TRACE line : if (lpStartupInfo->lpDesktop) FIXME("(%s,...): lpStartupInfo->lpDesktop %s ignored\n", name, lpStartupInfo->lpDesktop); By running the debugger, I got this : Wine-dbg>print *lpStartupInfo print *lpStartupInfo {cb=83886080, lpReserved=*** Invalid address 0x4c000000 (_end+0xb823758) , lpDesktop=*** Invalid address 0x4c403416 (_end+0xbc26b6e) , lpTitle=*** Invalid address 0x70403416 (_end+0x2fc26b6e) , dwX=1883255830, dwY=406860822, dwXSize=1107296256, dwYSize=-1795162040, dwXCountChars=1849690049, dwYCountChars=1819042932, dwFillAttribute=1819042862, dwFlags=791899392, wShowWindow=26988, cbReserved2=14946, lpReserved2=*** Invalid address 0x7273752f (_end+0x31f5ac87) , hStdInput=409955375, hStdOutput=1107296256, hStdError=-285212600} It means that we are seeing a very broken application where these fields (lpDesktop and lpTitle) do not seem to be filled in propery... Now I never tried running this application on Windows to test if it even works, but I suppose it should work (otherwise it would not be burned on the CD :-) ). So what should we do ? Suppress the '%s' and replace it with a '%p' ? Add a check on the pointer to see if it's valid ? Lionel PS: BTW, why is this application that is on a win95 filesystem get run as : Call kernel32.CreateFileA(00405070 "~inst.exe",40000000,00000000,00000000,00000002,00000080,00000000) ret=00401391 tid=080678a0 Thus leading to a "~inst.exe" not found... -- Lionel Ulmer - http://www.bbrox.org/

2 2

FONT 8 requested, but 6x12 choosen: Wrong setup?
by Uwe Bonnes April 20, 2001

April 20, 2001

Hallo, the entry dialog of the Encarta 99 setup (from Computer Bild) looks wrong on my system: The box is to small and graphics and text overlap. This is caused by CreateDialogIndirect requesting an Font with width 8, but wine choosing a font with width 6. Manually correcting the return value of DIALOG_GetCharSizeFromDC to 8 gets the visula impression right. Is this caused by me setting up something wrong? Any hints how to setup right? Call USER.219: CREATEDIALOGINDIRECT(0x02fe,058f:0008,0x0390,0x02ef7778) ret=02ef:76b5 ds=02ff trace:dialog:DIALOG_ParseTemplate16 DIALOG 0, 0, 293, 214 trace:dialog:DIALOG_ParseTemplate16 STYLE 50000040 trace:dialog:DIALOG_ParseTemplate16 CAPTION '' trace:dialog:DIALOG_ParseTemplate16 FONT 8,'Helv' trace:font:X11DRV_FONT_SelectObject hfont=ffed trace:font:XFONT_RealizeFont physfont 1 trace:font:CreateFontIndirectW (-10 0 0 0) 'L"Helv"' => 09f6 trace:font:XFONT_UnAlias found alias 'Helv'->Helvetica' trace:font:X11DRV_FONT_SelectObject hfont=09f6 trace:font:XFONT_MatchDeviceFont (1) 'Helvetica' h=-10 weight=0 trace:font:XFONT_MatchDeviceFont found facename 'Helvetica' trace:font:XFONT_Match [ 10pt h=12 w=6 Bold Italic] trace:font:XFONT_Match returning 518 ... trace:font:XFONT_Match [ 12pt h=18 w=10 Normal ] trace:font:XFONT_Match returning 560 trace:font:XFONT_Match [ 13pt h=20 w=11 Normal ] trace:font:XFONT_Match returning 576 trace:font:XFONT_Match [ 17pt h=27 w=14 Normal ] trace:font:XFONT_Match returning 624 trace:font:XFONT_Match [ 23pt h=35 w=19 Normal ] trace:font:XFONT_Match returning 688 trace:font:LFD_ComposeLFD LFD(uRelax=0): -adobe-helvetica-medium-r-normal-*-11-*-100-100-p-*-iso8859-1 trace:font:XFONT_RealizeFont physfont 3 trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 32 AveCharWidth = 6 Italic = 0 LastChar = 255 MaxCharWidth = 11 UnderLined = 0 DefaultChar = 32 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 21 -------------------- InternalLeading = 2 Ascent = 10 Descent = 2 Height = 12 trace:font:GetTextExtentPointA not bug compatible. trace:font:GetTextExtentPoint32A (00000088 "abcd"... 4 0x407c6c8c): returning 22 x 12 trace:dialog:DIALOG_GetCharSizeFromDC Using tm: 6x12 (dlg: 6 x 12) (variable) Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: Strange crash
by gerard patel April 20, 2001

April 20, 2001

At 10:30 AM 20/04/2001 +0200, you wrote: <snip> >The lower 6 bits are the new floating point exception masks. Mine are >all set and yours are cleared, therefore the crash. > >Why that is the case, I haven't got a clue. I'm not sure I followed everything, but it could come from a problem that occurred a lot of time before, no? The bits could be already cleared on entry of the subroutine. If the exception handling bits are cleared and the app don't do anything with floating point, nothing will break, AFAICT. If this is the case a way could be to patch the code to print the mask with every +relay operation. BTW, I wonder if Dmitry has done some classic tricks like - getting a fresh tree from Winehq - compiling everything with -O0 - trying the same app on another computer with a (as much as possible) different configuration. Gerard

2 1

problem with native dll's.
by Rein Klazes April 20, 2001

April 20, 2001

Hi, Since the cvs commits early this week or the last (I could be more precise but that will take a while) I have noticed a problem with some native dlls. If I start one app that uses such a dll and then another using the same dll may crash. If this second app is started as the first process it runs fine. As an example eudora, using native commctrl/comctl32 crashes when it loads these dlls: | Unhandled exception: priviledged instruction | in 32-bit code (0x406e12b8). | In 32-bit mode. | 0x406e12b8 (GetTextColor+0x34 [dcvalues.c:177]): hlt | 177 DC_GET_VAL( COLORREF, GetTextColor, textColor ) | Wine-dbg>bt | Backtrace: | =>0 0x406e12b8 (GetTextColor+0x34(hdc=0x0) [dcvalues.c:177]) (ebp=405b6dc4) | 1 0xbfebbd8d (COMCTL32.DLL.341+0x74) (ebp=405b6dd8) | 2 0xbfebbceb (COMCTL32.DLL.EntryPoint+0x36) (ebp=405b6e04) | 3 0x4008abe3 (MODULE_InitDLL+0x97(wm=0x40383d84, type=0x1, lpReserved=0x1) [module.c:115]) (ebp=405b6e24) | 4 0x4008acf1 (MODULE_DllProcessAttach+0xd1(wm=0x40383d84, lpReserved=0x1) [module.c:182]) (ebp=405b6e48) | 5 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x403838f4, lpReserved=0x1) [module.c:177]) (ebp=405b6e68) | 6 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x4038302c, lpReserved=0x1) [module.c:177]) (ebp=405b6e88) | 7 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x403826f8, lpReserved=0x1) [module.c:177]) (ebp=405b6ea8) | 8 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x0, lpReserved=0x1) [module.c:177]) (ebp=405b6ec8) | 9 0x400d288f (start_process+0x133 [process.c:373]) (ebp=405b6f30) | 10 0x400d5f99 (SYSDEPS_DoCallOnStack+0x25(func=0x400d275c, arg=0x0) [sysdeps.c:173]) (ebp=405b6ff0) | 11 0x400d603f (SYSDEPS_CallOnStack+0x2f) (ebp=bffff8d4) | 12 0x400d60e2 (SYSDEPS_SwitchToThreadStack+0x8e(func=0x400d275c) [sysdeps.c:236]) (ebp=bffff908) | 13 0x400d2c5d (PROCESS_InitWine+0x1a1(argc=0x5, argv=0xbffff9a4, win16_exe_name=0x804d5c0, win16_exe_file=0x804d6c4) [process.c:524]) (ebp=bffff924) | 14 0x0804c164 (Letext [main.c]) (ebp=bffff93c) | 15 0x4028116b (NTDLL.DLL.sqrt+0x3bc6b) (ebp=bffff978) | 16 0x08049021 (_start+0x21) (ebp=00000000) The ip register is pointing to some instruction byte, making it an bogus opcode, "hlt" in this case: | Wine-dbg>disass $eip-12,$eip+10 | 0x406e129c (GetTextColor+0x18 [dcvalues.c:177]): call 0x406bf664 (_init+0x67c) | 0x406e12a1 (GetTextColor+0x1d [dcvalues.c:177]): addl $4,%esp | 0x406e12a4 (GetTextColor+0x20 [dcvalues.c:177]): testl %eax,%eax | 0x406e12a6 (GetTextColor+0x22 [dcvalues.c:177]): jz 0x406e12b4 (GetTextColor+0x30 [dcvalues.c:177]) | 0x406e12a8 (GetTextColor+0x24 [dcvalues.c:177]): movl 0x88(%eax),%edi | 0x406e12ae (GetTextColor+0x2a [dcvalues.c:177]): pushl %esi | 0x406e12af (GetTextColor+0x2b [dcvalues.c:177]): call 0x406bfee4 (_init+0xefc) | 0x406e12b4 (GetTextColor+0x30 [dcvalues.c:177]): movl %edi,%eax | 0x406e12b6 (GetTextColor+0x32 [dcvalues.c:177]): leal 0xfffffff4(%ebp),%esp | 0x406e12b9 (GetTextColor+0x35 [dcvalues.c:177]): popl %ebx | 0x406e12ba (GetTextColor+0x36 [dcvalues.c:177]): popl %esi | 0x406e12bb (GetTextColor+0x37 [dcvalues.c:177]): popl %edi | 0x406e12bc (GetTextColor+0x38 [dcvalues.c:177]): leave | 0x406e12bd (GetTextColor+0x39 [dcvalues.c:177]): ret $0x4 | 0x406e12c0 (GetViewportExt16 [dcvalues.c:182]): pushl %ebp Redoing the experiment (by starting and stopping all apps's) will give crashes at slightly different places. Has any one a suggestion? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: Strange crash
by Alexandre Julliard April 20, 2001

April 20, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Unhandled exception: c000008f > [...] > > Commenting lines 36-37 > physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * > dc->xformWorld2Vport.eM11 * 0.5); > in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. > > Why call to floor() leads to crash? Exception c000008f is EXCEPTION_FLT_INEXACT_RESULT. Probably one of the floating point values is invalid, or something similar. -- Alexandre Julliard julliard(a)winehq.com

4 10

Regedit from Win2k
by Dominik Strasser April 19, 2001

April 19, 2001

Hi, trying to run regedit from Win2k I encounter the following problems: err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef Hmm, but those are implemented. When I try to add a loadorder for shlwapi to get the builtin one, this doesn't work. "shlwapi" = "builtin, native" Still the native version is used. If I change the overall DefaultLoadOrder, to "builtin, native" it works. After this, the tree items in the Treeview vanished but I don't care. I assume this is the cause: fixme:listview:LISTVIEW_Create ANSI notify format is NOT used Trying to save the registry I get a crash wich I tracked down to this line in filedlg95.c: 453: AllocInArgWtoA(ofn->lpTemplateName, lpTemplateName); But ofn->lpTemplateName is not a pointer but seems to be a handle: 0x00000064. If I wrap the call into a if(!IsBadReadPtr(ofn->lpTemplateName, 4)), the filedialog comes up. Any clues anybody ? Regards Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser(a)mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard April 18, 2001

April 18, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > Separating the string data from their indices will allow them to be > declared as const, so that should get them into the ".rodata" section of > the resulting assembly; the Adobe Glyph List vector is already there. > Is this what you mean by "read only memory"? Yes, exactly that; separating the strings and the indices seems the right thing to do. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard April 18, 2001

April 18, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > typedef struct { > + INT index; > + CHAR sz[0]; > +} GLYPHNAME; > + > +typedef struct { > + LONG UV; > + GLYPHNAME *name; > +} UNICODEGLYPH; > + > +typedef struct { > + INT size; > + UNICODEGLYPH glyphs[0]; > +} UNICODEVECTOR; Zero-size arrays are not portable, and the standard method of using a size of 1 doesn't work well with initialized data (lots of warnings). So you probably need to change your data structures a bit; also it would be nice to store all the preinitialized stuff, or at least the strings, in read-only memory to save a bit of swap space. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: SEH logging
by Alexandre Julliard April 17, 2001

April 17, 2001

Francois Gouget <fgouget(a)free.fr> writes: > In this implementation exception.c reuses format_exception_msg() > which is normally used to display the dialog box asking whether to debug > the exception or not. Since this is all in ntdll it works. Actually win32/except.c is part of kernel, it's only linked in ntdll now because separation is not finished. So you cannot call format_exception_msg from ntdll. And anyway this would print "unhandled xxx" for all exceptions, which is misleading since they might be handled later on. Also I don't think the core exception routines should know about specific exception codes like EXCEPTION_WINE_STUB. If you want a message on stubs, it should be done in the .spec.c file before the call to RtlRaiseException. -- Alexandre Julliard julliard(a)winehq.com

2 1

IStorage file format.
by Psyon April 17, 2001

April 17, 2001

I am interested in making an HTMLHelp (.CHM) viewer for Linux. I am told the files are actually IStorage files. I have been scouring the internet looking for information about this format with no avail. I have also been looking over the WINE implementation, to see if that would shed some light on the format, but the code dives into a bunch of cryptic functions that I cant seem to follow. Is there any documents describing the format of these files? even just a brief description would be nice at this moment. If you have any information please replay directly to me at x-odus(a)iname.com Thanks in advance --Don Becker

4 3

RH 7.1 gcc fixes compiler bug
by James Juran April 16, 2001

April 16, 2001

As discovered about two weeks ago by Francois Jacques and Ulrich Weigand, Red Hat's gcc-2.96-69 package has a bug which shows up in the HOOK_CallHook function in windows/hook.c (and possibly other places). Red Hat 7.1 contains gcc-2.96-81, which fixes this bug. Users of Red Hat 7.0 should install the gcc and cpp packages from Red Hat 7.1 to fix this problem. -- James Juran jamesjuran(a)alumni.psu.edu

1 0

Re: strange msvcrt crash
by gerard patel April 16, 2001

April 16, 2001

At 02:47 PM 16/04/2001 -0700, you wrote: > > Also I had lost of trouble running mspaint when using the builtin >msvcrt. None of the following works: >$ wine /mnt/win98/Program\ Files/Accessories/mspaint.exe >$ wine "/mnt/win98/Program Files/Accessories/mspaint.exe" >$ wine "c:/Program Files/Accessories/mspaint.exe" >$ wine "c:\\Program Files\\Accessories\\mspaint.exe" > > They all tell me that 'H:\wine\Files\Accessories\mspaint.exe was not >found.'. If I use native msvcrt they all work (and wine is the real >thing, not a script). Msvcrt includes command line parsing to give apps argc and argv - the current builtin handling in dlls/msvcrt/data.c is probably the cause of your problem : while (1) { if ((cmdline[end]==' ') || (cmdline[end]=='\0')) { if (cmdline[end]=='\0') last_arg=1; else cmdline[end]='\0'; Gerard

1 0

Re: strange msvcrt crash
by Alexandre Julliard April 16, 2001

April 16, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > Err, which debugger ?? > > I get "Segmentation fault", and that's it... The automatic debugger startup cannot work in this case, because it only triggers for exception that are not handled by the application. But if you run the application under the debugger from the start, it should break at the first exception. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: strange msvcrt crash
by Alexandre Julliard April 16, 2001

April 16, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > Call msvcrt.mktime(405b614c) ret=5f40e3b3 tid=08066638 > Ret msvcrt.mktime() retval=3adae6b2 ret=5f40e3b3 tid=08066638 > trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 > trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=c0000005 flags=0 > Call ntdll.RtlRaiseException(404a4aa8) ret=405e1056 tid=08066638 > trace:seh:EXC_RtlRaiseException code=80000100 flags=1 > trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 80000100 is EXCEPTION_WINE_STUB; the app probably called a stub from the exception handler of the first seg fault (and then called the same stub from the handler of the stub exception, etc.) The debugger should be able to tell you more about it. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: OpenGL Visual Management
by lawson_whitney＠juno.com April 16, 2001

April 16, 2001

On Mon, 26 Mar 2001, Gavriel State wrote: > This patch fixes several issues with the way OpenGL manages visuals: > > - It always uses a double-buffered visual if one is available, even when > not running Wine in --desktop mode. Previously, we just hoped that the > default visual was double buffered, which is isn't in some DRI GL drivers. > > - It ensures that all colormaps created use the double-buffered visual if > it exists. This prevents problems where DRI GL implementations fail > to work unless the colormap visual matches the window visual matches the > glX visual. > > - It gets around similar visual issue with the default GL context created for > apps that don't create their own contexts before trying to use GL functions. > > Note that we are not able to support the wgl ChoosePixelFormat/DescribePixelFormat > APIs properly. Some of the infrastructure for this exists in graphics/x11drv/opengl.c > so that it can be done when the time comes. This patch explicitly removes the wgl > code that tries to match the OpenGL visual to a requested pixel format, because > that won't work until we can dynamically remap HWNDs to new X11 Windows with > a new visual. > > -Gav > Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette. No doubt I am not well set up for DGA: grep -i dga config.cache ac_cv_header_X11_extensions_xf86dga_h=${ac_cv_header_X11_extensions_xf86dga_h=yes} ac_cv_lib_Xxf86dga_XDGAQueryExtension=${ac_cv_lib_Xxf86dga_XDGAQueryExtension=no} ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=${ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=yes} but I don't see why DGA support should disturb things so. I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong? Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

2 11

strange msvcrt crash
by Andreas Mohr April 16, 2001

April 16, 2001

Hi all, (sorry for the long posting, but I think it's needed) wine --debugmsg +relay,+seh mspaint.exe, clicking on File->Send gives: Call kernel32.FindFirstFileA(403c71d0 "G:\\afxe6b2.tmp",405b61dc) ret=5f45b90c tid=08066638 Ret kernel32.FindFirstFileA() retval=403d26ca ret=5f45b90c tid=08066638 Call kernel32.FindClose(403d26ca) ret=5f45b91a tid=08066638 Ret kernel32.FindClose() retval=00000001 ret=5f45b91a tid=08066638 Call kernel32.FileTimeToLocalFileTime(405b61e0,405b61bc) ret=5f40e2ec tid=08066638 Ret kernel32.FileTimeToLocalFileTime() retval=00000001 ret=5f40e2ec tid=08066638 Call kernel32.FileTimeToSystemTime(405b61bc,405b61ac) ret=5f40e302 tid=08066638 Ret kernel32.FileTimeToSystemTime() retval=00000001 ret=5f40e302 tid=08066638 Call msvcrt.mktime(405b614c) ret=5f40e3b3 tid=08066638 Ret msvcrt.mktime() retval=3adae6b2 ret=5f40e3b3 tid=08066638 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=c0000005 flags=0 Call ntdll.RtlRaiseException(404a4aa8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4788) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4468) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a4148) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a3e28) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a3b08) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a37e8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a34c8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a31a8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2e88) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2b68) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2848) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2528) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a2208) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a1ee8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Call ntdll.RtlRaiseException(404a1bc8) ret=405e1056 tid=08066638 trace:seh:EXC_RtlRaiseException code=80000100 flags=1 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=11 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=80000100 flags=11 Segmentation fault Any idea what's going on here ? Somehow the mktime() call seems to be a bit unhealthy. Not to mention the seh mess... Andreas Mohr

2 1

Re: Traces: fs -> tid
by Alexandre Julliard April 16, 2001

April 16, 2001

Francois Gouget <fgouget(a)free.fr> writes: > Also, this is why I think it's nice to have the tid on each trace. If > not using +relay there is no indication of which thread is issuing the > trace. I'm not opposed to a +tid option to switch on thread information on all traces. But I think +relay should always display the thread info, we will get too many useless traces if it doesn't. -- Alexandre Julliard julliard(a)winehq.com

4 5

InstallShield (resend)
by Daniel Walker April 15, 2001

April 15, 2001

I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why. I tryed changind it to "if (dwFlags & PSP_USETITLE && LOWORD(lppsp->pszTitle) != 0)" but it didn't have any effect. I also tryed reverting the PSP_USETITLE flag with no effect. Anyone have any ideas why there isn't a title? The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work.. Daniel Walker --- ./dlls/comctl32/propsheet.c Mon Feb 12 10:08:31 2001 +++ ../../wine-20010305/dlls/comctl32/propsheet2.c Sat Apr 14 17:22:59 2001 @@ -296,12 +296,10 @@ if (dwFlags & PSP_USETITLE) { - if ( !HIWORD( lppsp->pszTitle ) ) - { char szTitle[256]; - - if ( !LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) - return FALSE; + + if ( !HIWORD( lppsp->pszTitle ) && LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) + { psInfo->proppage[index].pszText = HEAP_strdupAtoW(GetProcessHeap(), 0, szTitle );

1 0

Strange crash
by Dmitry Timoshkov April 15, 2001

April 15, 2001

Hello all. Could anybody help to find the source of the following crash? Do this crash look known to somebody? ... Unhandled exception: c000008f in 32-bit code (0x40897fde). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40897fde (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffffffe(%edx) 69 } Wine-dbg>bt Backtrace: =>0 0x40897fde (X11DRV_PEN_SelectObject+0x8e(dc=0x4038bbbc, hpen=0xffe7, pen=0x40842034) [pen.c:69]) (ebp=41f35aac) 1 0x40895a73 (X11DRV_SelectObject+0xb3(dc=0x4038bbbc, handle=0xffe7) [objects.c:62]) (ebp=41f35ad0) 2 0x4082a789 (SelectObject+0x75(hdc=0x68, handle=0xffe7) [gdiobj.c:867]) (ebp=41f35af0) 3 0x4081fceb (DC_InitDC+0x47(dc=0x4038bbbc) [dc.c:163]) (ebp=41f35b08) 4 0x40820919 (CreateDCA+0x135(driver=0x4083745d, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x4083745d) [dc.c:579]) (ebp=41f35c50) 5 0x40823ddc (CreateDIBitmap+0x144(hdc=0x60, header=0x4038b4ec, init=0x4, bits=0x407bc308, data=0x4038b4ec, coloruse=0x0) [dib.c:850]) (ebp=41f35c80) 6 0x40782069 (CURSORICON_CreateFromResource+0x2dd(hInstance=0x0, hObj=0x0, bits=0x407bc2a0, cbSize=0x2e8, bIcon=0x1, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [cursoricon.c:550]) (ebp=41f35d14) 7 0x40782647 (CURSORICON_Load+0x257(hInstance=0x106, name=0x7f00, width=0x20, height=0x20, colors=0x100, fCursor=0x0, loadflags=0x8040) [cursoricon.c:777]) (ebp=41f35d64) 8 0x40784da7 (LoadImageW+0x12f(hinst=0x0, name=0x7f00, type=0x1, desiredx=0x20, desiredy=0x0, loadflags=0x8040) [cursoricon.c:2268]) (ebp=41f35d98) 9 0x40784c4e (LoadImageA+0x7e(hinst=0x0, name=0x7f00, type=0x1, desiredx=0x0, desiredy=0x0, loadflags=0x8040) [cursoricon.c:2208]) (ebp=41f35dcc) 10 0x407840c6 (LoadIconA+0x26(hInstance=0x0, name=0x7f00) [cursoricon.c:1792]) (ebp=41f35df0) ... Commenting lines 36-37 physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * dc->xformWorld2Vport.eM11 * 0.5); in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. Why call to floor() leads to crash?

1 0

KC Wine & WWN
by Brian Vincent (C) April 14, 2001

April 14, 2001

Over the last few days I've talked with Eric Pouech and Zack Brown about taking over the KC Wine and Wine Weekly News updates. It looks like I've got the first issue ready to go. Anyway, here's just some of my thoughts on it, and I'd welcome any and all feedback: - Right now my ISP at home is really messed up. At least in the short term I'll be doing a lot of this at work. Unfortunately that means I'll be mostly using Hypermail archives and some really editing methods. I won't be subscribed to the list, but I'll gladly receive email at the address below. - Unfortunately that also means I don't have CVS access right now. At some point I'd like to get WWN going again, but it might be several weeks. - Also, I always like the CVS commit summary, who used to write that? I'd like to incorporate that into the KC Wine page eventually. - My technical skills are not nearly as good as Eric's. So some of my summaries might be a little off. Hopefully I'll get better over time. - IMHO, these updates are a great PR tool for the project. Screenshots, product reviews, and news stories about Wine are very helpful. I'd encourage all of you to send me any news like this. I'll definitely include it. - Along those same lines, in the future I'll probably setup a screenshots page or something like that. ------------ Brian Vincent Copper Mountain Telecom brianv(a)ski-copper.com

2 1

InstallShield
by Daniel Walker April 14, 2001

April 14, 2001

I've been working on getting the Free Borland installer working. It uses installshield so I think this pertains to all installshield installers .. I've found a problem in propsheet.c , PROPSHEET_CollectPageInfo() . It appears that the property pages that come out of the installer have the PSP_USETITLE flag set. So wine attempts to get the title from the pszTitle field. The problem occurs because the pszTitle field is null. Wine try's to use it as a resource ID then fails. From reading over some MS docs I think windows, in this situation, reverts the PSP_USETITLE flag then uses the title in the template. So far I can get the installer to work, but it doesn't have a title or caption I haven't figured out why. I tryed changind it to "if (dwFlags & PSP_USETITLE && LOWORD(lppsp->pszTitle) != 0)" but it didn't have any effect. I also tryed reverting the PSP_USETITLE flag with no effect. Anyone have any ideas why there isn't a title? The patch below should fix the borland installer and , I assume, other install shield installers. Let me know if this patch doesn't work.. Daniel Walker --- ./dlls/comctl32/propsheet.c Mon Feb 12 10:08:31 2001 +++ ../../wine-20010305/dlls/comctl32/propsheet2.c Sat Apr 14 17:22:59 2001 @@ -296,12 +296,10 @@ if (dwFlags & PSP_USETITLE) { - if ( !HIWORD( lppsp->pszTitle ) ) - { char szTitle[256]; - - if ( !LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) - return FALSE; + + if ( !HIWORD( lppsp->pszTitle ) && LoadStringA( lppsp->hInstance, (UINT) lppsp->pszTitle, szTitle, 256 ) ) + { psInfo->proppage[index].pszText = HEAP_strdupAtoW( GetProcessHeap(), 0, szTitle );

1 0

Re: debugger startup
by Alexandre Julliard April 13, 2001

April 13, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > apart, from always using argv[0] (and transposing it to a windows > filename when needed), is there another fix ? You can set WINEPRELOAD to make sure we load the right file; so the exec would be something like: WINEPRELOAD=winedbg.so exec wine $* -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: debugger startup
by Alexandre Julliard April 13, 2001

April 13, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, this has a major holes: > - since the process creation in Wine knows the created process is not > a PE image, it doesn't set the info on the server side for the newly > created process ; after the exec in the shell script, the info cannot > be retrieved from the parent, hence an error What makes you think that? Of course the info is set for non-PE binaries too, otherwise you could never debug a Winelib app. > perhaps, the best fix would be to merge the init_process/new_process > server calls I don't see how you could possibly do that. new_process is done by the parent, and init_process by the child; they serve very different purposes. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard April 12, 2001

April 12, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Hopefully I get the cutting and pasting right now... > > ... > Call KERNEL.88: LSTRCPY(0x045f781a,0x02ef7044 "%CMDLINE%") ret=02e7:0687 ds=02f7 > Ret KERNEL.88: LSTRCPY() retval=0x045f781a ret=02e7:0687 ds=02f7 > ... > Call KERNEL.516: GETVDMPOINTER32W(0x045f781a,0x0001) ret=02e7:ae4a ds=02f7 > Ret KERNEL.516: GETVDMPOINTER32W() retval=0x404951ba ret=02e7:ae4a ds=02f7 > ... > Call kernel32.lstrcmpA(404951ba "\021\021\021\021\021\021\021\021\021\021\021\021\021\021\0..."...,407e6cbc "%FINDWINDOWCL%") ret=10001464 tid=081df290 Well, either GetVDMPointer returns the wrong pointer, or someone has written to the buffer in the meantime. You need to show us the full trace if you want us to be able to help. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard April 12, 2001

April 12, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I don't understand this sequence: > > Some strings gets copied to segemented memory > Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff > Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff lstrcpy is supposed to return its first argument (0x046f0018 in this case). Something is very wrong here... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: edit control patch
by lawson_whitney＠juno.com April 11, 2001

April 11, 2001

On Wed, 11 Apr 2001, Dan Engel wrote: > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > Not meaning to beat on you, but - if somebody else patches the same file while you are working on it, it makes garbage of your diff. For a project as big and open as Wine, it is only common sense and common courtesy that we use diff -u. As well as + and - to show what changed, that has also context lines so patch can have some idea if it is FI adding lines where they belong. Besides, Alexandre prefers it. (From <wine>/README, which I think we should all read now and again :-) " If you add something, or fix a bug, please send a patch ('diff -u' format preferred) to julliard(a)winehq.com or to the wine-patches(a)winehq.com mailing list for inclusion in the next release. -- Alexandre Julliard julliard(a)winehq.com " Lawson This message is brought to you by Wine-20010326, junopine-2.0.2, Juno 2.0.11, and pine-4.10 ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: edit control patch
by James Hatheway April 11, 2001

April 11, 2001

Just one little comment, you should make your diffs using the -u (unified diff) option. (ie. cvs -d $CVSROOT -u controls/edit.c > newdiff.diff) That way your patch has "+"s and "-"s instead of ">"s. It makes it easier to read what is changing in the patch... (For example, you patch will look something like this instead:) + INT BkMode; + BkMode = GetBkMode(dc); + SetBkMode( dc, OPAQUE); + SetBkMode( dc, BkMode); -James -- James Hatheway Work: james(a)macadamian.com ~ http://www.macadamian.com Home: jhatheway(a)home.com ~ http://members.home.net/jhatheway "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer" ----- Original Message ----- From: "Dan Engel" <dengel(a)sourceharvest.com> To: <wine-patches(a)winehq.com> Sent: Wednesday, April 11, 2001 10:24 PM Subject: edit control patch > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > > Problem: Edit boxes are, in some cases, displaying selected text as white-on-white, so that it disappeared. > > Analysis: When text is drawn using the x11drv function X11DRV_ExtTextOut, the function does not paint a background rectangle if the background mode for the device context is transparent. In the case of edit controls, there is no attempt to change the background mode to opaque for selected text. > > Solution: In the case of painting reverse text in the edit control (function EDIT_PaintText) set the backgound mode to opaque, and then restore it before exiting the function. > > The patch is attached (wine.diff). > >

1 0

Strange behaviour with GETVDMPOINTER32W
by Uwe Bonnes April 11, 2001

April 11, 2001

Hallo, I don't understand this sequence: Some strings gets copied to segemented memory Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff ... This segmented memory gets mapped to linear memory Call KERNEL.516: GETVDMPOINTER32W(0x0467781a,0x0001) ret=02ef:ae4a ds=02ff Ret KERNEL.516: GETVDMPOINTER32W() retval=0x4043bda2 ret=02ef:ae4a ds=02ff ... Accessing the linear memory returns garbage Call kernel32.lstrcmpA(4043bda2 "\021\021\021\021\021\021... ... ret=10001464 tid=08404b48 I don't see any other accesses to 0x046f:0x0018 or 0x0467781a in between. This happens withthe Encarta 99 setup. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: debugger startup
by Alexandre Julliard April 11, 2001

April 11, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > either we decide that shell scripts shouldn't be used (easy > solution) or we could do something like : > - if the CreateProcess fails, then wait for a certain amount of > time. If after that time the current process isn't currently > debugged, then report the error. Otherwise assume what did happen is > what has been described above CreateProcess already waits a couple of seconds for the new process to show up, so it's probably enough to simply check for the debugger once CreateProcess returns. An easier fix may be to have the script exec the debugger instead of launching it as a child process; this way the debugger parent pid will be the original Wine process, and everything should work fine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: VxD information
by Alexandre Julliard April 11, 2001

April 11, 2001

Maurice van der Pot <griffon26(a)kfk4ever.com> writes: > I'd like to get started on VxD support, but I'm unable to find any useful > documentation on how it's implemented in Wine. I've been looking through > the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection > between a call to int 2F and a call to the functions in vxd.c. The connection is through int 2f ax=0x1684 (in msdos/int2f.c), which does a GetProcAddress on wprocs and returns the vxd entry point to the application. The app then calls the corresponding vxd directly with a normal function call. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RegSetValueEx problem?
by Alexandre Julliard April 11, 2001

April 11, 2001

davep <davep(a)cyw.uklinux.net> writes: > I have now been able to build and run WineMine under NT4, and it works > perfectly. On exit each parameter is saved to the registry as 16 bytes including > the training garbage (not visible in Regedit of course) and when restarted the > exact same 16 bytes are reloaded from the registry. > > It does therefore seem that there is something wrong with Wne's implementation. No, it depends if data[sizeof(data)] is null or not; the +1 on the size is done only if the last byte is null, on the assumption that the programmer forgot to count it (i.e. used strlen(data) instead of strlen(data)+1). It's the usual Microsoft approach of hiding bugs instead of fixing them, and it is definitely what NT does (or we wouldn't be doing such a monstrosity). Now what can happen is that the Microsoft compiler lays out the stack in a different way than gcc, and that the variable that is just above the array on the stack doesn't contain 0 in this case. In fact I suspect that if you run your Windows binary of WineMine under Wine it will work fine too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Traces: fs -> tid
by Alexandre Julliard April 11, 2001

April 11, 2001

Francois Gouget <fgouget(a)free.fr> writes: > Yes, but it would also be the simplest implementation (overdesign can > be ugly too). And if it's the one off hack that it current looks like it > is, why not. > I propose to just let Alexandre decide which implementation, if any, > he thinks would be worth including in CVS. I think we have now wasted enough bandwidth on this non-issue. The relay traces have always displayed the thread info, and will continue to do so. People who are morally offended by the extra 5 characters needed for the tid can hack their local tree, or learn to use sed/awk/perl. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: edit control patch
by Ian Pilcher April 11, 2001

April 11, 2001

Dan Engel wrote: > > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > Word-wrap is nice. :-) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: RegSetValueEx problem?
by Alexandre Julliard April 11, 2001

April 11, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > I have browsed server/registry.c and it seems that the registry > stores a terminating null for strings; so if you have in the registry > file a string like "0123456789", it get in memory a length of 11. > So I guess that the fix would be to fix the length by -1 somewhere > in the path server->ntdll->advapi No, the current behavior is correct for NT; what you want is a version check to get the Win95 behavior. Something like the patch below should do it (and of course WineMine should be fixed to work on NT too). Index: dlls/advapi32/registry.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/advapi32/registry.c,v retrieving revision 1.24 diff -u -r1.24 registry.c --- dlls/advapi32/registry.c 2001/03/23 19:12:01 1.24 +++ dlls/advapi32/registry.c 2001/04/09 20:49:35 @@ -640,8 +640,12 @@ { UNICODE_STRING nameW; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ { + if (type == REG_SZ) count = strlenW( (WCHAR *)data ) + sizeof(WCHAR); + } + else if (count && is_string(type)) + { LPCWSTR str = (LPCWSTR)data; /* if user forgot to count terminating null, add it (yes NT does this) */ if (str[count / sizeof(WCHAR) - 1] && !str[count / sizeof(WCHAR)]) @@ -663,7 +667,11 @@ WCHAR *dataW = NULL; NTSTATUS status; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ + { + if (type == REG_SZ) count = strlen(data) + 1; + } + else if (count && is_string(type)) { /* if user forgot to count terminating null, add it (yes NT does this) */ if (data[count-1] && !data[count]) count++; -- Alexandre Julliard julliard(a)winehq.com

2 1

VxD information
by Maurice van der Pot April 11, 2001

April 11, 2001

I'd like to get started on VxD support, but I'm unable to find any useful documentation on how it's implemented in Wine. I've been looking through the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection between a call to int 2F and a call to the functions in vxd.c. Regards, Maurice van der Pot.

1 0

Re: Traces: fs -> tid
by Alexandre Julliard April 10, 2001

April 10, 2001

Francois Gouget <fgouget(a)free.fr> writes: > But maybe we could ask for traces generated with +relay,+tid instead > of just +relay. > Also when you're working on a specific application for which you have > determined that threads don't play a role, then you would have the > option of omitting the +tid to get simpler traces. I disagree, I think the thread information is important even if you are not chasing a thread problem, simply to tell you which calls are part of the same sequence. It's not possible to make sense of any relay trace if the calls made from different threads cannot be distinguished. If the tid really disturbs you, you can always pipe the output into a sed 's/tid=.*//' or something similar. -- Alexandre Julliard julliard(a)winehq.com

3 2

Traces: fs -> tid
by Francois Gouget April 10, 2001

April 10, 2001

I noticed that fs was replaced by tid in relay (and snoop & co too now). I propose a slightly different version based on the following premises: * when suspecting a threading problem it could be nice to tag each trace with the id of the thread that emits it * when there's no thread issue, then fs and tid are unnecessary and only clutter the traces by making lines longer and harder to read * I find that lines are more readable if the thread id comes first as it's always the same length and doesn't mess up the alignment of the other fields So this patch adds a debug channel called 'tid' which activates printing the tid as the first field of all traces. Actually, it might make sense to merge 'tid' with the 'thread' debug channel. 'Screenshot': 08063178:Call user32.DispatchMessageA(405b6e50) ret=00402135 08063178:trace:relay:WINPROC_CallWndProc (wndproc=0x401c74,hwnd=00000138,msg=WM_SYSCOMMAND,wp=0000f060,lp=00000000) 08063178:Call user32.DefWindowProcA(00000138,00000112,0000f060,00000000) ret=0040206c Comments? Changelog: * dlls/ntdll/ntdll.spec Declare the tid debug channel * dlls/ntdll/debugtools.c, relay32/relay386.c, relay32/snoop.c Output the current thread id as the first field if tid is turned on -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

2 3

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard April 9, 2001

April 9, 2001

"James Hatheway" <james(a)macadamian.com> writes: > I implemented the callback in a very similar way as the Wave out callback > is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), > and WAVEMAP_DstCallback() , look at the data passed in the wom structure > (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will > be able to callback into the app when the WineOSS layer notifies the wavemap > layer. The way it is now (wineoss directly calling the app) > causes my app to crash, and doesn't work that way on waveout. But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: RegSetValueEx problem?
by gerard patel April 8, 2001

April 8, 2001

At 10:54 AM 08/04/2001 +0100, you wrote: > >I've found time to do some more digging, but I'm still stumped. <snip> I have browsed server/registry.c and it seems that the registry stores a terminating null for strings; so if you have in the registry file a string like "0123456789", it get in memory a length of 11. So I guess that the fix would be to fix the length by -1 somewhere in the path server->ntdll->advapi I have tried this but I am not sure at all this is correct : --- registry.c.orig Mon Mar 5 20:34:21 2001 +++ registry.c Sun Apr 8 18:11:39 2001 @@ -799,14 +799,17 @@ struct key_value *value; int index; size_t ret = 0; + size_t l; if ((value = find_value( key, name, &index ))) { *type = value->type; - *len = value->len; - if (value->data && offset < value->len) + l = value->len; + if ((value->type == REG_SZ) && l) l--; + *len = l; + if (value->data && offset < l) { - if (maxlen > value->len - offset) maxlen = value->len - offset; + if (maxlen > l - offset) maxlen = l - offset; memcpy( data, (char *)value->data + offset, maxlen ); ret = maxlen; } Gerard

2 1

Wrc question
by gerard patel April 8, 2001

April 8, 2001

I have looked at wrc code and there is a strange 100K limit on the size of mem allocation : assert(size > 0); assert(size < 102400); res = malloc(size); if(res == NULL) { Baffling code - hardcoded limit hidden in a C file :-/ I removed the assert and wrc was able to handle a 1 megabyte bitmap. Anyone has an idea about the meaning of this limit ? Gerard

2 1

Re: debugger startup
by gerard patel April 8, 2001

April 8, 2001

At 06:32 PM 07/04/2001 +0200, you wrote: <snip> >the setup was that the AeDebug registry key pointed to a shell script, >which in turn, >launched the real debugger (used to set up different context options, >and such) ah that was the problem ? from the bug reports on the news group I had the idea that the key was just not initialized. <snip> >either we decide that shell scripts shouldn't be used (easy solution) The script has an utility, no ? I don't know what it's doing, is the goal to configure the debugger options ? (if yes, maybe using an environment variable could give the same result ??) Gerard

1 0

Re: RegSetValueEx problem?
by davep April 8, 2001

April 8, 2001

On Sun, 01 Apr 2001, you wrote: > At 01:59 PM 31/03/2001 +0100, you wrote: > > <snip> > >Compiling and running Winemine under Windows 95 this problem doesn't occur. > >Win95 truncates the value at the first null. > > Under NT4 SP6, if I write (for example) '47' + 0 + 13 bytes of garbage, I get > exactly that when querying with the same buffer length (16). > If I use a longer buffer, one binary 0 is appended. > If I use a shorter buffer, nothing is copied and the function does not succeed > (ERROR_MORE_DATA). > > Of course under Regedit the garbage is not displayed; regedit displays only '47' > in this case. I've found time to do some more digging, but I'm still stumped. This is the trace from WineMine saving one parameter in the registry (-debugmsg +relay,+reg): Call advapi32.248: RegSetValueExA(00000038,4038cae0 "Xpos",00000000,00000001,405e66a0,00000010) ret=40388dc8 fs=008f Call kernel32.643: MultiByteToWideChar(00000000,00000000,405e66a0 "3",00000010,00000000,00000000) ret=407c4fe9 fs=008f Ret kernel32.643: MultiByteToWideChar() retval=00000010 ret=407c4fe9 fs=008f Call kernel32.553: HeapAlloc(40390000,00000000,00000020) ret=407c4fff fs=008f Ret kernel32.553: HeapAlloc() retval=403d62fc ret=407c4fff fs=008f Call kernel32.643: MultiByteToWideChar(00000000,00000000,405e66a0 "3",00000010,403d62fc,00000010) ret=407c5023 fs=008f Ret kernel32.643: MultiByteToWideChar() retval=00000010 ret=407c5023 fs=008f Call ntdll.419: RtlInitAnsiString(405e658c,4038cae0 "Xpos") ret=407c5038 fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000000 ret=407c5038 fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(40113578,405e658c,00000000) ret=407c504d fs=008f Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c504d fs=008f Call ntdll.230: NtSetValueKey(00000038,40113578,00000000,00000001,403d62fc,00000020) ret=407c5067 fs=008f trace:reg:NtSetValueKey (0x38,L"Xpos",1,0x403d62fc,32) Ret ntdll.230: NtSetValueKey() retval=00000000 ret=407c5067 fs=008f Call kernel32.559: HeapFree(40390000,00000000,403d62fc) ret=407c5083 fs=008f Ret kernel32.559: HeapFree() retval=00000001 ret=407c5083 fs=008f Call ntdll.466: RtlNtStatusToDosError(00000000) ret=407c5089 fs=008f Ret ntdll.466: RtlNtStatusToDosError() retval=00000000 ret=407c5089 fs=008f Ret advapi32.248: RegSetValueExA() retval=00000000 ret=40388dc8 fs=008f So the 16-byte buffer (containing the character "3", a null, and 14 bytes of garbage) has been converted into a 32-byte unicode string and saved. Good. Inside the registry this looks like: "Xpos"="3\0\0\0`\x00ca7@\0\0\0\0\0\0\0@" Now if we read that value back in this is what happens: Call advapi32.236: RegQueryValueExA(00000034,4038cae0 "Xpos",00000000,405e6970,405e697c,405e6974) ret=40388a38 fs=008f trace:reg:RegQueryValueExA (0x34,"Xpos",(nil),0x405e6970,0x405e697c,0x405e6974=16) Call ntdll.419: RtlInitAnsiString(405e6764,4038cae0 "Xpos") ret=407c5565 fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000000 ret=407c5565 fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(40113578,405e6764,00000000) ret=407c557a fs=008f Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c557a fs=008f Call ntdll.177: NtQueryValueKey(00000034,40113578,00000002,405e676c,00000100,405e6760) ret=407c55b0 fs=008f trace:reg:NtQueryValueKey (0x34,L"Xpos",2,0x405e676c,256) Ret ntdll.177: NtQueryValueKey() retval=00000000 ret=407c55b0 fs=008f Call kernel32.889: WideCharToMultiByte(00000000,00000000,405e6778 L"3",00000011,00000000,00000000,00000000,00000000) ret=407c56c9 fs=008f Ret kernel32.889: WideCharToMultiByte() retval=00000011 ret=407c56c9 fs=008f Call ntdll.466: RtlNtStatusToDosError(80000005) ret=407c57be fs=008f Ret ntdll.466: RtlNtStatusToDosError() retval=000000ea ret=407c57be fs=008f Ret advapi32.236: RegQueryValueExA() retval=000000ea ret=40388a38 fs=008f RegQueryValueEx maintains that there are 17 characters and since they won't fit in the buffer the function aborts. Incidentally, the "null-terminate if the user forgot" trick is carried out both in RegSetValueEx *and* RegQueryValueEx. Would not once be enough? -- Dave Pickles

1 0

debugger startup
by eric pouech April 7, 2001

April 7, 2001

someone (IIRC Gérard) had issues when starting the debugger when an exception occured. the setup was that the AeDebug registry key pointed to a shell script, which in turn, launched the real debugger (used to set up different context options, and such) however, what happens is: - the main program (the one generating the exception) tries to launch the debugger using the AeDebug - the process creation forks, and exec:s the debugger program - at the unix level, the debugged program starts, which runs the shell script, which then starts the debugger - at the windows level, since the shell script isn't a Wine process, the call fails (even if an Unix process is created) - the exception handler then reports the error in process creation and stops the main program, whereas the debugger has been started for this program either we decide that shell scripts shouldn't be used (easy solution) or we could do something like : - if the CreateProcess fails, then wait for a certain amount of time. If after that time the current process isn't currently debugged, then report the error. Otherwise assume what did happen is what has been described above comments are welcome A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard April 7, 2001

April 7, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > using the Wine debugger (or any program using the debugging API) may > have some drawbacks. As the API is designed, it's not possible to > get control of the debugged program between its creation and its > entry point entering this makes very difficult to let the Wine > debugger trigger the expected features by poking the memory in the > debuggee. That's not exactly correct, the debugger can intercept the dll loads and break in the dll init code. Since with dll separation all Wine inits will be done inside dlls, the debugger should be able to intercept everything from the point we connect to the wineserver. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Nasty Wine/kernel bug, anyone?
by Ulrich Weigand April 6, 2001

April 6, 2001

> If I were going to make more WAGs (Wild Assed guesses), > I'd hazard a guess that this was due to my Alsa sound system > (running on the AC97 codec on my Asus motherboard). > > I tried to walk the stack back, but didn't get very far > (after the first time of wrongly computing the hex offset > from a .s file, I gave off, stomped off to look > for a better disassembler and gave up). If you have the 'vmlinux' file, try objdump --disassemble vmlinux > My best guess is that we're coming through dentry_open > (xc012e7fe)/ chrdev_open (0xc012f66c) > /soundcore_open (0xc01bbf71). However, I wasn't > seeing a familiar EBP/EIP pattern, so I'm possibly just > pulling random symbols out of the air. Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule [I am assuming that you have 256MB main memory. Correct?] Now, the question is still, who is sleeping on that semaphore and why? >From the call trace, it would seem that some sound-related module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...) We can continue to track in two directions. First, we can try to locate the point within the Wine application where the open() syscall is performed. >From the trace we see that the system call instruction is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY ) [The stack pointer value is rather weird, I'd say ...] This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis. The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ... The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this: Call Trace: [<d0826a42>] [<d087ce3e>] to a file and pipe the file through ksymoops. In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 1

Re: [PATCH] Name Thread Exception support in Wine debugger
by eric pouech April 6, 2001

April 6, 2001

James Hatheway wrote: > > Hi guys, > > As I mentioned in an earlier email to the Devel mailing list, I discovered the > application I am supporting started raising more exceptions than usual. These > turned out to be an undocumented signal to the MS VC6 debugger to name the > current thread. You can read more about this at: > http://www.vcdj.com/upload/free/features/vcdj/2001/03mar01/et0103/et0103.asp > or searching google.com or deja.com for "0x406D1388". This patch fixes > the WINE debugger to handle this exception, just like MS VC6 debugger does. something seems wrong in your patch... the szName field from the exception field is never copied from the debugged program space to the debugger space (only the address is) so, you should use ReadProcessMemory instead (something like ReadProcessMemory(pThread->name, sizeof(pThread->name), DEBUG_CurrThread->process->handle, pThreadName->szName); ) also, I don't like the fact that you put the #define in a public header file and the exception struct definition inside the file it would make more sense to me if both were either public or private (I'd go for private, since those values don't seem to be defined in Windows' standard headers) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

WWN
by eric pouech April 6, 2001

April 6, 2001

for personal reasons, I will no longer be able to write the WWN (and I haven't in the last couple of weeks) so, if someone wishes to take the job over, I'd be happy to help him (her) to set it up A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: [PATCH] deferred trace
by gerard patel April 6, 2001

April 6, 2001

At 03:00 PM 14/03/2001 -0800, you wrote: <snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed. Expressed ? What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time. I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people. And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it. So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-) Gerard

2 1

Re: Make PostScript driver less loquacious
by Dmitry Timoshkov April 4, 2001

April 4, 2001

"Ian Pilcher" <ian.pilcher(a)home.com> wrote: > dlls/wineps/init.c, ppd.c > > Change some PS driver FIXMEs/MESSAGEs to WARNs I think it's not the time to do it. Those messages/fixme's help a lot to add missing page and bin type into psdrv: they are not complete now. And without message about missing fonts in ppd/afm it would be nightmare to track down problems with ps fonts at least for me.

3 8

Newbie question...
by Elan Feingold April 4, 2001

April 4, 2001

Hi, I have a 3rd party x86 DLL file, that I would like to use under Linux. I have read the documentation on the specmaker tool, which would seem to provide some help. The thing that makes my case a bit different is that I would like to use the DLL within a Linux native program, not a WineLib program (its just a command line application and I need it to be very lightweight). Im pretty sure the Wine code can help me out, but Im not sure what the easiest way to proceed is, and what parts I need to use. Thanks in advance, -elan

2 1

T@x2001: Linuxport via Wine
by Joerg Mayer April 3, 2001

April 3, 2001

Just found the following at the SuSE portal pages (German only): http://portal.suse.de/de/content/reports/tax2001.html Rough translation on the introductory paragraph: The program t(a)x by Buhl Data has been around for the Windows platform for some years. This year, the current version T(a)x2001 has been made available for the Linux OS for a first time. In order to do this the Windows emulator Wine was used. Wine allows using Windows applications running Linux. This emulator has been modified to work with t(a)x2001. The summary as far as Wine is concerned: The program should be more stable and faster. Does anyone know which modifications were made to wine? 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.

1 0

Re: Interesting Magic # exception understood by the MS debugger...
by Alexandre Julliard April 3, 2001

April 3, 2001

"James Hatheway" <james(a)macadamian.com> writes: > OK, I don't know too much about the internals of the WINE debugger, so > here goes. Is there a field for this already, or should I make a new > field in DBG_THREAD structure? (I think that seems like the right place > for it) Yep, you can add a field there. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Interesting Magic # exception understood by the MS debugger...
by Alexandre Julliard April 3, 2001

April 3, 2001

"James Hatheway" <james(a)macadamian.com> writes: > For now, I put the little hack I attached to this mail in my tree to > save my sanity. My question to the list is, (A) is there a way to name > threads in Linux/Unix (I don't think so, but of course I could be wrong) No, and we don't need that. > and (B) should we support MS's hack somehow in the official tree? Yes, in the Wine debugger, which should store the name and simply continue execution, just like the MSVC debugger does. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells April 3, 2001

April 3, 2001

Okay, I've thought about how to make the wine kernel module easier to use for Wine, and I've started adding another API to it - one that interprets Wine server messages. When I designed the module initially, I decided to make it possible to add as many API's as I liked, so in theory it's not too difficult. I'm currently performing a major rearrangement of the files that comprise the module: * Splitting the current win32 API bits out of the same files that contain the actual object class implementations. * Putting the core and the API's in separate subdirectories. * Abstracting name support, so that the internal API takes an "object name" which the user API is responsible for extracting from userspace and converting from WCS/MBS as necessary. * Fixing introduced bugs. This does not mean that I'm getting rid of the Win32 API I've already got! It will just be optional. Calling the new API will be by means of either: union generic_request msg; syscall(__NR_win32,WINESERVER_WINE_SERVER_MESSAGE,&msg); Or: union generic_request msg; int fd = open("/proc/wineserver"); struct WineserverIoctl wioc = { WINESERVER_WINE_SERVER_MESSAGE, &msg }; ioctl(fd,WINESERVER_IOCTL,&wioc); David

1 0

Interesting Magic # exception understood by the MS debugger...
by James Hatheway April 2, 2001

April 2, 2001

Hi guys, I encountered something interesting while debugging a newer build of my application. I noticed that all of a sudden I was receiving approximately 10 new exceptions in the debugger on startup that I wasn't receiving before. After digging a little, I found out that the app coders were making use of a 'hidden' feature of MS VC that allowed you to name your threads (thus allowing for easier debugging). To do this, you call RaiseException with the code of 0x406D1388. (Search on deja.com or google.com for "0x406D1388" for details.) The windows debugger seems to be on the lookout for this code. Of course, what it does in wine is just breaking into the debugger many times and getting on my nerves. :-) For now, I put the little hack I attached to this mail in my tree to save my sanity. My question to the list is, (A) is there a way to name threads in Linux/Unix (I don't think so, but of course I could be wrong) and (B) should we support MS's hack somehow in the official tree? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: RegSetValueEx problem?
by davep April 2, 2001

April 2, 2001

On Sun, 01 Apr 2001, you wrote: > At 01:59 PM 31/03/2001 +0100, you wrote: > > <snip> > >Compiling and running Winemine under Windows 95 this problem doesn't occur. > >Win95 truncates the value at the first null. > > Under NT4 SP6, if I write (for example) '47' + 0 + 13 bytes of garbage, I get > exactly that when querying with the same buffer length (16). > If I use a longer buffer, one binary 0 is appended. > If I use a shorter buffer, nothing is copied and the function does not succeed > (ERROR_MORE_DATA). > > Of course under Regedit the garbage is not displayed; regedit displays only '47' > in this case. Ah, I didn't know Regedit was not giving the true value. That complicates matters even more. It seems I'll have to do some experiments. -- Dave Pickles

1 0

Re: event flags using pipes
by Alexandre Julliard April 1, 2001

April 1, 2001

Mike McCormack <mike_mccormack(a)looksmart.com.au> writes: > Why? By changing the client side implementation of SetEvent and > ResetEvent the use file descriptors and implementing a client side > unix fd/handle cache, it should be possible to eliminate server calls > for these operations and improve the performance of wineserver. I don't see how you can get the right semantics this way, but maybe I missed something. How will you be able to wake a single thread for auto-reset events, but all of them for manual events? How are you going to implement PulseEvent? How can you do WaitForMultipleObjects for an auto-reset event without a race? -- Alexandre Julliard julliard(a)winehq.com

1 0

event flags using pipes
by Mike McCormack April 1, 2001

April 1, 2001

Hi, i've written an implementation of windows event flags using pipes. (The modifications are confined to server/event.c for the moment.) Why? By changing the client side implementation of SetEvent and ResetEvent the use file descriptors and implementing a client side unix fd/handle cache, it should be possible to eliminate server calls for these operations and improve the performance of wineserver. Anyway, any comments are welcome. Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0