Old fireworks does not works on x64

[caraveiro]

I run this Little jewel just to found that it crash in my x64.

I dunno where is the failing code; I'll post here if I got it!

:icon_rolleyes:

[caraveiro]

I have found the crashing line. Of course the App does not work when the line is commented.

Code Select Expand


Blur_MMX2                       proc uses esi edi ebx               ; 24bit color version
    ;emms    ;
    mov edi,bitmap2            ; (Developed under an old SiS6326 graphic card
    mov esi,bitmap1            ;  which prefers 24bit for faster operation)
    mov bitmap1,edi            ;  Note: SiS315 is excellent, good rendering quality
    mov bitmap2,esi
    pxor MM7,MM7
    mov eax,fadelvl
    imul eax,00010001h
    mov [ebp-4],eax
    mov [ebp-8],eax
    movq MM6,[ebp-8]
    mov eax,maxx
    lea eax,[eax+eax*2]
    mov ecx,eax
    imul maxy
    push eax                   ; maxy*maxx*3
    lea edx,[ecx-3]
    lea ebx,[ecx+3]
    ;neg edx                    ;if uncommented crash on W7x64
    xor eax,eax
    lea esi,[esi-3]
@@:


[rrr314159]

Hi caraveiro,

I'd like to see the prog work sounds interesting, but at the moment don't know what's wrong. If you comment out "neg edx" it just fails somewhere else; always a bad mem reference.

This code is purely 32-bit, although the problem occurs when you run it under a 64-bit OS. Question: does it work on 32-bit OS? I wouldn't expect it to.

Anyway since it's 32-bit code NOT 64-bit it doesn't really belong in this forum caraveiro, but in a regular forum, the Campus for instance. Only reason it matters, fewer people will notice it here, and the ones who do check this forum (like myself) will presumably be less interested, since they're into 64-bit code

If I find anything I'll let u know, don't hold your breath ...

[Gunther]

Hi caraveiro,

I've downloaded the 32-bit exe from http://www.ronybc.com/fire.php and that works fine under Virtual PC (Host: Win64, Guest: XP, SP3). That's very strange. You should send an error report to the original author.

Gunther

[FORTRANS]

Hi rrr314159,

This code is purely 32-bit, although the problem occurs when you run it under a 64-bit OS. Question: does it work on 32-bit OS? I wouldn't expect it to.

   Seems to work well on my P-III with Windows 2000.  Nice
display.  Odd program options.

Cheers,

Steve N.

[rrr314159]

...the 32-bit exe from http://www.ronybc.com.../fire.php

- on my Windows 8 64-bit systems the download crashes the same way, appears to be same as caraveiro's posting. Strange that it works on 32-bit and Virtual PC. caraveiro, are u using Windows 8? Could be that's the problem, not 64-bit

[qWord]

Got it run (win7-x64) after fixing the stack usage:

Code Select Expand

Blur_MMX2 PROC                 ; 24bit color version
LOCAL var1:QWORD ; <--
    mov edi,bitmap2            ; (Developed under an old SiS6326 graphic card
    mov esi,bitmap1            ;  which prefers 24bit for faster operation)
    mov bitmap1,edi            ;  Note: SiS315 is excellent, good rendering quality
    mov bitmap2,esi
    pxor MM7,MM7
    mov eax,fadelvl
    imul eax,00010001h
    mov DWORD ptr var1[0],eax  ; <--
    mov DWORD ptr var1[4],eax  ; <--
    movq MM6,var1   ; <--
...

and in FireThread:
replace line

Code Select Expand

    sub ebp,12                 ; as 3 local variables
with

Code Select Expand

sub esp,12
mov ebp,esp


[rrr314159]

Congratulations qWord that gets it running  :t

However it still crashes easily, for instance going to fullscreen. But now that it works (at first), it's easy enough to fix such details. But why does it need modifying under 64-bit OS, it's supposed to be compatible?

Have run into analogous problem with my own code rarely, going the opposite way: 32-bit code developed on 64-bit OS but doesn't work on 32-bit OS (runs a second or two, exits quietly, no window). Like something's wrong in WM_CREATE handler, but evidently that's not it. I tend to blame it on Win 8, but could be 64 vs 32 OS. If it would crash it would be more debuggable but that doesn't happen. Learned to just ignore the problem, continue developing the code, and more-or-less always the next version works again on XP 32-bit OS! Can also be fixed by re-compiling (the exact same code, same includes and libs) on the target machine. Obviously this is not a great approach, would like to know what the underlying problem is.

[qWord]

But why does it need modifying under 64-bit OS, it's supposed to be compatible?

bad programming style ⇒ buggy code

[rrr314159]

No doubt you're right qWord ... but. Bad style => buggy code, yes, but why is it a bug under only one OS not the other, when they should be compatible? And why (in my case) does simply re-compiling on the target fix the problem? What's that got to do with style?

I'm considering these as rhetorical questions, don't particularly expect an answer (only Bill knows). Someday I'll post an example: 32-bit code, the .exe works on one OS not the other; I can find examples both ways - works on 64 not 32, and vice versa; on my machines, at least. Can't find anything on the net - people have similar probs with DLL's but not normal code. Does anybody know where it's discussed? (jj2007 alert)

BTW it's not a pressing problem, only happens rarely, easily fixed; mainly just curiosity

[qWord]

but why is it a bug under only one OS not the other, when they should be compatible? And why (in my case) does simply re-compiling on the target fix the problem? What's that got to do with style?

A typical reason is to make assumptions rather than relying on documented behavior (e.g. about register usage). The point is that the code is wrong for all OS versions, but for some reason it does run perfectly on a particular version (for example later windows versions preserve nonvolatile registers for the WndProc and under x64 there is also an all-eating-exception handler around it).
An other problem could be different code generation of assemblers (e.g. invoke-directive and byte/word sized parameters [IIRC the reason why RadASM can't be assembled using later MASM versions]).

[jj2007]

...assumptions rather than relying on documented behavior (e.g. about register usage).

For example, many people don't know that xmm regs are preserved in 32-bit code on Win-32 but not in 32-bit code (!) on Win-64. A nasty trap if you develop code on Win-32.

under x64 there is also an all-eating-exception handler around it

I noticed that, after chasing down some "mysterious" bugs with Olly. Do you have any links to documentation? It seems also they abandoned this "feature" in Windows 8.1, at least in my experience.

[qWord]

Do you have any links to documentation? It seems also they abandoned this "feature" in Windows 8.1, at least in my experience.

Originally there was an KB entry, but I've recognize that the MSDN entry of the WindowProc now contains a explanation. However, according to the relevance of WinAPI programming, this document is outdated and does not mention windows 8+.

[rrr314159]

The point is that the code is wrong for all OS versions, but for some reason it does run perfectly on a particular version

- yes that makes sense

For example, many people don't know that xmm regs are preserved in 32-bit code on Win-32 but not in 32-bit code (!) on Win-64

- "Many people" including myself ... fortunately I started with Win-64 so always preserve XMM registers anyway (as required). There must be quite a few of these "gotcha's". One way is to read a lot of MSDN, easier (for hobbyist anyway) is to test on each platform and fix whatever needs fixing

An other problem could be different code generation of assemblers

- in my case the same assembler, same linker, same code, includes, libs, rsrc, cvtres.exe - everything. Works when compiled on the XP platform, not when compiled on Win 8 and (try to) run on XP. I should post the example ...

[jj2007]

the MSDN entry of the WindowProc now contains a explanation. However, according to the relevance of WinAPI programming, this document is outdated and does not mention windows 8+.

There it is, a great demonstration why one should avoid buying Microsoft shares.