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:
I have found the crashing line. Of course the App does not work when the line is commented.
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]
@@:
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 ...
Hi caraveiro,
I've downloaded the 32-bit exe from http://www.ronybc.com/fire.php (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
Hi rrr314159,
Quote from: rrr314159 on August 02, 2015, 09:20:43 AM
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.
Quote from: Gunther...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
Got it run (win7-x64) after fixing the stack usage:
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
sub ebp,12 ; as 3 local variables
with
sub esp,12
mov ebp,esp
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.
Quote from: rrr314159 on August 03, 2015, 02:06:45 AMBut why does it need modifying under 64-bit OS, it's supposed to be compatible?
bad programming style ⇒ buggy code
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
Quote from: rrr314159 on August 03, 2015, 02:50:13 AMbut 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]).
Quote from: qWord on August 03, 2015, 03:16:29 AM...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.
Quoteunder 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.
Quote from: jj2007 on August 03, 2015, 03:49:22 AMDo 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+.
Quote from: qWordThe 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
Quote from: jj2007For 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
Quote from: qWordAn 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 ...
Quote from: qWord on August 03, 2015, 04:11:56 AMthe 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. (https://msdn.microsoft.com/en-us/library/windows/desktop/ms633573%28v=vs.85%29.aspx)
I am with qword here, every time Microsoft produce a new OS version they tend to re-write many functions according to documented specifications and if they get it right which is not always the case, exceptions that worked on an older OS will go BANG on a later one. Comply with the published Intel ABI or live dangerously. There is no spec to preserve MMX and XMM registers so if you assume any of them, you risk it going BANG on a later version.
It seems that my Full-HD screen is Bigger than 1024w*1024h*4colors:
align 4
FireThread proc uses esi edi ebx
LOCAL dScreenW:DWORD
LOCAL dScreenH:DWORD
LOCAL dScreenBits:DWORD
;
;
Invoke GetDC,hWinMain ;hwnd ;wnd ;hWinTarget
mov wnddc,eax
invoke GetProcessHeap
mov hHeap,eax
Invoke GetSystemMetrics,SM_CXSCREEN
mov dScreenW,eax
Invoke GetSystemMetrics,SM_CYSCREEN
mov dScreenH,eax
xor edx,edx
mov ecx,dScreenW
mul ecx
shl eax,4
mov dScreenBits,eax
invoke HeapAlloc,hHeap,HEAP_ZERO_MEMORY OR HEAP_GENERATE_EXCEPTIONS,dScreenBits ;2048*2048*8 ;1024*1024*4=4194304
;add eax,4096*4 ;4096 ; blur: -1'th line problem
mov ecx,dScreenW
shl ecx,4
add eax,ecx
mov bitmap1,eax
invoke HeapAlloc,hHeap,HEAP_ZERO_MEMORY OR HEAP_GENERATE_EXCEPTIONS,dScreenBits ;2048*2048*8 ;4194304
;add eax,4096*4;4096 ; blur: -1'th line problem
mov ecx,dScreenW
shl ecx,4
add eax,ecx
mov bitmap2,eax