Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
en:multiasm:papc:chapter_6_9 [2025/12/14 17:44] – [Pure Assembler Applications for Windows] pczekalskien:multiasm:papc:chapter_6_9 [2025/12/14 17:58] (current) – [Pure Assembler Applications for Windows] pczekalski
Line 13: Line 13:
 It is possible to write an application for Windows solely in assembler. While the reason to do it is doubtful, some hints presented below, such as calling system functions, may be helpful. It is possible to write an application for Windows solely in assembler. While the reason to do it is doubtful, some hints presented below, such as calling system functions, may be helpful.
 Calls to the Windows system functions is possible via classical ''call'', and require explicit declaration of the functions as external, and linking ''kernel32.lib'' and ''user32.lib''. Use of ''legacy_stdio_definitions.lib'' and ''legacy_stdio_wide_specifiers.lib'' may be helpful when using advanced ''stdio'' functions and enumerations.\\ Calls to the Windows system functions is possible via classical ''call'', and require explicit declaration of the functions as external, and linking ''kernel32.lib'' and ''user32.lib''. Use of ''legacy_stdio_definitions.lib'' and ''legacy_stdio_wide_specifiers.lib'' may be helpful when using advanced ''stdio'' functions and enumerations.\\
-A common approach to development is to start with a stub command-line C++ application and manually convert it to assembler requirements. Visual Studio Community ([[https://visualstudio.microsoft.com/vs/community/]]) is a free version and the first choice for developing apps written in pure assembler, for Windows OSes.+A common approach to development is to start with a stub command-line C++ application and manually convert it to assembler requirements. Visual Studio Community ([[https://visualstudio.microsoft.com/vs/community/]]) is a free version and the first choice for developing apps written in pure assembler, for Windows OSes. A great feature of such an integrated IDE is that, properly configured, it enables debugging of assembler code, even in high-level integration scenarios.
  
 A template of the typical pure assembler, command-line application for Windows is as follows: A template of the typical pure assembler, command-line application for Windows is as follows:
 <code asm> <code asm>
-.data 
- 
- 
- 
- 
 ... ...
 .code  .code 
Line 40: Line 35:
 </code> </code>
  
-The name ''hello_world_asm'' is of choice but needs to be informed to the compiler as so-called entry point.+The name ''hello_world_asm'' must be specified to the compiler as the so-called entry point. 
 + 
 +Calling system functions, such as the system message box, requires understanding the arguments passed to them. As there is no direct assembler help, documentation of the Windows system API for C++ is helpful. 
 +Code below presents the necessary components of the assembler app to call system functions (library includes are configured on the project level): 
 +<code adm> 
 +.data 
 +STD_INPUT_HANDLE = -10 
 +STD_OUTPUT_HANDLE = -11 
 +STD_ERROR_HANDLE = -12 
 + 
 +handler dq 0 
 +hello_msg db "Hello world",
 +info_msg  db "Info",
 +... 
 +includelib          kernel32.lib  
 +includelib          user32.lib  
 +EXTERN MessageBoxA: PROC 
 +... 
 + 
 + WINUSERAPI int WINAPI MessageBoxA( 
 +;  RCX =>  _In_opt_ HWND hWnd, 
 +;  RDX =>  _In_opt_ LPCSTR lpText, 
 +;  R8  =>  _In_opt_ LPCSTR lpCaption, 
 +;  R9  =>  _In_ UINT uType); 
 +mov rcx, handler 
 +mov rdx, offset hello_msg 
 +mov r8,  offset info_msg 
 +mov r9,  0 ; 0 is MB_OK 
 +and rsp, not 8  
 +call MessageBoxA 
 +... 
 +</code> 
 +The majority of standard library functions accept ASCII strings and must be terminated with a 0 byte (0 is a value), so they do not require passing the string length. 
 +The ''and rsp, not 8'' instruction causes stack alignment to be required before application leave or before following system function calls. 
 ==== Dynamic memory management considerations ==== ==== Dynamic memory management considerations ====
 Using dynamic memory management at the level of the assembler code is troublesome: allocating and releasing memory require calls to the hosting operating system. It is possible, but complex. Moreover, there is no dynamic, automated memory management, as in .NET, Java, and Python, so the developer is on their own, similar to programming in C++. For this reason, it is common to allocate adequate memory resources on the high-level code, e.g., the GUI front-end and pass them to the assembler code as pointers. Note, however, that for some higher-level languages, such as C#, it is necessary to follow a strict pattern to ensure correct and persistent memory allocation, as described in the following chapters. Using dynamic memory management at the level of the assembler code is troublesome: allocating and releasing memory require calls to the hosting operating system. It is possible, but complex. Moreover, there is no dynamic, automated memory management, as in .NET, Java, and Python, so the developer is on their own, similar to programming in C++. For this reason, it is common to allocate adequate memory resources on the high-level code, e.g., the GUI front-end and pass them to the assembler code as pointers. Note, however, that for some higher-level languages, such as C#, it is necessary to follow a strict pattern to ensure correct and persistent memory allocation, as described in the following chapters.
en/multiasm/papc/chapter_6_9.txt · Last modified: 2025/12/14 17:58 by pczekalski
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0