Loading AI tools
From Wikipedia, the free encyclopedia
{{gold software}}
File:RosAsmMainWindow.png | |
Original author(s) | René Tournois (Betov) |
---|---|
Developer(s) | RosAsm Community |
Initial release | September, 1998 |
Stable release | |
Operating system | Windows, Wine (software), ReactOS |
Platform | 32 Bits x86 architecture |
License | GPL free software license and RosAsm license |
Website | RosAsm site |
RosAsm is a 32-bit Win32 x86 assembler developed by a independent group of programmers and contributors. It is the continuation of a assembler called SpAsm, always under the direction of it´s original author René Tournois.
The name stands for ReactOS Assembler, meaning that it was designed to run on that platform as a primary operating system, although both projects are developed by an independent group of developers, not related to each other. ReactOS package does not include RosAsm assembler, and uses itself to assemble part of their sources.
RosAsm is a assembler with full integration of a IDE, resource editor, debugger and disassembler. The syntax is inspired by NASM's.
It is released under the terms of the GNU General Public License (GPL).
RosAsm packages the source code from which an executable was assembled directly within the portable executable files. Because RosAsm produces PE files directly, a separate linking step is not required. This means, though, that it does not allow linking to external object modules other than DLLs, and it does not support the ability to produce object modules that can be linked with other programs.
Nevertheless, the user is allowed to analyse a library file without the needs of linking. One of the features in RosAsm is a library scanner that can analyse the contents of a library file, export the object code, and in the near future convert the library to assembly code to be imported directly to the generated applications without the needs of linking.
RosAsm was always made entirely in assembly language and it is assembled by itself.
Disclaimer:
To avoid any naming confusions it is important to note that both projects (ReactOS and RosAsm) are made by independent group of developers not related to each other.
ReactOS package does not include RosAsm assembler, and uses another assembler (Nasm) to assemble part of their sources.
In September 1998, René Tournois (also known as Betov), created SpAsm - The Specific assembler which was maintained and supported by him until 24 July 2003. It was then continued with its successor, RosAsm.
René is RosAsm's principal author, although it includes many contributions from others. The very first version of the former Spasm project was built in 16 bits using the free version of a shareware assembler called A86/A386, from Eric Isaacson. With the help of this remarkable program, René continued improving his programming skills until he faced the world of 32 bit programming. In less then Two years, he migrated from A86 to the ASM32 assembler - by Intelligent Firmware Ltd -, whose simplicity, flexibility and very reliable overall performance for system programming, helped him to develop his own, independent and free assembler made entirely in 32 bits. In July 2000, Spasm 1.00 was born.
Since then, René continued his work, for several years, almost alone, releasing several versions of the Software. All versions released were maintained and developed under the GPL rules, in order to give to the assembly community a new and powerful tool, and for mankind in general, a free gift that can be used to improve their lives wherever possible by the continuous development of high technologies making them available to the public. In time he gained contributors that helped to improve his assembler.
Spasm 4.15j ,was the last of the versions released and maintained by René. On 24 July 2003, he decided to take a higher step toward advancing the benefit of Assembly Language and the free programming community. Concerned about the ongoing of the Software and his constant efforts in keeping with his ethical and political views, he left the project. From that remarkable day, RosAsm was born!
RosAsm 1.1a was the first version from the renewed Software, released on 27 July 2003.
All versions of RosAsm are a derivative work of all previous releases of SpAsm, except from it's version 4.15k (and newer) which were being developed and maintained by independent contributors. (Nowadays, the independent version of the former Spasm project seems to be discontinued)
RosAsm is a 32 bit specific assembler with an integrated IDE. As opposed to other Assembly IDE’s, which tend to impress the user by a heavy overload of features and multiple windows, the one of RosAsm is as naked and simple as possible. Most advanced features require reading the Manual, like the very powerful Right-Click, that you will miss it you don't read Source_Editor. For the assembler itself, it has been written with the following goals and characteristics:
Just a few words to tell what the main author means with "specific". He uses this word in both of two meanings simultaneously:
- Specific as specifically designed for only one file type production;
- Specific as a programming style that does things the simplest way, without any portability or reuse claim. Portability is a wrong headed idea. Reuse of routines should be avoided as much as possible because this is the most assured way we will be calling for a truck to carry a single strawberry.
Easy of usage:
Each assembler comes with its implied "programming philosophy" and the one of RosAsm is in some way being a "specific assembler":
Modular programming in assembly does not make much sense. If one wants to do modular programming, its better to use Basic. It does it perfectly. Now, the fact is that many programmers do not want to always re-invent the wheel, and want to easily reuse something , in some way, i.e. already written chunks of code.
In the good old DOS time, Static Libraries were very useful to save one from seemingly endless Compilation times. Even today, with some Assemblers such a Code-Reuse Method may be of some interest. Given the actual performances of hardware, and given the Compilation speed of RosAsm, this Compilation times argument falls flat on its face.
In many other Assemblers, you still have LIBs and INCs, and this is, yet today, the HLL way, but, once some code is saved as "reusable" this way, it becomes Black-Box. The bad thing with Black-Boxes is that you will forget what is inside, and, because reusing is easier than verifying what we are really doing, there are many chances that you will run inaccurate solutions to your programming problems.
An important point, with traditional libraries, is that such an implementation would completely break down two of the most important features of RosAsm, that make the developments fast and easy: 1) Right-Click advanced Searches and the 2) Source Level Run-Time Debugging.
To make a routine reusable, with these features, you have to make it hold all expected (and unexpected) possibilities. This is to say that you will run big engines to solve tiny problems, in most circumstances.
Facing these problems, RosAsm implemented advanced Code-Reuse features, in order to make it a really up-to-date Development Tool.
The main way chosen for reusing Code is a feature called "Clip". There are "Clips" Files aside RosAsm that the user can edit, in which he can save his precious chunks of code and templates. Inside the Main Editor, there is a Menu option that runs a Clips Dialog allowing to choose / customize / Save in ClipBoard. Then, the user pastes it inside his source. Once done, he can adapt the pasted code to his real requirements. All of this is not much longer than LIBs and INCs techniques, but is far better from an Assembly point of view.
Another method, for the programmers who really want "Libraries", is to consider the use of the TITLE feature as an intermediate solution: We could as well call the TITLE saving, reloading, updating methods a kind of "Source Level Library" method. It is quite simple, to save the Library under the .asm form (Ctrl+S, and/or to save a ready to reuse Application with only the Base and the Library inside). At least, this intermediate solution will enable you with all the so useful features of Right-Click and with a direct pointing in error cases, if nothing else...
RosAsm syntax was made as easy and the most flexible as possible, allowing to the user/programmer to build is applications choosing all sorts of writing styles.
The Wizards Concept
A Wizard is a Visual Designer Interface that creates a Source Template to be pasted into a client Source.
RosAsm Wizards are independent PE files, to be located in the [RosAsmFiles] Folder, aside the Equates Files, the Interactive Visual Tutorials, and friends. For now, only one Wizard is available, and is still under development, the Form Wizard.
You can run the Wizards either by the [Wizard] Menu Item, for fresh new creations, or you can re-edit an existing Wizard Template, by Right-Clicking upon the associated 'Tag' Comment in the source code.
The Wizards Templates
When leaving the Wizard, the edited Template is pasted inside your Source, at the actual position of the Cursor.
You should never remove, or even modify, these Comments and the in-between Sources, if you wish to keep the re-edition possibility. Modifying something inside the Template Source will be erased by a re-edition.
Because of this difficulty, you should always paste your Wizards Templates at the end of your Source, in a dedicated TITLE, in order to make sure that you will never accidentally modify them. The Source Editor has actually no security implemented to save you from such accidents.
The actual Form Wizards
This first Wizard is still under development and is actually used to study, define and finalize the exchange mechanisms between the Source Editor and the Wizards. It is fully effective, but will probably be improved and extended.
The purpose of this Form Wizard is to visually edit the windows interface of a Program, a bit similar to what the Resources Editor does, but in a more powerful and flexible manner as, in this case, the creations are not based on Dialogs, but on the 'CreateWindow' Function.
The Form Wizards Files
The Window Wizard File (*.wwf) format is used to store all information about a form.
See the Wizard source code for additional information on the file format (TITLE Help of the main RosAsm source code).
Wizard Global Introduction
Drawing
All drawing actions can be done with the mouse.
Properties
The properties window allows you to modify all the styles available for a given control.(Window Tab for window styles, WindowEx Tab for extended window styles and Control Tab for control specific styles)
The A-Z Tab contains additional information:
Code writing
You can output the code corresponding to your form in several ways. (All these options are available in the Output menu)
Menu Itens control
File New : Create a new form Open : Open a new *.wwf file Save : Save the current form Save As : Save the current form with new name Edit Bring To Front : Bring the control to the top of the Z-Order. Send To Back : Send the control to the bottom of the Z-Order. Delete : Delete the current selected control(s). Lock Controls : Lock control position.
Output Display
Requirements
The wizard uses a file so as to store all the window and control styles.
The file rwslist.dat is a raw list of all available styles with only basic information. You can get more information about this file in the Wizard source (TITLE Help in the main rosAsm source code).
RosAsm comes with an integrated debugger which is built on top of the Win32 Debug API. When you Run / F5 your application (the debuggee) from inside RosAsm, it is automatically debugged. If you try to run a DLL, the debugger asks for a host process, which is expected to load the library.
The debugger will point out eventual exceptions in your source with the faulty instruction highlighted and a detailed exception description.
Furthermore you can set breakpoints in your source either at design time or at run time. When the debuggee encounters such a breakpoint, the OS transfers control to the debugger and halts all threads of the debuggee. With the debug dialog you can view the current flag states, register & data label values and view the contents of the whole address space of your application. The flags are embedded in the toolbar and can be shown and hidden through its context menu (right-click on toolbar).
Exceptions
When the exception box pops up, something went wrong in your application. The debug dialog title shows 'EXCEPTION' and the exception dialog title tells about the code module in which the crash occurred. A detailed exception description is given in the text window. Furthermore the instruction that caused the exception and its address are provided. In case of access violations additional information about the address which was tried to access and the access mode is shown below.
In general, the debuggee must be terminated when an exception occurs. Take care that the debug dialog is closed when you press Terminate. Therefore be sure to analyze the cause which may have led to the crash before you exit.
When you make use of structured exception handlers (SEH) the exception is still reported but you have the chance to forward it to the handler by Pass to SEH. If the exception is handled, the debuggee continues, otherwise the exception will be reported again without the possibility to pass it to the handler.
If the exception dialog caption doesn't show the name of your application but some other module like user32.dll, the exception happened outside of your application and (hopefully) a call to a external routine is highlighted. This does not mean, however, that it isn't your fault :) Most of the time missing or wrong parameters are the reason for these crashes. Check the call stack if in doubt which parameters have been passed to the routine(s).
Another possibility is an Exception in the Non-Code Section. The instruction pointer (EIP) was corrupted and triggered an access violation when the CPU tried to execute code at an inaccessible address. Instructions that may corrupt EIP are stray jumps or a ret when a wrong number of arguments have been passed. A look at the call stack might give a hint.
Registers
The register tab gives insight to the contents of the CPU registers. The debugger checks whether MMX, SSE is supported on your machine and shows additional pages in the tab if appropriate. Segment selectors and debug register (+EIP) pages can viewed / hidden in the debug dialog menu settings. The combo-box offers various representations of the register contents, particularly useful to debug MMX/SSE code with a vector representation of mm0-7 / xmm0-7.
The general purpose registers page differs from the other pages in that it contains buttons for each entry: If EBX contains a valid 32-bit virtual address in the process address space, clicking on the EBX-button takes you to the address referenced by EBX in the memory inspector.
The register contents are all shown zeroed until an exception occurred or a breakpoint is reached.
Setting Breakpoints
You can insert Breakpoints into your source, in two ways:
Flow control / Tracing
When a breakpoint is encountered the next, not yet executed instruction is highlighted. To continue you can use the Continue menu items, the toolbar buttons or the corresponding shortcuts.
Source editor integration
RosAsm debugger operates on the source level. What does that mean in the context of assembly language? It means that you have full access to all symbols (code & data labels, equates) and the tracing takes place in the source editor. When stepping, the instruction which is executed next is highlighted. In case of instructions which have been generated by macros or pre-parsers the statement is highlighted from which the instruction was generated. To keep track of the progress inside the statement, the disassembled instruction is shown in the caption of the debug dialog.
If single-stepping multiple instruction statements is not wished, you can switch to 'Source level stepping' in the debug dialog menu settings. In this mode the debuggee is continued until the next source statement is reached. One of the benefits of operating on the source level, is the possibility of mouse sensitive data observation. When you move the mouse over an addressing expression (e.g. D$eax+8) in the source editor while debugging, you'll see the resolved virtual address (e.g. 010008 if eax=010000) and (if it is a valid address), the 32-bit value at this address in various data representations (hex, unsigned & signed decimal). Observable expressions start with D$, W$, B$, F$, R$, T$ and may contain registers, numbers, plain data labels & equates, segment selectors and '+', '-', '*' as operators. Q$, X$ and U$ are not yet supported. The size specifier determines the quantity and quality of the displayed memory contents. For example, D$ and F$ both reference 32-bit values but the latter is represented as floating point. Expressions which contain local labels or equates can only be observed if those belong to the procedure currently being executed. In other words, when you step through 'Foobar' you can observe the labels and equates local to Foobar in the form 'D$@Local' or the more common 'D@Local'. Examples for legal observable statements: B$eax F$DataLabel+ecx*4+EQUATE W@Local+2 ; only if CurrentLabel@Local is defined D$fs:8 To view the locals of the caller function(s) you can use the call stack described later in this document.
Data viewer
The data viewer shows all data symbols and their virtual addresses declared in your source. When selecting a symbol you can see the content with different representations in the window below the label list. The representations comprise Dword, Word, Byte sizes in Hexadecimal and Decimal (signed and unsigned) notation, floating point in single and double precision, and, if the data stream consists only of printable chars, the ASCII representation.
When right-clicking on a data symbol you can choose to view the content in the memory inspector, or, if the Dword content of the data is a valid address in the process' address space you can view the referenced memory. You can also search the declaration in the source, change the sort order of the symbols (by name, by address) or set watchpoints.
Watchpoints
Watchpoints can be assigned to data symbols. They are useful to observe write and/or read accesses to data, therefore they are sometimes referred as data breakpoints. To set a watchpoint, right click the symbol you want to observe in the data viewer and select 'Break On Write Access' or 'Break On Read/Write Access'.
Watched data symbols are highlighted red (write) or orange (read/write). In the current implementation you cannot set multiple Watchpoints at the same time. Therefore, if you assign another watchpoint to a different symbol you will lose the old watchpoint.
When a watched access is observed the debuggee is halted, the title shows 'WP ...', the data viewer is activated and the watched data symbol is selected. Some implementation specific details:
Memory inspector
With the memory inspector you can view the memory contents of the allocated memory of your process. The memory is displayed in 4kB chunks which corresponds to the typical page size on x86 systems. The edit box shows the virtual address of the page in hex notation. Each list item contains an offset (e.g. +3F8) and the memory contents at this address. To view content at a specific address just enter it in the edit box and press return or use the virtual page table to select another region. You can also use segment overrides: e.g. FS:8 displays the TEB and goes to offset 8.
Call stack
The call stack shows the called procedures (labels) along with their parameters and local data. As the name implies it is derived from the stack content. When right-clicking on a function name you can show the invocation or declaration. The call stack is built using advanced interpretation mechanisms and should also show function calls inside modules, functions which don't setup stack-frames, ... However, it is only an interpretation. If your code or the modules you use make dynamic stack allocations (sub esp eax) or use jump tables the success rate will drop significantly. (It also does not handle spaghetti code very well) .
Best results are achieved if you follow these rules:
Function calls which belong to different modules (referenced code is outside your source) are grayed for clarity. If the information given is yet too detailed you can filter the output by right-clicking on any function name and selecting 'Hide module calls' or 'Hide intra-module calls'.
Debug log
The traditional way to debug code when no debugger is available is to log information to the console or a file. This might even make sense if using a debugger: For example, when the applications working is time-dependent and halting the program for inspection is not feasible because it would tamper with the output. Win32 offers a function for applications to pass strings to a possibly attached debugger: 'OutputDebugString'. When the debuggee calls 'OutputDebugString' the debugger is invoked and adds the string to the log tab and a log file is created aside the application with the name '[AppName]_dbg.log'. call 'Kernel32.OutputDebugString' {'Hello big brother' 0} For convenience the log tab also lists mapped & unmapped modules and the creation and destruction of threads. Note that 'OutputDebugString' causes a context-switch to the debugger and thus is an expensive operation.
Address space
The address space tree shows all user accessible virtual memory pages of the debuggee. These are comprised of the mapped PE, the process environment block (PEB), the thread environment blocks (TEB), the stacks, the imported modules, the modules loaded by LoadLibrary, memory allocated by VirtualAlloc and the environment.
The root nodes can be regarded as the 'logical groups' in which the memory was reserved while the leaf nodes represent the actual 4kB pages represented through the virtual start address and page properties (eXecute, Read, Write, Copy on write, Guard, No cache). When you double-click on a leaf node the page is loaded in the memory inspector.
RosAsm comes with a library scanner which is built to the user or programmer analyse or study COFF library or object files.
The library scanner creates a structured form ready to be assembled.
The main purpose of the library scanner is to provide to the programmer an alternative way to analyse or insert his object files inside his project.
As opposed to linkers, the library scanner was designed to recreate the source code from a given library file to the user insert on his application only the function or data he wants with the hability to rewritting his work if needed.
What the library scanner currently does:
What the library scanner will do:
Purpose and scope
The Library Scanner will remain under intensive developments for several months. In its final state, it will be a feature used in the main Decompilation output process for a complete restoration of the Targeted File, ready for re-compilation in a significant amount of cases.
When you open a PE file without a Source Code inside or not written with RosAsm, RosAsm offers to Disassemble it. The proposed options are:
General approach RosAsm's Disassembler is first, an Automatic Disassembler, that tries to provide a Source that could be re-compiled without any further hand work. This is actually effective on most small Demos. Between, say, 100 and 300 Kb, this may also work, but it depends, essentially on the quality (clean vs dirty construct) of the PE. Over this size (Megabytes) there is no hope, and probably never will be, unless the PE organization would be absolutely standard.
What the Disassembler actually does
A bit of Interactivity has been introduced since RosAsm V.2.022a.
What it does not do
Practice In practice, if you believe that you will have the possibility of disassembling a big Executable, and of re-Assembling it in two clicks, you will be disappointed. This is not at all the purpose of the Disassembler, and no Disassembler on earth will ever do that. It is simply impossible, unless the complete file would be 100% standard, from a Sections point of view and 100% clean, which is extremely uncommon.
So, work first with small Applications.
With middle size (100 / 300 Ko), you may have a valid Disassembly, that would not reflect exactly the Disassembled PE, because of minor failures.
The most usual failure cases are with erroneous interpretations of small Chunks of Data or Code. In these cases, you may give a try to the "Bad Disassembly" Option of the Float-Menu, when double-clicking on the suspected Label.
Then, once the Application is correctly re-compiled, it may also misbehave because of several minor points, that you may have to fix by hand, after analysis.
Purpose and scope
The Disassembler will remain under intensive development for several months. In its final state, it will be a universal Decompiler outputting a complete restoration of the Targeted File, ready for re-compilation in a significant amount of cases.
Even in case of failure of the full "Two-Clicks-Disassembler-ReAssembler" process, the results will often be usable, at least, for study and for helping at the translation works.
The Disassembler is a Study and Translation Tool designed for the Open Source Movement. The main goal is to make the translations of Demos and Tuts to RosAsm syntax, as easy and fast as possible. Even when having the Sources, a port to Assembly may be not so easy, with big files. We can be sure that the Disassembler will, at least, make fewer translation errors, and will take much less of our working time than we would when translating it by hand.
Note: The colors of the images displayed here were made by one of the developers. They are not the default from RosAsm.
There are few games created with RosAsm. A remarkable programmer called GGes built some interesting and entertaining open source games with RosAsm.
Another programmer called Martin created a remarkable NES emulator called Nessie (emulator) in a short period of time using RosAsm.
Assembly is a language suitable for creating all sort of applications, and in what concern game development this assertive couldn´t be more true.
As an opensource program, RosAsm is in constant evolution. The developers works hard to bring to the assembly community a full integrated programming environment, where the creation of programs can be made as easy and fast as possible.
RosAsm developers are working hard on the current projects:
The developers are working to provide this tools as fast as possible, even if the actual staff contains a very limited amount of developers contributing to the whole package every day.
Developers:
Name | Country | Activities | Current Status |
René Tournois (Betov) | Meuse, France | Main Maintainer | Retired |
Ludwig Hähne (wkx) | Germany | debugger Command Line. debugger Maintainer. | Active |
Gustavo Trigueiros (Guga, aka Beyond2000!) | São Paulo, Brasil | Win32 Doc Project Maintainer (Equates, Api, Structures). General overview of assembler, disassembler, creation of LibScanner, Digital DNA System, among other things. | Active |
Julien (Scarmatil) | France | Equal Pre-Parser. Form Wizard. | Active |
Are Jon (Half a Wannabe) | Norway | Unused Symbols Box, IncInclude Preparser and demos. | Active |
Yeohhs | Malaysia | Examples, tutorials, guides. | Active |
Eric Asbel | Indiana, USA | Board Maintainer, creation of COM examples. | Active |
James F. Marinic | USA | Proof-reading of the help file (B_U_ASm) and creation of Visual Tutorials. | Active |
Diego Fraga | Argentina | Rewrite of the Resources building, with Named IDs assumed. | Active |
GGes | France | Game developments, demos and tutorials. | Active |
Rémi Coquet | France | Guid files with assistance of René Tournois. | Active |
Joddy Xefer | Brasil | RosAsm logo. | Active |
Nico Nico (Scalp) | France | Mouse Wheel implementation | Active |
Rikkert Vifferin (EvilBro) | Netherlands | Rewrite of the assembler Parsers. | Active
|
Ken Bentley (Kenny) | California, USA | Keys Table managements in the Source Editor. Former OpHelp.exe Manager | Retired |
Peter Tuente (Pit) | Germany | StatusBar implementation | Retired |
Marcelo Zamateo (Zama) | Argentina | FPU HLL Pre-Parser | Retired |
Category:Assemblers Category:Programming languages Category:Assembly languages Category:Disassemblers Category:Debugging Category:Articles with example Assembly code
bg:RosAsm ca:RosAsm cs:RosAsm de:RosAsm et:RosAsm es:RosAsm fr:RosAsm it:RosAsm he:RosAsm hu:RosAsm nl:RosAsm ja:RosAsm no:RosAsm pl:RosAsm pt:RosAsm ru:RosAsm sk:RosAsm fi:RosAsm sv:RosAsm uk:RosAsm zh:RosAsm
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.