wine-devel

wine-devel@winehq.org

6 participants
84465 discussions

Registering DLL's
by Jeff Smith 06 Dec '02

06 Dec '02

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]" Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg. About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions. Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 4

Cabinet FDICreate()
by Mike Hearn 06 Dec '02

06 Dec '02

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: wine/tools Makefile.in .cvsignore mingwrap.c
by Dimitrie O. Paun 06 Dec '02

06 Dec '02

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

1 0

Re: Loading Autorun.inf on CD's
by Dustin Navea 06 Dec '02

06 Dec '02

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

1 0

[Alsa] A simple test for IDirectSound.GetCaps.
by Sylvain Petreolle 06 Dec '02

06 Dec '02

Running the dsound test using winealsa.drv, the program hangs and try to call the debugger. [syl@snoop dsound]$ make test make[1]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400bb478 make[1]: Quitte le répertoire `/home/wine/dlls/dsound/tests' According to http://www.delphifaq.com/fq/q1061.shtml, exception c0000194 is STATUS_POSSIBLE_DEADLOCK. How could I debug the tests ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

WineBuild/WineLib <-> MFC
by jaymz＠free.fr 05 Dec '02

05 Dec '02

Going further into the MFC dll handling, I raised the following issue: I have two dynamic libs (mfc.dll.so and myapp.dll.so), both loaded by the wrapper (myapp.exe.so). The problem is that global or static class variables are badly exported from mfc.dll.so to myapp.dll.so. Here's an example: In mfc.dll.so, let assume that I export a global integer variable named myVar. I add @ extern myVar myVar in mfc.dll.spec. When I do a GetProcAddress of myVar from the wrapper, the returned address is good, but when I link my application, myVar is undefined (WineBuild did not include it in myapp.dll.spec.c). If I add instead in the spec file something like @ stdcall myVar() myVar, it's still good when using GetProcAdress, I can now link my application, but at runtime, the address of the variable is not the good one, so I'm using corrupted data ! Therefore, when the app runs, all static data are in fact not or badly initialized and it crashes. What's the exact syntact to correctly export class static variable from a dll ? Thanks a lot for your attention.

2 1

[RFC] wrc & windres
by Dimitrie O. Paun 05 Dec '02

05 Dec '02

Hi folks, As we discussed here a few weeks ago, there is good reason to have a windres compatible mode for wrc. Needless to say, this will greatly ease porting apps that use windres to Winelib. More information about the issues at hand can be found in this thread: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html That being said, what would it take to (1) keep the current wrc behavior, and (2) make it compatible with windres? First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc -> .res. It would be interesting (from the Winelib point of view) to also support .rc and .res -> .o. The other transformations supported by windres (.o -> .res -> .rc) are not as interesting, as they are not used in the build process. With that in mind, what do we need to do to have said compatibility? Well there are two things: 1. Support windres command line options 2. Add conversion of .rc and .res to .o I will treat each of these below. Command line compatibility -------------------------- Luckily, there is only one (seldom used) option that conflicts: -I. Moreover, it has a long format name in windres as well, which can be used instead. In other words, it should be very simple to add support for the windres options to wrc (most of them will just get ignored). In other words we can support windres's options while keeping full backwords compatibility. Having this compatibility makes sense as long as we support the conversion to .o files as well. Assuming we can do that, I would say this is something we should have. Conversion to .o files ---------------------- As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html generating .o files in proper format is non-trivial. And since I'm willing to do the work, there's no chance I'm going to propose something difficult to implement! :) What I have in mind is quite simple: store the .res file, as a byte array, in a .wine.resources ELF section, and have winebuild pick it up from there (as an alternative to getting it directly from the .res file, so current behavior is conserved). With these two changes, we eliminate the biggest nastiness of getting apps compiled with Winelib. The modification will typically be: -WINDRES=windres +WINDRES=wrc Moreover, the solution is: o Simple to implement o Fully backwards compatible with current Wine practice o Fully compatible with Win32 apps using the MinGW toolchain o Supports multiple resource files, etc. So now the big question: Alexandre, are patches that implement these ideas acceptable? Sorry for the long message, and thanks for reading this far. -- Dimi.

3 6

Re: [RFC] wrc & windres
by Jeff Smith 05 Dec '02

05 Dec '02

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> >Hi folks, > >As we discussed here a few weeks ago, there is good reason >to have a windres compatible mode for wrc. <snip> >That being said, what would it take to (1) keep the current wrc >behavior, and (2) make it compatible with windres? Here is an alternative idea for dealing with command-line incompatibility: create a link 'windres' pointing to 'wrc'. In the program, we could determine how the program was invoked and handle the command-line options accordingly. This should technically work, unless we find some reason to 'mix' command line options, in which case we we would have to start 'blending' the two syntaxes. Please note that I am not familiar with the command line options of either program. <snip> >The modification will typically be: >-WINDRES=windres >+WINDRES=wrc WINDRES would not have to be changed using this method. -- Jeff S. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

Re: possible memory corruption
by steve.lustbader＠philips.com 05 Dec '02

05 Dec '02

>>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: > > steve> When I try to load a window in my app that has a treeview in it, > steve> it crashes immediately, before the window even gets displayed. > steve> This is the end of the backtrace: > > Try running with native commctrl to see if the corruption comes from our > commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will > check on every heap manipulation to see if the heap is still okay. Then >look what corrupted the heap. It works fine with a native (WinXP) comctl32.dll. I'll post the +relay,+heap output shortly. -Steve

1 0

possible memory corruption
by steve.lustbader＠philips.com 05 Dec '02

05 Dec '02

When I try to load a window in my app that has a treeview in it, it crashes immediately, before the window even gets displayed. This is the end of the backtrace: 0x400d6377 (HEAP_FindFreeBlock+0x3b [heap.c:608] in libntdll.dll.so): movl 0x0(%edx),%eax 608 DWORD arena_size = (pArena->size & ARENA_SIZE_MASK) + Wine-dbg>bt Backtrace: =>0 0x400d6377 (HEAP_FindFreeBlock+0x3b(heap=0x41230000, size=0x108, ppSubHeap=0x406e1af4) [heap.c:608] in libntdll.dll.so) (ebp=406e1adc) 1 0x400d6df5 (RtlAllocateHeap+0x71(heap=0x41230000, flags=0xa, size=0x104) [heap.c:1028] in libntdll.dll.so) (ebp=406e1b04) 2 0x40b283e2 (COMCTL32_Alloc+0x4a(dwSize=0x104) [comctl32undoc.c:352] in comctl32.dll.so) (ebp=406e1b24) 3 0x40b732bb (TREEVIEW_UpdateDispInfo+0x227(infoPtr=0x41230838, wineItem=0x41232060, mask=0x1) [treeview.c:762] in comctl32.dll.so) (ebp=406e1ba4) 4 0x40b73d94 (TREEVIEW_InsertItemA+0x324(infoPtr=0x41230838, lParam=0x406e1be8) [treeview.c:1318] in comctl32.dll.so) (ebp=406e1bd8) 5 0x40b73eb6 (TREEVIEW_InsertItemW+0xb2(infoPtr=0x41230838, lParam=0x406e1f08) [treeview.c:1389] in comctl32.dll.so) (ebp=406e1c34) 6 0x40b79881 (TREEVIEW_WindowProc+0x6a5(hwnd=0x2006a, uMsg=0x1132, wParam=0x0, lParam=0x406e1f08) [treeview.c:5237] in comctl32.dll.so) (ebp=406e1c50) 7 0x408ec923 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406e1c74) 8 0x408ec9ae (WINPROC_CallWndProc+0x82(proc=0x40b791dc, hwnd=0x2006a, msg=0x1132, wParam=0x0, lParam=0x406e1f08) [winproc.c:183] in user32.dll.so) (ebp=406e1ca4) I had thought originally that it might be a treeview problem, since the crash happens based on calls from treeview, but Dimi says that it's probably memory getting corrupted somewhere. What trace would be helpful to debug this? Thanks, Steve, PS - I had previously posted a +treeview trace a couple of weeks ago. Here it is again, just in case it's helpful: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger...

2 1

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