What is GeneSys all about??

[grofaz]

How is it different from basic masm32 package?? Custom libraries or what??

[Vortex]

Hello dEbUgGeR,

GeneSys is a package designed for people who are making their first debut in Win32 assembly. It has ml.exe , link.exe and the other necessary tools to develop applications in assembly. The project offers various GUI and console examples to the user. GeneSys comes with a run-time library developed and maintained by members of the Masm forum. The project does not only support Masm but it also supports Poasm, a nearly Masm compatible assembler maintained by Pelle Orinius. GeneSys comes also with a user-friendly editor making easy the coding and building stages of asm projects for beginners.

You can contribute the GeneSys project if you have interesting examples and tools.

The idea to create a package targetting new asm coders came from Pbrennick who is also a professional coder.

Masm32 is a project created by the board administrator Hutch and the author of the famous Win32 asm tutorial series, Iczelion. The project is dating back to the late 90s and today Hutch maintains the project. Like GeneSys, it comes with a run-time library with specialized functions. The package provides a macro set enriched with HLL elements making easier a lot Masm32 programming tasks.

[grofaz]

Right, I'm familiar with masm32 so I was wondering why anyone would go with GeneSys package when it at first glance appears to be more or less masm32 ? That's my question, what makes GeneSys desirable ? The examples, the macros, what ? What does it do that masm32 doesn't ? I'm not picking on GeneSys mind, I just what to know the gritty details. I have masm32, fasmw, hla, and gas on board already. GeneSys too, so I was wondering. I like asm. :)

Thanks man!

[Vortex]

Hi dEbUgGeR,

Desirable : One of the main features of GeneSys is that it supports not only Masm but also the ml.exe compatible assembler Poasm.

Another fact : You can always contribute the project with your opinions, examples, tools, algos, tutorials etc.

I think the right answer for you would be to try the GeneSys package. Feedback is always welcome.

[hutch--]

dEbUgGeR,

The differences are in the target market, where Paul and Erol (Vortex) have targetted closer to the learner market the masm32 project is primarily an SDK targetted at experienced programmers. Much of the code / libraies in masm32 assume that the programmer already has an extensive background in win32 in both API style coding and direct assembler mnemonic coding.

While the design of masm32 has tried to simplify much of the coding with pseudo high level code in macros and libraries, Paul and Erol as well as a number of code contributors have deliberately avioded the more complex code so that GeneSys would be more user friendly to programmers who don't have years of experience in API and mnemonic coding.

[grofaz]

I see, thanks for replies.  :U

[PBrennick]

dEbUgGeR,

While the design of masm32 has tried to simplify much of the coding with pseudo high level code in macros and libraries, Paul and Erol as well as a number of code contributors have deliberately avioded the more complex code so that GeneSys would be more user friendly to programmers who don't have years of experience in API and mnemonic coding.

In one short paragraph, Hutch has perfectly stated it. There is, also, no attempts made to optimize the code as this winds up being a type of obfuscation. I believe that, eventually, everyone needs to know how to optimize code (such as is done by Lingo who, in my opinion, is the best there is), in the beginning, it is more important to build reliably functioning code. Because of this, I will never write a procedure that uses an instruction such as 'ret 16' or OPTION PROLOGUE:PrologueDef, OPTION EPILOGUE:EpilogueDef, etc. These are complicated for the beginner and are not necessary to use in the creation of a stable program that does not throw GPFs.

There is also a lot to be said about the layout of your code. I believe if code is ordered in a certain way, it is more comprehensible, so I encourage the development of this type of habit.

By no means is this a slight of masm32 and this is not nor has ever been a competition. Very few people realize how much help I have received from Hutch. In the beginning, we both saw this need and decided that this is the best way to handle it. There is supposed to be a new set of API directed tutorials and they 'will' come but as most know, my medical issues were ruining the dream. They no longer are an issue so at some point development of GeneSys will resume.
More and more things like the following will start to appear in the project:

What is a Procedure ?



Higher level languages use a variety of names for seperate blocks of code that perform certain tasks and this ranges from "functions" to "routines" to "subs" and the associated "subroutine" but all of these designs are a subset of what is called in assembler programming, a procedure.
Procedures are directly supported by the processor with the CALL and RET instructions which form an efficient means of branching to another location, running the code at that location and then returning back to the following instruction after the one that called it.
At its most basic a procedure is identified by its starting location, a block of code that is run and a following RET instruction that branches back to the instruction after the one that called it. When coded at low level it looks something like the following.

    myproc:
    ; block of code here
    ret

When the program calls this code it is done with something as simple as,

call myproc

The CALL instruction branches to the label in the procedure "myproc", the code at that location is run and when the RET instruction is reached, the execution of the code branches back to the instruction that follows the original CALL instruction.
This technique at its most basic is very simple but it does not allow the programmer to do things that are common in writing software like passing arguments to a procedure and using LOCAL variables within a procedure.
The technique that makes all of the other methods possible is a section of memory that is called the "stack" and this memory is directly addressed by the stack pointer register ESP. Once stack memory is available, it can be used to pass arguments to the procedure and allocate space for local variables that are commonly used in writing procedures.
All of this code can be written manually but it tends to be an advanced technique that is mainly used for specialised high speed code but MASM has a standard method of constructing procedures that simplifies their operation and is highly reliable using the PROC / ENDP operators available in the language. A normal MASM procedure looks much like the following code.


    masm_proc PROC arg1:DWORD,arg2:DWORD
    LOCAL var1 :DWORD
    LOCAL var2 :DWORD
    ; code is written here
    ret
    masm_proc ENDP

This MASM PROC build what is called a "stack frame" which preserve the values in both ESP and EBP, allocates the storage for the two LOCAL variables and when the procedure is finished it restores both ESP and EBP and balances the stack so that the stack pointer when program execution is back in the calling procedure has the same value as when it called the procedure.
The RET instruction in this context is actually treated like a MACRO in that it varies depending on the arguments passed to the procedure. If there are no arguments, RET is actually the OPCODE "C2" but if the stack must be balanced to compensate for arguments passed to the procedure, the OPCODE "C3" is used as it takes an extra 2 byte argument for the byte count to balance the stack.
The method described is the common method used in Windows programming and it is part of the standard calling convention STDCALL but MASM can also handle the main alternative which is the C calling convention and they differ only in this much that a procedure that uses the C calling convention can pass a variable number of arguments to the procedure as long as it is written correctly to handle this situation.
The STDCALL calling convention already knows what the argument count and stack correction needs to be so it simply does this with the RET instruction but when the number of arguments are controlled by the caller, this cannot be done. Where the STDCALL calling convention balances the stack on its termination, the C calling convention performs the stack balancing from the caller's end and this is usually done in the following manner.

    push arg2 ; 4 byte variable
    push arg1 ; 4 byte variable
    call myfunction
    add esp, 8 ; balance the stack AFTER the procedure has returned.

Under normal terminology the STDCALL calling convention cleans up the stack where the caller with a C calling convention must clean up the stack.
In both instances a MASM PROC handles the different calling conventions correctly and this is normally determined by the PROTOTYPE for the procedure which specifies which calling convention is used.

These type of informations need to be created in response to a request from a user. It would not be very helpful for us to assume what you need to know. YOU need to tell me what confuses you most.

Another thing is the builder tools, I have been working a long time on automating this so a beginner can concentrate on learning assembly and NOT learning an IDE.

I hope this adequately answers your questions and I hope you will come back with some questions, problems and concerns. And, by all means, embrace the moment - enjoy the fact that you are bringing a program to life. You will become an artist who can look back and say, 'I did that.'

Paul (for the GeneSys Team)

[grofaz]

 :U

Thanks Paul, I appreciate your post. It will be great to have some documentation like what you posted here included in the package. Good stuff!

[frktons]

This was the first topic I read  :P

Very well done friends  :U

I am going to spend some of my spare time surfing this section of the
forum and learn, ask, post something.  :P