wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

Re: ImageList fixes
by Michael Stefaniuc 26 Feb '02

26 Feb '02

Hello, sorry to replay so late but I didn't had the time to test your patch before. On Fri, Feb 22, 2002 at 08:39:39PM -0500, Dave Hawkes wrote: > The hotspot handling in imagelist is broken. This fix partially repairs it. ... and breaks it too. With your patch the hotspot handling in FreeSolitaire is broken. The attached patch reverts a small portion of your patch and fixes the recursion. For what do you need bHSPending? With the recursion removed it's pretty useless. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Erich!!!! Very Cool! Thanks for your prompt answer. Please send me the patch. I will surely test it! Just one question on your answer, my two apps are called DISP.EXE and PDV.EXE Is one of them 16 and the other 32 bit ? If I recompile both of them to 32 bit or 16 bit, should DDE work? I can also try that. Frankly, I didn´t even know that one was 16 and the other 32 bit. Miguel Feitosa At 21:11 26/2/2002 +0100, you wrote: > > The http://www.winehq.com/News/status.html states that the implementation > > of the serial/parallel port > > is 90% complete but that DDE is still being implemented by Eric Pouech and > > not functional. >the status page is now a bit outdated >DDE (and DDEML) now kinda work >however, some 16 bit support is still missing in DDE (and DDEML), hence >your >problems as the trace shows >as of today : >- two 32 bit apps should be able to communicate through DDE >- two 16 bit apps should be able to communicate through DDE >- however, a 16 bit and a 32 bit app will not be able to communicate > >I have a yet unfinished patch here that should (partly) take care of >that >if you have the wine source and are ready to do some testing, I can >provide >you the patch to see if it helps in your situation > >as DDEML is a pure 16 bit DLL (the 32 bit DDEML implementation is part >of >USER32), it's very unlikely that native DDEML will work in wine >so, sticking to builtin USER/USER32/DDEML is the only viable solution >(even >if it's not completly done yet) > >A+

2 1

Artilcle - loading Windows DLL's under Linux
by Nick Temple 26 Feb '02

26 Feb '02

Hello All -- I am working on an article about how to load Windows DLL's under Linux. This system is for stand-alone Linux applications that only need to use some of the logic in a single Windows DLL, not a full WINE implementation. The code has been "borrowed" and tweaked from the avifile distribution (which is GPL'd), originally borrowed from WINE (BSD license), and will be re-released under the GPL or LGPL once the article is published. I have found the following names in the headers of the various files I'm using: Eric Youndale & Erik Bos Martin von Löwis Marcus Meissner Thomas Sandford Robert J. Amstadt Alexandre Julliard I plan to give credit either at the end of the article or in a sidebar. I would also like to put in a "blurb" about the WINE and avifile projects in the article (or sidebar) as well. Is there a standard blurb I can use? Also, I want to make sure that the appropriate people / organizations get credit. I am willing to accept comments on the completed version before publication to make sure I'm not stepping on any toes, please contact me directly if you are interested. Thanks in advance for the feedback, Nick

7 6

wineserver request size
by Eric Pouech 26 Feb '02

26 Feb '02

how to handle large wineserver request structure ? I've been working on adding the dwFillAttribute handling to CreateProcess (and passing between parent and child) while I was at it, I also added all the other fields (window geometry, console title/size...) at the end the two requests used in the process (new_process and init_process) are larger than the fixed request_max_size structure (80 bytes would be needed) so, what's the preferred way of handling this: 1) bump the request_max_size to the needed size (but all requests will be penalized about it) 2) remove the request_max_size (therefore aligning the size of the request on the one of the biggest available) 3) try to compress the structure fields (most of the data are 32 bits, whereas they would fit in 16 bit fields) 4) store the data above the 64 bytes into the variable part of the message (but that would break the current structure scheme) A+

3 2

Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Hi! I started using wine (wine-20020122 compiled from source tarball) a couple of weeks ago to run a store-point-of-sale application. The idea is to port this windows application to linux. Before porting, we decided to check if the app could be emulated on linux with wine or recompiled with winelib. This is also necessary to run proprietary windows DLLs from third parties such as credit card companies that bind the application to specific hardware. The software uses a lot of external hardware such as printers, barcode scanners, special keyboards etc. These hws usually communicate through the serial port. Another important feature of the software is the use of DDE - Dynamic Data Exchange from the windows API. The application is broken into at least two executables that communicate through DDE. The http://www.winehq.com/News/status.html states that the implementation of the serial/parallel port is 90% complete but that DDE is still being implemented by Eric Pouech and not functional. After reviewing the manuals and spending a few days on trial runs, I decided to try and bring in the native DDEML.DLL and see if the exe´s would communicate. QUESTION: Should this native windows library work under wine, has anybody tried this? When I tried running the software with the native DDE engine (from Win98), I get DDE errors and a warning saying that DDE is not functional yet. This is expected as reported by the status.html page. When I tried running the software with a setup that only the DDEML.DLL was native, the program crashed with an exception. I tried running the program with several debug channels but couldn´t detect the problem. The only thing learned was that the program seemed to be crashing inside USER.DLL builtin code. I then tried several different native/builtin setups using mainly the following DLLs: Native DLLs DDEML.DLL OLE32.DLL COMCTL*.DLL COMDLG*.DLL SHELL.DLL SHELL32.DLL I even tried bringing in USER and USER32. Some of these setups were documented not to work and didn´t. Everytime I got a setup that seemed to work, the software would crash with basically an exception or page fault. I then decided to use winedbg. I was able to get a stack trace of the software at the time of the exception. It is at the end of this email. I also put a complete run of winedbg --debugmsg +msg 'c:\sw\store.exe' in http://admin.vmn.com.br/wine/out.txt From the trace it seemed that USER builtin in code was not yet finished and handling correctly DDE messages or had a messaging bug related to DDE or not. I read the functions in c code from the trace and couldn´t see any obvious problems. They seemed complete and finished. QUESTION: Is the builtin USER.DLL complete? QUESTION: Should it interact correctly with DDEML.DLL? If DDEML.DLL and USER.DLL were communicating through COM then they should interact correctly but since DDE is a protocol dating back to win3.1, probably older than OLE and COM, maybe they don´t. I have thought of reworking the original software to use SOCKETS but this is quite a lot of work. I am new to wine so I may be missing something obvious. Thanks in advance for any help. Miguel Feitosa TRACE First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). In 32-bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>130 params = GlobalLock(hMem); Wine-dbg>1142 if (!UnpackDDElParam( info->msg, info->lparam, &uiLo, &uiHi )) Wine-dbg>1587 return post_dde_message( dest_tid, &data, info ); Wine-dbg>1995 return put_message_in_queue( dest_tid, &info, NULL ); Wine-dbg>89 return PostMessageW( hwnd, msg32, wparam32, lparam ); Wine-dbg>1052 return proc( Wine-dbg>

2 1

Menu Item problem(was Notepad not remaining language selection)
by Sylvain Petreolle 26 Feb '02

26 Feb '02

Hi, I have implemented 2 procedures to set the language used by Notepad at startup. Now it selects language by using string key "Language" under HKCU\\Software\\Wine\\Notepad. Restore of the language functions now. But I'm new in Windows coding so I don't know which procedure is called when I click on an item in the Language menu.So saving the language in the registry is not called.The procedure is ready to use but never called. Could someone help ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

4 7

Out of process COM objects & Installshield v6
by Sander van Leeuwen 26 Feb '02

26 Feb '02

Hi, What's the current state of OOP COM objects in Wine? I've noticed a lot of related changes, but have yet to find an InstallShield 6 installer that works. (I did copy the stdole*.tlb files to the windows & system directory) After porting the OLE changes to Odin, I tried the Java 1.4 installer. It fails with error 0x80070057 (CoMarshalInterface; failed to marshal interface) Trying the same installer in Wine (built from latest CVS) results in the same error There's a fixme for NdrDllRegisterProxy for the same GUID that fails in CoMarshallInterface. Perhaps that's the cause. Before I start debugging this, I'd like to know if it is supposed to work at all. Thanks, Sander

5 7

RE: License change vote results
by Kevin Lawton 26 Feb '02

26 Feb '02

Dimi, Come on now, it isn't as if Brett is accusing Codeweavers of actually doing this. He just pointed out a potential flaw in the ballot system. The fact that you failed to comprehend the meaning of such a simple message casts some doubt on your ability to contribute much of any use to either this or any other list. The fact that you so arrogantly dismiss an other's contribution to the discussion makes one wonder just who it is who should 'do everyone a favour and bugger off' ?. There are enough adversaries out there without creating more. I can only suggest that you try to behave more like a gentleman in the future. Kevin. -----Original Message----- From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] Sent: 19 February 2002 23:11 To: Brett Glass Cc: Roger Fujii; wine-devel(a)winehq.com Subject: Re: License change vote results On Tue, 19 Feb 2002, Brett Glass wrote: > This is an interesting point. Codeweavers could easily have > "stuffed" the ballot box by insisting that its employees > vote the way it wanted (and/or by claiming that they'd be > out of work if they did not). Well, not that I did not have enough reasons before, but this lands you in my killfile. And as far as I'm concerned, YOU ARE NOT WELCOMED on this list. So do everyone a favour, and bugger off. -- Dimi.

11 16

Re: Alternative make scripts
by Dimitrie O. Paun 26 Feb '02

26 Feb '02

On Tue, 26 Feb 2002, Andriy Palamarchuk wrote: > Does that mean we don't need alternative build scripts > in the Wine tree (probably except winetest)? I'd personally would want to see our Makefile system be portable enough to do this. When I tried porting Wine to cygwin, they were good enough, so I see no reason for a separate script. -- Dimi.

1 0

About that eeevil library naming decision...
by Andreas Mohr 26 Feb '02

26 Feb '02

Hello all, I've just had prime evidence of yet another library naming conflict: libuser.so (which is in package libuser-0.32-1). (installed as /usr/lib/libuser.so) Other examples would be libole.so or libavifile.so. So could we please *finally* rename the wine libraries to libwineuser.so or maybe even better libwine_user.so ? Thank you very much... Yeah, people told me that wine libraries would be in separate directories anyway, so no need for that naming. But believe me, I HATED that decision from day 1. Packagers simply won't always choose a separate directory for wine libraries. (especially for "global" installs without a wrapper script) Thus there'll be lots of trouble for some people. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel