wine-devel

wine-devel@winehq.org

7 participants
84405 discussions

AVI resources in shell32.dll
by Stefan Leichter 03 Oct '02

03 Oct '02

Hello, i have an installer that fails because of a missing AVI resource (the magnifier in front of the computer) in the buildin shell32.dll. To get the installer running i tried to build the resource. i used Paintshop Pro 6 to create the single pictures of the AVI and built the AVI with the animation builder of Paintshop Pro. The created AVI work (at least in the Media Player), but my new AVI is 53k big instead of the 7k of the native shell32.dll. Reducing the color deep of the single picturs does not have any effect to the size of the AVI. What do i need to change to get the resource as small as the native on? Are other tools needed to build the resource? Using compression ? Is there a tool to analyse the native resource in deep ? Any ideas? Thanks Stefan

3 4

Re: Need help interpreting debug log for Wine hard loop
by Miguel Feitosa 03 Oct '02

03 Oct '02

On Thu, 2002-10-03 at 18:35, Sean Millichamp wrote: > On Thu, 2002-10-03 at 17:03, Miguel Feitosa wrote: > > I forgot to ask. > > What are the DLLs that your app links? > > It seems that your code is failing before mine. > > Mine actually got to start drawing a window...and yours hasnt. > > I was able to track done my erros to Borlands BWCC or something > > like that .DLL > > Well... I'm not sure how to see what DLL the app links but I suspect it > does need BWCC. I looked and it was installed in C:\Windows\System on > my fake_windows area. I use +file and +dll [I think] I've never done +loaddll Do a simple grep in the wine src and you can see the channels that exist. > > When I do a --debugmsg +loaddll I don't see any mention of bwcc.dll or > any non-builtin DLL. Is there a way I can force-load bwcc? Is there > some reason Wine wouldn't be loading it automatically? No, wine loades DLLs very well. I have never had any problems with that. > > Here are the DLLs that it's installer installed in Windows\System: > bwcc.dll dewcc.dll dewsc.dll dewtc.dll winsys.dll The only one I know is bwcc.dll > > I presume it needs all of them at some point but I see none of them in > use with loaddll before the loop. Do I need to configure this special > in .wine/config? I thought that it was supposed to know to auto-load > them but.... No need to put them in config, they will be loaded, your app is failing before bwcc get's loaded... > > I'm sorry if these are simple questions. I really appreciate you taking > the time to try to help me. If I don't get this working I will have to > install Windows where the application is needed (currently it's all > Linux) and I want to avoid that if possible. No problem, I had to sort through all this too a couple months ago. At the time I was trying to do this, I seach alot and didnt find a whole lot about wine + Borland C... I finally gave it up... I believe that expert wine programmers with the relay can pinpoint the issue that is bugging your app...8-) > > Thanks, > Sean > > See ya! Miguel

1 0

miscemu/wine gets into the way in map_image
by Uwe Bonnes 03 Oct '02

03 Oct '02

Hallo, the full installer for XILINX Webpack 5.1 is a 160 MByte executable. It doesn't start with wine: > ~/tmp/wine/compile/wine/wine WebPACK_51_fcfull_i.exe err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? Clearly my kernel isn't "security-patched". Printing out /proc/maps/self in this situation shows: 08048000-0805c000 r-xp 00000000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine 0805c000-0805d000 rw-p 00013000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine An strace on wine shows the mmap call in map_image: 23236 mmap2(0x400000, 161087488, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404c2000 Adding 0x400000 and 161087488 gives someting in the 0x09d0000 range. This overlaps with the wine executable itself and mmap2 can't satisfiy the request in place. Any ideas what to do about that? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 5

What do you guys make of this?
by Greg Turner 03 Oct '02

03 Oct '02

I'm trying to run StarTeam Client, which used to work as recently as earlier this month. Nowadays, I get infinite recursion in the exception handlers, caused by various NULL pointer deferences within dlls/msvcrt/cppexcept.c. Any ideas? Looks like stack corruption to me... Here's some +seh output: trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f17f0 trace:seh:EXC_RtlRaiseException info[2]=41108f80 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1750 frame 0x406f186c trylevel 0 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108f68 0: flags 1 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:call_catch_block matched type 0x41108f48 in tryblock 1 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x41108c98 for type 0x41108f48 addr 0x410fbb36 ebp 0x406f1878 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f0e6c trace:seh:EXC_RtlRaiseException info[2]=41108df8 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f186c trylevel 1 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f19ac trylevel 1 descr 0x410d43f8 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410d4418 7 0: prev -1 func (nil) 1: prev 0 func (nil) 2: prev 1 func 0x410ceabd 3: prev 2 func 0x410ceac6 4: prev 3 func 0x410ceacf 5: prev 0 func (nil) 6: prev -1 func (nil) try table: 0x410d4450 2 0: start 1 end 4 catchlevel 5 catch 0x410d4478 2 0: flags 0 offset -80 handler 0x410abe43 type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abe6d type (nil) 1: start 0 end 5 catchlevel 6 catch 0x410d4498 2 0: flags 0 offset -84 handler 0x410abe9c type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abeb9 type (nil) trace:seh:call_catch_block matched type 0x41108d80 in tryblock 0 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x410d4478 for type 0x41108d80 addr 0x410abe43 ebp 0x406f19b8 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException info[2]=00000000 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e9a3 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000008 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405e09d8 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405dfe98 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 . . . and so on, forever. The experience in a debugger is that the exception type becomes NULL and is passed around like that until it gets deferenced. Then all hell breaks loose. I don't understand where __wine_call_from_32_regs lives in the source, and lose track of what's going on in there, thwarting my debugging efforts. -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 3

spec files and handles
by steve.lustbader＠philips.com 03 Oct '02

03 Oct '02

With functions that take HANDLEs as arguments, what should that argument be listed as in the spec file? I thought HANDLEs were void *'s, so ptr would seem right. I found a function (DebugBreakProcess in kernel32.spec) that takes a HANDLE and has that listed as long in the spec. So which should it be - ptr or long? -Steve

2 1

Re: RPC merge (PL0)
by Ove Kaaven 03 Oct '02

03 Oct '02

On Wed, 2 Oct 2002, Greg Turner wrote: > OK, here's a first chunk of Jürgen Schmied's RPC patches. > > This is roughly equivalent to the stuff I posted recently, just > not my code anymore (which is a good thing 'cause my code > had some bugs). Some very minor changes may exist between this > and the original patch but it's intended to be basically > the same stuff. > > LICENSE: > "OK to put it into Wine" Is it OK for you if it gets into ReWind too? Then just say X11, otherwise say LGPL. > just a thought: > are statics guaranteed to be zero'ed out, as this code > seems to assume? Yes, uninitialized static and global variables are allocated in the .bss section, which is always explicitly zeroed on load. You could make it an initialized variable if you don't feel comfortable with it, though (something like static UUID uuid_nil = {0};), which will allocate it in the .data section instead, so the initial value will be embedded in the compiled binaries.

1 0

Re: Patch - Makefile.in shell32
by Alexandre Julliard 02 Oct '02

02 Oct '02

Steven Edwards <Steven_Ed4153(a)yahoo.com> writes: > Changelog: Dont include win16 shell support when building without > win16. (Untested under *NIX) It doesn't link with --disable-win16: iconcache.o: In function `ExtractAssociatedIconA': /home/julliard/wine/wine/dlls/shell32/iconcache.c:465: undefined reference to `ExtractAssociatedIcon16' shell32_main.o: In function `ExtractIconA': /home/julliard/wine/wine/dlls/shell32/shell32_main.c:526: undefined reference to `InternalExtractIcon16' -- Alexandre Julliard julliard(a)winehq.com

1 0

cursor:create_cursor ?
by Nick 02 Oct '02

02 Oct '02

Hi, fixme:cursor:create_cursor Currently no support for cursors with 10 bits per pixel and similar messages are (seemingly) the only things preventing Heroes of Might and Magic 2 from being fully playable. Is this function really uncommonly used or something? It looks so basic... Just wondering, Nick

2 1

RE: winaspi+libscg
by Patrik Stridvall 02 Oct '02

02 Oct '02

> Szombathelyi György <gyurco(a)freemail.hu> writes: > > > And how about a configure option to enable it? Default > option would be only > > the platform specific code, but a user can enable libscg > with a compile time > > option, and will receive a warning message about the license. Is it > > acceptable? If it is, I will make a patch. > > I don't think that would necessarily solve the issue. Some would argue > that the source itself is a derivative work that has to be under the > GPL. But the SOURCE is already under the LGPL which is compatible with the GPL so it doesn't matter if some part (whatever part) of the source might be required to be under the GPL. BINARIES might be required to be GPL:ed if and ONLY IF you enable the option. So it not really a problem for Wine AFAICS. > I don't want to debate the merits of that legal theory, Yes, we have debated this before. I know what you are going to answer, and you probably know what I'm going to say in return, so let us save the time and don't bother. :-) > but I > think it's better to avoid the issue completely. SIGH. As you wish.

1 0

Re: winaspi+libscg
by Alexandre Julliard 02 Oct '02

02 Oct '02

Szombathelyi György <gyurco(a)freemail.hu> writes: > Here's my winaspi patches that uses libscg for the scsi transport layer. It > statically links libscg, which is the part of the cdrtools package (all > distribution have it). As far as I can tell libscg is under the GPL, not the LGPL. So we cannot use it in Wine. -- Alexandre Julliard julliard(a)winehq.com

2 2

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