Visual Assembler::Developer Information --------------------------------------- 1. IDE Coders 2. ASM Coders 3. Documentation/HLP Files 4. Tool Development 5. DLL "Wizard" Modules A note about contacts: The "Contacts" field lists the developers who are working in the relevant area and would best be able to answer questions. They may be contacted through the message board if their email is not listed on the Visual Assembler home page. -------------------------------------------------------------------------------- 1. IDE Coders ============= Contacts: The+Intern, +ReZiDeNt The IDE is being coded in Borland C++ Builder; it is preferred that IDE coders have a copy of Borland C++ Builder, though of course standard C and C++ code can be incorporated. The bulk of the IDE work that must be done lies in five areas: Editor The Code Editor is to be a fully-functional programmer's editor, with syntax highlighting, search/replace, and standard clipboard cut-copy-paste functionality. It currently can open any file that will fit in a rich text edit box, though eventually it would be useful to incorporate code that can load any size of file (i.e., disassembled listings). Code Insertion Both the Code Insertables and the Components contain asm code and routines that will be inserted into user modules; the Insertables will paste code into the current cursor position of a text file opened in the editor, while the Components will add routines to .asm modules in the current project. The code insertion interface--which will rely on code in SCR modules--needs to be designed to cope with "project" and "non-project" files, to check for previous code insertion (in the case of Components), and to allow the SCR components to be previewed (i.e. dumped into the Message Window) in lieu of being inserted. Project Interface The "project" interface for Visual Assembler needs to be developed and made more interactive. Loosely speaking, a "project" will be any set of .asm modules that are partially generated by Visual Assembler and which must be compiled together. All "wizard" modules will produce a Visual Assembler "project", but there should be some provision for the user creating a project--with or without .asm modules created from Visual Assembler templates, but with a project.ini file--without using a wizard. Visual Assembler projects will be characterized by a global data module (e.g., "maindata.asm"), a startup code module (e.g., "startup.asm" for DOS programs or "winmain.asm" for win32 programs), and a code routines module (e.g. "proc.asm") which will contain the code routines inserted by the Components. A "New Project" dialog box--used in place of a Visual Assembler "wizard"--should prompt the user for a project name, directory, target assembler (Tasm, Masm, etc), target OS (DOS, Win32, Linux, etc), executable file type (com, exe, dll, vxd), and for the names of the global data, startup, and code routines modules. Wizard Interface Visual Assembler will support "wizard" dlls that will be placed in the \Visual Assembler\Wizards subdirectory. A wizard will prompt the user for specific information (for example, variable or class names) which it will need to generate the source code for the user; it will create the project.ini file and fill it with the information normally provided by the user in the "New Project" dialog. The actual .dll calling interface has not been fully developed yet, though currently the plans are to list all of the wizard dlls in a directory list box, to call the exported "BuildSkeleton" function of the dll chosen by the user (passing it the pointer to a structure to fill with info on the project), and to open the files specified in the project.ini ceated by the wizard after the wizard has finished. It is undetermined as yet whether the IDE will create the project.ini file based on information supplied by the wizard, or whether the wizard will create the project.ini itself (current opinion seems to favor the former as the code will be in the IDE for the "New Project" dialog). Configuration The IDE will contain information for the configuration of tools, compilers, help files, projects, and for Visual Assembler itself. The configuration routines must therefore be constantly updated and tested. 2. ASM Coders ============= Contacts: mammon_, wbinvd Needless to say, there is plenty of assembly language coding to be done--though most of it will be rather rudimentary, as it is for examples and/or insertable code. A great deal of the work will be writing (or copying public domain) asm snippets and converting them into SCR files. Of course there is a need to have a standard "look" for all insertable code; I have been working with a three-space tab for actual opcodes and having everything else flush with the left margin. Proposed coding standards are welcome. Insertable Code Modules The Insertable Code modules will all be in SCR format. An insertable module is a snippet of asm code that can be pasted into any asm program (depending on the compiler, of course) regardless of whether or not that program is a Visual Assembler "project". The insertable modules are contained in the tabs of the Code window on the bottom right of the screen. API:Multi-line insertables demonstrating the use of common Win32 API functions. // Function: MessageBox // Data EXTRN MESSAGEBOX:FAR // Code push WORD PTR {hwnd} ;hwnd= handle of parent mov ax,OFFSET {szText} ;szText= text in MessageBox push ds push ax mov ax,OFFSET {szTitle} ;szTitle= title of MessageBox push ds push ax mov ax, {MB_STYLE} ;MB_STYLE=style of MBox, eg MB_OK push ax call MESSAGEBOX Asm Templates (formerly "Asm Headers"): Multi-line templates for different types of target executables, such as COM file, DOS EXE file, DOS TSR, Win32 EXE, Win32 DLL, Win32 VxD, etc. // Function: DOS .exe file // Creator: Greythorne // Code ; .EXE File Program Template (EXE.ASM) ; snagged from greythorne :) .model small ; normally small medium or large here .stack 200h .code EXE_PROG segment byte public assume cs:EXE_PROG,ds:EXE_PROG,es:EXE_PROG,ss:EXE_PROG ; Start of Program (Entry Point) start: jmp MAIN_PROGRAM ; ------Your Data Here------ MAIN_PROGRAM: ; ------Your Code Here------ ; End of Program (Exit Point) mov al, 0h ; return code (0 = no error) exit_program: mov ah,4ch ; quit to DOS int 21h EXE_PROG ends end start C Routines (formerly "C-Style"): Multi-line insertables demonstrating how to implement C language structures, statements (eg "for", "if...then", "switch...case", etc), and standard library routines (e.g. strlen() ) in assembly. SampleSCR: // Function: For x=0, x cold boot, else warm boot */ PUBLIC reboot reboot PROC warm:WORD xor BX,BX mov ES,BX mov AX,warm ; AL=1 for warm boot, 0 for cold cmp AL,1 jnz @NcB mov AX,1234H ; Avoid POST @NcB: mov ES:[BIOS_POST],AX ; Install flag cli ; Reboot xor AX,AX mov DS,AX mov ES,AX mov SS,AX mov SP,AX @cP: in AL,64H ; Wait on AT keyboard controller test AL,2 jne @cP mov ah,0d ; DOS function 0Dh: flush disk buffers int 21 ; (this will also flush most caches) xor AL,AL ; Try reset lines out 64H,AL mov ax,0000 @Dly1: dec ax ; Delay loop: wait for reset signal cmp ax,0000 jnz @Dly1 mov AL,0FEh out 64H,AL mov ax,0000 @Dly2: dec ax cmp ax,0000 jnz @Dly2 ; Still going? hardware reset failed mov AX,0002H ; Jump to reset vector push AX ; via IRET mov AX,00000H push AX mov AX,0FFFFH push AX iret reboot ENDP end Opcodes: One line asm snippets demonstrating the use of Intel Opcodes. Sample SCR: // Function: mov // Code mov {dest}, {src} ;move data at src addr/reg into dest addr/reg Prefab Components The Prefab Components will be stored in SCR format. A component is an assembly language routine whose code is inserted into a special "userproc.asm" module of a Visual Assembler project, and whose data is inserted into the main "globaldata.asm" file. Once inserted into the project, the routine can be called from within any of the project modules. Note that this could also be accomplished by linking asm libraries to the project, however I prefer allowing the user to modify the source code for the routine before compilation. The components are contained in the tabs of the main Visual Assembler window at the top of the screen Dialogs: Common Dialogs used in windows 95 (Print, File Open, Font Select, Find/Replace, etc) The following are ideas for additional Component categories: DDE: Dynamic Data Exchange routines Hooks: Routines for hooking standard windows events OLE: Object Linking and Embedding routines MultiMedia: Imaging, Animation and Sound routines Resources: Custom controls, list boxes, tree views, etc VxD: DeviceIO handlers and other VxD functions Winsock: Socket Creation/Connect/Disconnect routines, plus ping, listen etc routines Sample Programs When Visual Assembler is completed and distributed, there should be some sample assembly language applications to demonstrate just how this sort of programming is done. It would be good to have a wide variety of programs, such as a text editor, a ping program, a graphic file viewer, etc, as well as to have a few that demonstrate the low-level power of assembly, such as a file patcher, a process patcher, and an absolute disk editor (possibly even a rudimentary file infector ;). Multiple Compiler Support Visual Assembler will support the use of multiple compilers; the compilers.ini file lists the assemblers that will venetually be fully supported. Note that source code must be written for each assembler in the case of insertables and components; each type of assembler will be an "owner" in the SCR file and have its own code (note that many compilers are tasm or masm compliant; if an OWNER: key is given to each section in compilers.ini, these assemblers can have TASM or MASM listed in their "owner" key rather than their own names--this will require less code redundancy inside the SCR files). When inserting code, the current assembler (defined as' the default assembler or the target assembler specified for the current project) will determine the "owner" of the code to be accessed in the SCR file; thus, if TASM is the current assembler, then code functions owned by TASM will be inserted; if MASM is the current assembler, then code functions owned by MASM will be inserted, and so on. This eliminates the need for asm source code with conditional-compilation macros, which is not only tougher to code but alos harder to maintain. Header Files Header files for each assembler will be needed by Wizard developers. Header files will be assembly language .inc files such as w32.inc or windows.inc which contain constants, defines, and procedure declarations which will make the asm application easier to code. A class library can also be created for Tasm-only projects. SCR File Format I see no reason not to quote directly from n00se's documentation: "There are nine tag lines which identify the text which follows. These are: // Owner: --- (1) // Function: --- (2) // Creator: --- (3) // Description --- (4) // Data --- (5) // Code --- (6) // Unicode --- (7) // Ansicode --- (8) // End --- (9) (1) // Owner: This specifies the name of the owner of the following function(s). An Owner is name which is used to identify the collection of functions and used by the SCRF routines to know which functions to load. This is NOT case sensitive. (2) // Function: This specifies the name of the function which is following the tag. Again this is NOT case sensitive. (3) // Creator: Specifies who created the function(s). If this appears after a // Function tag then it is associated to this function only. If it appears after a // Owner tag then it is associated to ALL the following functions unless they are overided by a local // Creator tag. (4) // Description This identifies that the following text is a description of the function. (5) // Data Specifies that the following text will be data for the code that follows. This should follow any Code tags. (6) // Code Specifies that the following text will be source code for the function (7) // Unicode Specifies that the following text will be UNICODE source code for the function. This will be loaded as a separate function (so will appear as a function in the numFunctions() result). (8) // Ansicode Specifies that the following code will be ANSI source code for the function. Again, this will be loaded as a separate function. (9) // End Marks the end of the whole SCR file. This actually isn't entirely necessary since the end can be detected by other means. However, it is recommended that you use it since it ensures that there are no superfluous empty lines of code on the last function in the SCR file. A rule of thumb for all of the tag-lines is that if the tag ends in a colon (':') then it is expected that the text for that tag will appear on the same line as the tag. e.g. // Function: DOS_OPENFILE_RO // Owner: BEGINNER_DOS // Creator: Noose Likewise, if a colon does not appear at the end of the tag then it is expected that the text will start on the NEXT line, and the block will be terminated by any other tag appearing at the start of the line. e.g. // Description This function will display something It will not destroy any registers // Code Where the Description block has been terminated by the Code tag. I've made this intentionally flexible though. If you specify a colon when one isn't needed, it will be ignored, and likewise if you don't specify one then it will be assumed. In fact colons aren't required at all, it just makes the tag lines a little clearer. 3. Documentation/HLP Files ========================== Contacts: i_magnus, Dr Slack There has been some concern regarding the use of pre-written tutorials which will be converted to .hlp format and supplied with Visual Assembler. It is my opinion that anything published on the web is de facto public domain and therefore redistributable, though to prevent copyright infringement it should be clear that such documentation, though available for download through the Visual Assembler web page, are intended only for the internal use of the project and therefore are not to be considered a public "distribution". That said, the help files available with (or around ;) Visual Assembler will be of the following three types: Documentation Of course documentation will be needed for the Visual Assembler IDE, tools, wizards, and sample code--not to mention installation instructions and troubleshooting. Tutorials Tutorials on the use of Visual Assembler, on assembly language programming, and other relevant topics (for example, using hex editors, disassembling programs, etc) will be necessary for the final distribution. Reference Reference material in .hlp (or similar) format will be needed for assembly language topics such as opcodes, BIOS/DOS services, File Formats, etc. 4. Tool Development =================== Contacts: mammon_ Visual assembler will ship with two types of tools: Integrated Tools The Integrated tools are binary executables which will be used by the IDE; as the filenames will be hardcoded into the IDE, these are not meant to be changed by the user. These tools can be exe or dll files, and will include a code browser, a file dumper, a debugger, a disassembler, and a resource editor. External Tools The External tools are shipped with Visual Assembler but can be changed by the user to point ot "foreign" tools. These should all be .exe files and will include a calculator, a hex editor, and a text editor. 5. DLL/"Wizard" Interface ========================= Contacts: Net Walker, IceMan Code generating wizard DLL files will be needed for a number of application types. Current plans include wizards for generic windows EXE, DLL, and VXD files, though it would be a good idea to provide code generation DLLs for specific application types, for example: debuggers, disassemblers, hex editors/dumpers, file patchers, etc.. Suggestions and submissions for wizard DLLs are accepted and even encouraged. rev 7.08