Almost 99% of asm apps I saw is buggy. Including asm shells and demos on Icz site You'll never get glory for your apps until they are save. Savety is and always be first priority. I can recomend 3 basic things. 1. Always preserve regs in your callback procs 2. Learn SEH 3. Install NT at least as second OS and test your progs there - that way you'll get additional outer control from OS, wich can save your from buggy places in your progs wich is usually access violation - i.e. going out of memory boundies. The Svin.
I ceratinly wouldn't say all, but there are many ASM tuts that don't work on Win2K or NT. There are authors which work in NT and so does their examples :P Maybe, you just need to shop around a bit. Maybe, you could help all these coders out by providing documentation of their faults (pun intended), and a framework for easily implementing SEH in their code. Take care, bitRAKE.
2. Learn SEH what is SEH???
Hi mega, I struggled with SEH as well, but I think I found out, what it means. It is structured error handling, meaning that you respond to anny errors that occured in your proggie like creation fails, wrong return values and such things that help you make the proggie more stable by not just let the faults pass by. I hope I am right with this, if not then please correct me! Hey Svin, maybe you could take a look at my sources (link is above) and give me some hints on how to improve them? I am willing to learn if someone shows me how to do it better. Stefan
I agree with Svin on the general complaint that most apps, asm or not are buggy somewhere. A lot of it has to do with the way Microsoft have continued to change the rules for what is a documented function and what is not. Operating system complexity and lack of documentation on the variations across different versions of Windows is the cause of a lot of unreliable code, even though it can be well written and well debugged on one version. For a long time, NT4 lagged behind win95 in available functions and effectively win95 became the standard. Problem was that Microsoft did not remain consistent across different versions of Windows. I am not all that happy about debugging Microsoft operating systems for them as I pay for what I use so I stick to the win9x range of functions as most people use win9x, not NT/2k. I am of two minds with structured exception handling, I see its uses but it is no substitute for writing error free code, put in error handling and you get sloppy code for it. Write the tests to ensure the error does not occur and you don't have a problem. Register preservation is subject to a rule in 32 bit windows, preserve EBX, ESI & EDI if they are going to be used in a procedure, there is no point in preserving them if they are not used nor is there any point in preserving the rest except to add to the stack overhead for the procedure. A callback is no exception. Page read & write faults come from either reading or writing to memory that the app does not own, SEH may catch them but its bad coding practice to write code that may GP fault. Better to write code that stays within the legal address range so you don't get the problem. Regards, firstname.lastname@example.org
So is that the only registers that need to be saved in win2000, ebx,esi and edi. After reading this topic, i went through a lot of my source code, and just put some pusha, and popa but they are expensive, and i would prefer to only do the minimum (Pusha and Popa are only temporary, just so that some all of my progs can now be used)
Mega, If you are developing a procedure and you are changing things around fast, you can use PUSHAD and POPAD, they are the right ones for 32 bit registers but you are doing too much work with them in a normal finished proc, it will work but it makes your procedure slower. Rule is you can freely use EAX, ECX and EDX but if you are going to use EBX, ESI or EDI, you MUST preserve them first and restore them at the end of the proc before RET. WIN2K is supposed to be compatible with NT and WIN9x but I would not garrantee it, it was written by Microsoft. :) Regards, email@example.com
To Hutch: 1. About NT and 9x - You may have your opinion as customer that you don't need to debbug OS since you pay for it, but as asm programmer you might find helpful to know OS you are writing for and asm programmer has advantage to get better picture using debugger 'cause a debugger is something that any real asm programmer gets used to. - Yes there is difference in implementation of Win32 API between NT and 9x (for ex. edit controls in NT and 9x are almost two different things), but I didn't mean it as reason when suggested to use NT as "bug finder" at least as second OS. The reason in that NT better catches memory access violation. And there are lots cases when your prog actually violate memory ranges in 9x but 9x not rises GPF, so you can miss it in tests and will not be able to correct it before too late. You see, memory violation is not nasseserily crashes OS and with some tests it might look fine so you can not note it. But the REASON why memory viaolations occurred (bug in prog) in a differernt case may lead to system crash when some sencetive regions of memory accessed. And it would be very difficult to spot this bug in proc 'cause in some conditions it will work fine and during the test you mark it for yourself as "safe pieces of code". NT in opposite always generate GPF when memory violation occured, so you can write your programm for what OS you want but testing it in NT will give you a better picture if some parts of your code violate memory range. So I meant not write for NT but use it as "bugs finder". 2.Regesters preservation and CALLBACK procs. You are deadly wrong here :) All win32asm programmers knows about the rule :PRESERVE EBX EDI ESI in your procs! But it seems to me not all of them quite understand why such a rule exist :) And while rules made by our officials may be stupide and yet we must follow them 'cause the officials have a power, rules made for a computer OS always has math and logic explonations and can be understood. In the case explonations are seen through understanding of stdcall stack frames formation and nature of callback procedures. This rule exist exactly because of calling callback procs by OS! And returning control after callback proc is done to OS! And the code in the OS section aspect the same edi esi ebx as it was before in call the callback proc. So the problem start not in your code, and not immideatly after callback return but when sploided esi edi ebx will lead OS to wrong places. I may write as a prove any long example wich will rapidly change ebx edi esi without preservation,call many Win32 APIs and it still doesn't crash anything in OS. But in this example will not be any callback procs and it will not call any procs which you callback procs. Retern address of your code in any Wnd and Dlg procs will have adress of your code space only in DlgProc while INIT handler is not done, in all other sections if you set brakes in debugger and look at what you have in stack frame as the return adress - you'll be surprise - there is not your address. And the code at the address will expect that edi esi and ebx will be the same when your function returns. Of course you need also preserve edi esi ebx in your stdlib procs. But reason is the same - this library procs may be used in the callback procs. The other reason is wellknown - if all the procs preserve edi esi ebx it gives additional help to use edi esi ebx values between calls to other procs. The Svin.
I downloaded your progs (some are interesting) found some buggs and the causes. Do you want me to optimize them as well? The Svin.
I don't like using EBP for a stack frame, so I need to preserve it as well. Since ESP is preserved I always know where the local and passed parameters are. bitRAKE
To S.Krause: As I said I'd downloaded your demos and looked at first in scan.asm Your callback proc WndProc doesn't preserve edi esi ebx registers. The code in the proc itself doesn't change the registers but it calls to other your proc "Scan" which actually changes edi esi during string operation and the Scan proc doesn't preserve the register. This leads that upon return to WndProc from Scan proc the registers spoiled and in this state the OS code gets them after return from your callback WndProc. It, in its turn, ends to GPF in NT shortly and might ends to BIG PROBLEMS in 9x since this OS are not able always catch in time changes and just hungs when it's too late. The Svin.
Ok now download my game also.. its a very stable game :) ..no leaks..no GPF...but hey... dont run it on NT 4.0.. :) yet...i belive i used some DirectX 6 code somewhere :) Win98 ME and 2000 are todays target systems :)... but i will try to make it work on NT 4.0 also...but without DirectX...what can i do? a GDI game? But in the long run you are true...much too offten errors escape not GPF'ed by those "modern OS's"... and then again they GPF on a lots of other things...like copy or erase very huge files local or network :) bottom line i think ASM proggy are just as safe as every progs on the market...IMHO a little more safe then C/C++ ones(my RTS GAME is an example for that)...and we can allways correct the...but you can NOT correct bugs in the C/C++ compiler...you just have to live with them :D The proggy you tested are just tutorials/demos/etc ie unfinished programms (like my DirectPlay demo :( ) made just to make you think and learn....finished ASM programms are a lot safer then the average program :) This message was edited by BogdanOntanu, on 2/25/2001 6:09:13 PM
Hey The Svin, first of all, thank you for downloading my programs. Have you already took part in the poll on my site? :rolleyes: If this is not too much of a problem for you, is it possible that you pick one that is very buggy, correct the bugs and show some improvements and send the source back to me so that I can compare the old one to the new one. That would be of great help. Stefan
Hi Hutch, you say 'you must preserve ebx, esi, and esi and restore them before ret' I hope this doesn't sound too dumb, but when do I preserve these registers? The restore part is clear, but for restore should I push ebx, etc before calling proc or push when in proc? best regards, czDrillard
czDrillard Just use a "use ebx,esi,edi" statement in the PROC line... then MASM will save/restore the registers for you... in the Prologue / Epilogue part of the PROCedure...look in the listing to see what MASM does :D but if you like the OLD Style (i sometimes do :) ) you can just pushad at the beginning of the procedure and then popad at the end...its the same thing...maybe slower...a little
Bogdan I wrote very big msg to you after haveing logged in. But when I press "submit" button my name dissapiered and server asked me to fill my name again :) So msg to your has gone forever into virtual enthropy :) NT 5 (aka Win2000) may work even with DX 8 (I have DDK for NT5) And It's too much for me to dissassmble several mgbs without sources just for fun. And I wish you good luck with your project and very proud of you. To S.Krause I will analyze your progs here not by e-mail. The reason was well discribed in the lost letter too :) Code, man! You'll get it - I'm sure! You can write real thing in a while. I wouldn't say it just to anybody. The Svin.
czDrillard, It done at the beginning of the executable code in a proc and at the end of the proc before RET.
Note that they are pushed and popped in reverse order as the stack is a last on, first off system. Regards, firstname.lastname@example.org
name proc parameters etc ... push ebx push esi push edi ; write code that uses these 3 registers pop edi pop esi pop ebx ret name endp
Hi The Svin, I don't care if you analyse it via E-mail and send it to me privately or on this board for the public. I just thought that it would be too much to be done on this board. Stefan
The Svim: Yeah that happened to me also...and others if i read well...looks like messageboard forgets your "log in" if you are inactive a long time....includeing if you write a long message write the reply in Notepad...and paste it in after...so you have it for a repost ... :) or write fast shorl replies no other solution for now...lets wait and see what Hiro has to say about it.. As for dissasembly...dont do it :P...just find some fatal bugs inside and send them to me...(little beta testing :) ) i will be forever gratefull :) This message was edited by BogdanOntanu, on 2/26/2001 10:27:30 PM
The Svin, How about publishing a little tutorial one day about correct/save code writing and/or optimizations? I'm sure a lot of folks can benefit from it. :rolleyes: