News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Script support for 5 code generation tasks

Started by hutch--, October 08, 2016, 09:37:38 PM

Previous topic - Next topic

hutch--

QE has for a long time had its own scripting engine, mainly dedicated to code generation. In the attached ZIP file are 5 scripts in a directory "Script64" which needs to be copied into the main MASM32 directory then open the text file "important_read_this.txt" to insert the correct calling code into the QE menu editor so that the options appear on the QE menu. If you configure this correctly you can just select from the menu and of 5 options to build working skeleton code in a directory of your choice.

The script choice is as follows.

Console Template Script
Dlg Template Script
Edit Template Script
Minimum Window Script
DLL Skeleton Script


If you have any problems, let me know, feedback is useful.






hutch--

Here is a collection of what the templates for applications produces. There is also an extra script that creates a template with a left side toolbar in the root directory of the zip file.

jj2007

Builds fine, but what is the purpose of the ret?
somevar REAL8 123.456
entry_point proc

    conout "Howdy, your new console template here.",lf,lf
    waitkey

    invoke ExitProcess, 0, somevar

    ret   ; why?

entry_point endp

hutch--

 :biggrin:

Bad habit of writing complete code.  :P None the less the 0C3h has not blown out the assembled size of the executable. I am much more interested in /LARGEADDRESSAWARE than I am in saving bytes.  :P

GuruSR

Quote from: jj2007 on October 12, 2016, 11:55:14 PM
Builds fine, but what is the purpose of the ret?

    ret   ; why?

entry_point endp


Simple, you can actually have 2 entry points into the same segment of code, say you had a function that printed a welcome message and right after it, printed software/version info.  Then you could let the code go into the next entry point and continue to it, so the first one would print the welcome message and then continue to the second entry point which would be used to print the software/version number.  Can't say I've never done this before.  It's a general practice in most cases, to have a pre-function on most functions.  Like a "Pretty a number", where you give the number to a function, it converts it out to a string, then sets the pattern for it in a second string and continues to the second entry point that takes the string, formats it to the pattern and exits.  You can easily use the second part without the first, someone enters a number say 1000 and your pattern is ###,###,###,###(.##) and it would format the number to "1,000" in the field.  And your calculations could pass a value off to the first function that converts it to the string and uses the default pattern for numbers.  So, if you don't ret, expect the thread to keep running code.

GuruSR.
Learned 68k Motorola Asm instruction set in 30 minutes on the way to an Amiga Developer's Forum meeting.
Following week wrote a kernel level memory pool manager in 68k assembler for fun.

rrr314159

But, GuruSR, in this case we're dealing with two exit points, not two entry points. The second one (ret) will never be executed, unless you want to dive into the code just after the ExitProcess invoke. Without a label there, that would be very questionable programming practice.

But I must admit, I also put a ret after ExitProcess! It just doesn't look right without it. Old habits die hard.
I am NaN ;)