Hi
I have a problem with my VC6 MFC MDI app. Every child window that is
docked inside isn't painted anymore and doesn't receive any messages.
Together with a friend (THX ic) I found out that the wrapper window that
does the docking doesn't have the visible flag set. Even if I create the
window with the flag set it gets deleted somewhere in CreateWindowEx
or ShowWindow. In Windows the flag can even get set even if it wasn't
set before but I just couldn't find out why.
I scrutinized the MoveWindow call. It sends the messages
WM_WINDOWPOSCHANGING, WM_NCCALCSIZE,
WM_WINDOWPOSCHANGED, WM_MOVE and WM_SIZE (in this
order) to the window. After these there is an additional
WM_SHOWWINDOW. In every handler the visible flag isn't changed yet.
After leaving the MoveWindow call the flag can be set or deleted. So
this must happen between WM_SHOWWINDOW and the end of
MoveWindow. But I couldn't find out what reason Windows uses to
change it so I can't say where in wine the error is.
I'd be very thankful if somebody with knowledge about windows and
their style flags could shed some light upon this.
Here is a small sample app (only exe, source is quite complicated,
but I can deliver that too if anybody is interested). There is a toolbar
docked below the menu but in wine there is just a dead area.
http://www.indel.ch/ftp/TestIMD.zip
BTW winedbg doesn't show the class information for walk wnd. The
same problem has MS-Spy++ but besides that it runs quite well in wine :)
Thanks for any hint/help/patch...
bye Fabi
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
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
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 ----------
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
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.
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
