Asm32 Rebirth History ...
The Assembly Rebirth began at a time I was completely out of any programming activity. When I went back to programming, in 1998, the Assembly Rebirth had already begun, and was in progress for a couple of years, with the work of several pioneers. As I did not take care to record the Dates and Names in timely fashion, and as more and more older Pages are becoming unavailable on the Net, as many older works, sometimes, do not have any Date and/or were even anonymously released, the following list is incomplete and poorly organized, I have been able to draw as of June of 2003... If you have some historically significant date and name references, please, let me know.
Though it is sometimes difficult to say in what group some given personality stands, the Rebirth may be described in several waves:
- The very first 'Pioneers' who wrote the very first Demos and Tutorials, most often at the level of the 'Hello Win' example. Many of them were TASM users and do not seem to be yet active as of July 2003. Most of these older Pages have long since vanished... (I.E. Masta, Lord Lucifer, Titi, ... etc.).
- The 'Clearing up guys', who established most of the basic principles of Win32 Assembly (Wayne J. RadBurn, Sven B. Schreiber, Jeremy Gordon, G.Adam Stanislav, ...).
- The 'Gardeners', who wrote most of the Tutorials and Demos we are using nowadays (Iczelion, Ron Thomas, Test Department, ...)
Some of these named Programmers cross all these 'categories', as they were there in the first days, and are, more or less, still active today, in 2003.
* Masta: 3 small Tutorials. TASM. (Date???)
* Lord Lucifer's Assembly HomePage (Date???)
* Titi (???...)
* Wayne J. RadBurn: Author of Skeleton v1.2 released the 1995/09/30 (started in June/1995 -MASM-).
* Sven B. Schreiber's 1996/03/19 release of WALK32. - MASM -
* Jeremy Gordon: Structured Exception Handling in Win32asm. 1996-8 Except32 - A386 -
* Steve Gibson: Author of Small Is Beautiful - October 1996 - MASM (http://grc.com/smgassembly.htm). (essentially a simple rephrasing of the other Pioneers works, particularly the ones of Wayne J. RadBurn).
* Whiz Kid Technomagic Homepage of G.Adam Stanislav: crc32.zip -1997- DLLs Demo. and several other Demos. One of them, Rand.exe, was the very first Win32 Application I learned Byte after Byte, atfer several weeks of study, before I began writing the very first Version of SpAsm, in 1998.
* Virogen: 1998, VGCrypt PE Encryptor v0.75 Beta // Virogen's PE Realinger v0.4
* Net Walker: Debugger v0.3. Debug Model, May, 14th - 1998
* Mike Bibby: 26 October 1998, Twin. Asmflip (Dx)
* Cynical Pinnacle: Wrote a 'beepverv' Demo for NT Services. (Date?)
* Win32 Programming by Tomcat. (?)
* Iczelion. From Wayne words: 'a CompuServe PC Programming forum message dated 1998/10/28 which first pointed out Iczelion's web site'. (Hutch says: 1997/98)
* Ron Thomas: Ron's Cornucopia for Assembly Language and Graphics Programming. 'Late 98 - early 99'
* Test Department released his first Demo in February 1999. He says he learned most of the stuff from Icze, _HaK_ and _masta_ and Lord Lucifer, and later 'found Titi's site with a lot of source codes'.
Most of the Dates and comments I provide here are the ones that each of these Programmers may have provided to me, when I asked them. I am not sure of the very first release of Iczelion's Tutorials. He seems less active now, and did not answer my mail asking him questions about this history. This seems to be in 1998.
~~~~~~~
Introduction to the Assembly Rebirth ..
After the oncoming of Windows 3, Assembly had been considered a dead Language by many programmers (including myself). During the years 1995-2000 a couple of pioneers achieved forcing open the closed door. In between time, any request sent to M$, for 'How to program in assembly under Windowz?' regularly got the same answer: 'Impossible! Windows being a C interface, it must be programmed in C...'.
The interest of dominant Companies for killing Assembly is quite evident:
They can't sell anything to assembler programmers.
Particularly not illusions.
Despite the recent rebirth, the disaster is still actual, as we can see each time we read some papers with titles like [Why Assembly] or [Assembly advantages]. Yet now, it is regularly stated that Assembly is interesting because of its capacity at producing Small and Fast Code, ... by HLL programmers making use of Asm Routines...
The sub-line of such claims is always that Assembly is just good for producing inline routines in order to improve the HLLs productions performance quality and to overcome their limitations, but that writing Applications in Assembly would be a strange idea coming from guys unable to use ''the proper tool for the proper thing''.
These ideas are basically unfounded and stupid from every point of view:
If Assembly interest is the speed of produced Code, with the actual Processors performances, the argument is very weak, and the Processors evolutions will go on and on, pushing to stupid and dirty programming methods.
If Assembly interest is at the size of produced Code, the argument is completely ridiculous, given the actual Hard Disks capacities and given the modern OSes Memory Manager's performances.
Another commonly expressed opinion is that Assembly is more difficult, more error prone and more dangerous than HLLs. This is partially true for the real beginner, who has to learn, at once, a lot of things, (like with any programming Language), plus the 20 Mnemonics we regularly use in Assembly Applications programming, plus the Asm Data Managements. With actual Assemblers and actual OSes, the Assembly ''difficulties'' are less and less true. After the first learning steps, not only has this turned false, but one can even see that Asm is often times easier than HLLs.
Generally speaking, actual Assembly Sources tend to be much more readable than, say, the usual 'Write-Only' cryptic C and C++ Sources. Also, because of the fact that Assembly offers a One-to-One correspondence between what you write and the outputted Code, debugging is made a hundred times easier and much faster in Assembly than with any HLL.
The real difference between Assembly and HLL programming is not that at all, that an Assembly written Application would be an optimized version of what an HLL could ever output.
The first point that makes some difference is about Strategy_Optimization. Why can't HLL programmers do real Strategy Optimizations ? Simple: When you do not have the real thing under your eyes, you simply do not know what you are really doing.
The RosAsm Disassembler, for example, is, more or less, 120 times faster than other Disassemblers and 20 to 50 times smaller,... this is not because I am a genius and/or because the other HLL Disassemblers Authors are stupid. This is because, when writing with RosAsm, I can see and I can know what I am really doing, from the bottom-end to the top-end of the logical actual Application building process.
This last point is the important thing. The speed and size gains are nothing but side effects, that will have lesser and lesser interest in the future, and that have a poor direct relationship with the chosen language, but strong relationship with the strategy visibility offered by the language.
One another great point with Assembly, compared to HLLs, is that Assembly has no organization convention. HLLs authors are telling you how to write. We, Assembly programmers, are telling the Assembler what to do. Therefore, we are responsible for our own definition(s), our own organization (s), our own style(s) and choices. This makes some significant difference... Just like the difference between the wolf and dog, freedom and containment, Anarchy and Fascism.
Something even more important than freedom is achieved by this convention lack: HLLs (typically C) force the programmers to always do the things in the same way, a bit like a mentally diseased person who would always answer the same sentence to any question.
In the real programming world , there is no such thing like a universal answer to the various problems we may encounter every day. What is good here may be stupid there. This flexibility, is a key for solving problems in Assembly, depending on the problem and not on the Language, is really nothing but what one usually calls... Intelligence.
The real question -out of market concerns- is now 'Why HLLs?'.
By definition, HLLs can do nothing but applying masks upon Assembly. Masks imply limitations, lesser access to the Asm 'reality', restrictions, illusions of portability, illusions of ease of use, which have always a heavy cost, when one has to force the closed black boxes. The price you don't pay, first, you pay last. Most often... at a much higher price.
Added to this, if we have to learn the basics of Asm, at the end, just to push-up the quality level of HLLs produced Applications, then, why use HLLs at all ?
Once you know Assembly programming. you are -unless you want to control the Processor electric impulsions- in the 'true thing' and you can do anything you want, with no more development time and no more difficulties than with any HLLs.
An important point, that misleads a lot of people, is that the HLLs so called ease-of-use, is usually not a characteristic of the Languages themselves, but is a characteristic of the user interfaces. If you may get a running DataBase in a couple of Clicks with Borland Pascal, this fact has zero relationship with the Pascal Language.
This is nothing but a ''Wizard'' output, and there is no reason that an Assembler could not be also featured with such Interfaces and Wizards. The real fact is that actually, there is no such Visual Components editor implemented in any Assembler, but despite the difficulties, the Assembly Rebirth will necessarily have to go to that point, and it will.
Finally, all actual Assemblers, include good features authoring HLL as writing Styles. These High Level Assembly Styles tend to turn Asm Sources into as easy to read sources as good old time Basic. So, what ? In some way, the remaining difference between HLLs featured with inline assembly, and High-Level-able Assemblers, is that the first ones are 'Top-Down', whereas the second ones are 'Bottom-Up'.
Top-Down is nothing but just a weird idea: Nothing ever worked that way in any natural world.
All programmers who really know Assembly seem to be of this opinion, that Assembly is perfectly well designed for producing full Applications:
Among the last three written Assemblers, two of them (RosAsm, FASM), directly output Applications. Two of them (GoAsm, RosAsm), output only PE Files. So it seems that we all three authors consider that there is absolutely no reason for not using Asm for building full Applications. Needless to say, all three Assemblers are written in Assembly and RosAsm, being auto-compiled, offers a two Megas Octets Source demonstration.
Nevertheless, the Assembly rebirth will remain a long journey, as we will have to slowly rebuild a user base from zero, mainly with real beginners.
Several facts will dramatically slow down this rebirth. The first one is, of course, the existence of a group of HLLs programmers using and defending Microsoft MASM, which, alas, is actually the Main-Stream, and which, alas, will go on misleading beginners for several years, wasting a lot of effort on a dead end road. The second fact comes from us, the Assemblers' authors, as we have been unable to federalize our works. Not only several Projects are running on different roads, but, even worse, despite my repeated efforts, we have never been able to define any generally accepted syntax common base (!!!...). A third and recent event will delay the Assembly Rebirth for several years:
The oncoming of HLA (an HLL Pre-Parser to other Assemblers, that its Author calls 'An Assembler'), and the book publication of associated Tutorials, are going to dry out the tiny flow of Assembly new comers for all the serious Assemblers Projects.
... So that the upcoming situation is actually as follows:
1) Very few Assembly Programmers.
2) 50% of those very few, lost for ever to MASM.
3) The remainder, divided into GoAsm, RosAsm, FASM and NASM, ...
4) Among the new Assemblers, only two (NASM and RosAsm) are GPLed and open to collective developments, while the others are clearly ''Anti-GPL'' (!?!?!?...).
So, most efforts go directly into the dust bin, and, if an Anti-GPL Project would rise to success, in the coming years, all of the work would have to be re-written again (!!!...).
Well, now, let the better win, but... what a waste!
~~~~~~~
Beginners' Steps .
B_U_Asm organization is not linear. Instead, it is organized in a way that makes it quick and easy to recover some information, once you can guess where what you are looking for could be located: A friendly reference method for everyday usage. As opposed to some linear documentations, you will have the impression that RosAsm documentation is... small. Nevertheless, it is more than 600 .rtf Files (2 Mega of organized Documents) with fast and easy access.
So said, here are the Documents a beginner should read first, in order to get started , without feeling lost inside this big Documentation Tree.
(To get back here, make use of the ToolBar horizontal Back Arrow).
IDE: Source_Editor
Asm : Numbers , X86_Basics
Integers_in_Assembly, Strings_in_Assembly
Tables
Registers , Stack , Flags_and_Jcc
Jumping , Addressing , Moving_Data
Logical, Shifting_and_Rolling
Integer_Math , Strings_Instructions
RosAsm: Specifics
Data_Management , Data_Access
Virtual_Data , Len
RosAsm_Numbers , RosAsm_Text
RosAsm_Tables
Mnemonics: Most_used_Op
Note:
First, see the Interactive Visual Tutorials, (James F. Marinic / Betov) that offer an original and friendly access to the basics of RosAsm programming. Once these Files are available in the The RosAsm companion Files Folder, you can access these Tutorials through RosAsm's source editor's Help Menu.
~~~~~~~
Help on Help .
The big green periods after the Titles represent the number of done proof-Readings.
I wrote this little Help viewer to save me from M$ HelpWorkShop gaz factory. This Helper is well designed for text only help. The Files are simple RTFs produced with WordPad, and assembled into an executable PE form by Docker.
As Docker is available at RosAsm pages, with all the desired information about the default viewer Application, the release of this Help, with the complete Source inside, would have no effect but doubling the size of this file for the downloads. So is it uploaded without the Source.
From inside RosAsm, Context Helps are available. They are run by simple command line. See examples of context calls in RosAsm source at:
'ContextHelp'.
To reuse for your own needs, see Docker.
The only limitation is that you cannot use ''double quotes'' inside the Help text because RosAsm text declaration -with CR/LF inside- reserves this sign for data limit settings. Use 'single quotes' instead.
KeyWords analyses are case sensitive and rely on text (not on colors or Pos).
Hitting [F1], from RosAsm, runs B_U_Asm (opening at root).
Hitting any keyboard key makes the help minimized.
So, you may keep the help open at a given page, and get it on / off very quickly by [Key]/[F1] or [TaskBar].
Help is mono-instance and just comes in front if it is minimized or covered when you hit [F1].
When running help from Editors Context help, the Window Style of help is TOPMOST in order to cover modeless Dialogs.
After this running mode is instored, TOPMOST style will remain (the Help Application can't guess when to remove this style). If you want it off, Close it and re-run by [F1].
When Closing RosAsm, if Help has been run from RosAsm, it is closed too.
When running this Help stand alone (from the OS DeskTop), the Auto-Minimizing feature is bypassed.
~~~~~~~
Introduction ..
This RosAsm side file groups and reorganizes the previous versions of SpAsmHelp, OpHelp and Asm32Tut.
The main Maintainer email is: < betov@free.fr >
In the line below, you should see two '_|' with yellow and red Background, as I use them to build Text made pictures in the Tutorials.
__| __|
If you do not see the Background colors (Win95...), you may be in need of the RichEdit DLL available at:
http://betov.free.fr/RichEdit20DLL.zip
For full technical information about x86 Mnemonics, download the Intel Manuals at:
http://developer.intel.com/design/PentiumIII/manuals/
~~~~~~~
XORPS
Usage: XORPS dest,src Modifies flags: None
Performs a bitwise logical Exclusive-OR of the two packed double-precision floating-point values from the 'src' operand and the 'dest' operand, and stores the result in the 'dest' operand.
Bitwise Logical XOR of Single-Precision FP Values
XORPS xmm1,xmm2/m128 ; 0F 57 /r [WILLAMETTE,SSE2]
XORPD returns a bit-wise logical XOR between the source and destination operands, storing the result in the destination operand.
The 'src' operand can be an XMM register or a 128-bit memory location. The 'dest' operand is an XMM register.
EXAMPLE:
xorps xmm1 Label
XORPD
Usage: XORPD dest,src Modifies flags: None
Performs a bitwise logical Exclusive-OR of the two packed double-precision floating-point values from the 'src' operand and the 'dest' operand, and stores the result in the 'dest' operand.
Bitwise Logical XOR of Double-Precision FP Values
XORPD xmm1,xmm2/m128 ; 66 0F 57 /r [WILLAMETTE,SSE2]
XORPD returns a bit-wise logical XOR between the source and destination operands, storing the result in the destination operand.
The 'src' operand can be an XMM register or a 128-bit memory location. The 'dest' operand is an XMM register.
EXAMPLE:
xorpd xmm1 Label
XOR
Usage: XOR dest,src Modifies flags: CF OF PF SF ZF (AF undefined)
Performs a bitwise 'exclusive OR' of the operands and returns the result in the destination.
Bitwise Exclusive OR
XOR r/m8,reg8 ; 30 /r [8086]
XOR r/m16,reg16 ; o16 31 /r [8086]
XOR r/m32,reg32 ; o32 31 /r [386]
XOR reg8,r/m8 ; 32 /r [8086]
XOR reg16,r/m16 ; o16 33 /r [8086]
XOR reg32,r/m32 ; o32 33 /r [386]
XOR r/m8,imm8 ; 80 /6 ib [8086]
XOR r/m16,imm16 ; o16 81 /6 iw [8086]
XOR r/m32,imm32 ; o32 81 /6 id [386]
XOR r/m16,imm8 ; o16 83 /6 ib [8086]
XOR r/m32,imm8 ; o32 83 /6 ib [386]
XOR AL,imm8 ; 34 ib [8086]
XOR AX,imm16 ; o16 35 iw [8086]
XOR EAX,imm32 ; o32 35 id [386]
XOR performs a bitwise exclusive OR (XOR) operation between its two operands (i.e. each bit of the result is 1 if and only if exactly one of the corresponding bits of the two inputs was 1), and stores the result in the destination (first) operand ; each bit is 0 if the corresponding bits are the same.
The MMX instruction PXOR performs the same operation on the 64-bit MMX registers.
EXAMPLE:
mov eax 00_1111_1111
xor eax eax ; eax = 0
XLATB
Usage: XLATB translation-table Modifies flags: None
Replaces the byte in AL with byte from a user table addressed by BX.
Translate Byte in Lookup Table
XLAT ; D7 [8086]
XLATB ; D7 [8086]
XLATB adds the value in AL, treated as an unsigned byte, to EBX, and loads the byte from the resulting address (in the segment specified by DS) back into AL.
The segment register used to load from [EBX+AL] can be overridden by using a segment register name as a prefix (for example, es xlatb).
The original value of AL is the index into the translate table. The best way to describe this is MOV AL,[BX+AL].
EXAMPLE:
[Data: B$ 0, 1, 2, 3, 8, 5, 6, 7, 4, 9]
xor eax eax
mov ebx Data
mov al 4
xlatb ; eax= 8
XCHG
Usage: XCHG dest,src Modifies flags: None
Exchanges contents of source and destination.
Exchange
XCHG reg8,r/m8 ; 86 /r [8086]
XCHG reg16,r/m8 ; o16 87 /r [8086]
XCHG reg32,r/m32 ; o32 87 /r [386]
XCHG r/m8,reg8 ; 86 /r [8086]
XCHG r/m16,reg16 ; o16 87 /r [8086]
XCHG r/m32,reg32 ; o32 87 /r [386]
XCHG AX,reg16 ; o16 90+r [8086]
XCHG EAX,reg32 ; o32 90+r [386]
XCHG reg16,AX ; o16 90+r [8086]
XCHG reg32,EAX ; o32 90+r [386]
XCHG exchanges the values in its two operands. It can be used with a LOCK prefix for purposes of multi-processor synchronization.
XCHG EAX,EAX generates the opcode 90h, and so is a synonym for NOP.
EXAMPLE:
mov ebx 25 | mov ecx 10
sub ebx ecx
xchg ecx ebx ; ecx = 15