"Sorry guys, we don't support 7/8 so ALL SOFTWARE you know will stop working at all because we change the rule to call winapi. Install our new windows and wait for developers to recreate their soft for our new stupid rule"

DimonSoft wrote:

Sorry, I was too focused on the parameter description and forgot to take a look at the function prototype itself which declares the only parameter as a pointer to const, so the question now is who would change the structure contents during the function call if the function itself is not supposed to?

It depends on the implementation of the API functions and the presence of an interception function.

DimonSoft wrote:

Yep. But my point was that storing and then taking the hInstance value from some WNDCLASSEX is a bad idea from the logical point of view in the first place.

And why store it at all, when it is possible to call GetModuleHandle(NULL) {GetWindowLong(hWnd,GWL_HINSTANCE) / GetClassLong(hWnd, GCL_HINSTANCE) } at any time. And WNDCLASS(EX) can be read by calling GetClassInfo(Ex).

If an interception function changes the behaviour in a way that is not compatible with the documentation of the original function, it is broken by definition and might render broken most programs that use the function. Function prototype is a contract, when one of the parties (caller/callee) breaks the rules the whole game is broken anyway, it’s just a matter of time to notice. If what’s documented for an OS function is broken, it’s not an application programmer’s fault.

Well, GetModuleHandle(NULL) may even be replaced with a literal, say, if one registers a class from an EXE, not a DLL, and it’s a 32-bit executable. For DLLs one still needs to store its hInstance somewhere since knowing the modules name to pass to GetModuleHandle gets trickier in such cases.

  format PE64 GUI DLL
  entry DLLEntry

. . .

section '.text' code . . .
DLLEntry:
  . . .

anyDllFunc:
   lea rax, [DLLEntry]
   xor ax, ax                   ;  rax = hInstance
    

GetWindowLong and GetClassLong need a window to be created in the first place. And using them to retrieve hInstance is just another step towards attaching module-global value (hInstance) to particular window/window class. It definitely works, but from the architectural point of view it might only be OK for a few scenarios. When the number of windows created/classes registered becomes bigger it might create a mess in the project. Reading the whole WNDCLASSEX back to just get the value of a single field looks even less promising.

OffTop: You're right. This is what I am regularly offered in the Windows Update Center.

Quote:

OffTop: You're right. This is what I am regularly offered in the Windows Update Center.

It is not about some functionality bugs, call rules about ALL functionality, TOTALLY. To change this they need something most global like evolution from 32bit to 64bit. You will never receive that changes in Update Center, you don't understand what you talking about. That rules is fundamental basis, even if all 32bit winapi recreated/recompilled to true 64bit, that I never believe. It is too late to change the rule when tons of code already created for that.

They may provide some new sort of call rules for some new functions, theoretically. Name it like new generation or something this way. But old will work as is.

Just use it like that:
CS_HREDRAW = 2
CS_VREDRAW = 1

CS_HREDRAW equ 2
CS_VREDRAW equ 1
    

CS_HREDRAW fix 2
CS_VREDRAW fix 1
    

define CS_HREDRAW 2
define CS_VREDRAW 1
    

label CS_HREDRAW at 2
label CS_VREDRAW at 1
    

facepalm
People just run away from the FASM after your advice. IT IS NOT THE BASIC! Can you just read what he asking about? Do you even know what CS_HREDRAW is? So why you make it such complicated? For me it was enough to see how he trying to use it to guess what exactly he need.

Code:

        format PE64 GUI 6.0
        entry label_start

; include 'win64w.inc'

section '.idata' import data readable writeable
;  library kernel32,'KERNEL32.DLL',\
;          user32,  'USER32.DLL'

        dd RVA kernel32.lookup, 0, 0, RVA kernel32.label, RVA kernel32.address
        dd RVA user32.lookup, 0, 0, RVA user32.label, RVA user32.address
        dd 0, 0, 0, 0, 0
kernel32.label          db 'KERNEL32.DLL', 0
                        rb RVA $ and 1
user32.label            db 'USER32.DLL', 0
                        rb RVA $ and 1

;  import kernel32,\
;         GetModuleHandle,'GetModuleHandleA',\
;         ExitProcess,'ExitProcess'
kernel32.lookup:
                        dq RVA GetModuleHandle.label
                        dq RVA ExitProcess.label
                        dq 0
kernel32.address:
  GetModuleHandle       dq RVA GetModuleHandle.label
  ExitProcess           dq RVA ExitProcess.label
                        dq 0
GetModuleHandle.label   dw 0
                        db 'GetModuleHandleA', 0
                        rb RVA $ and 1
ExitProcess.label       dw 0
                        db 'ExitProcess', 0
                        rb RVA $ and 1

;  import user32,\
;         RegisterClassEx, 'RegisterClassExA',\
;         CreateWindowEx, 'CreateWindowExA',\
;         DefWindowProc, 'DefWindowProcA',\
;         GetMessage, 'GetMessageA',\
;         TranslateMessage, 'TranslateMessage',\
;         DispatchMessage, 'DispatchMessageA',\
;         ShowWindow, 'ShowWindow',\
;         PostQuitMessage, 'PostQuitMessage',\
;         LoadIcon, 'LoadIconA',\
;         LoadCursor, 'LoadCursorA'
user32.lookup:
                        dq RVA RegisterClassEx.label
                        dq RVA CreateWindowEx.label
                        dq RVA DefWindowProc.label
                        dq RVA GetMessage.label
                        dq RVA TranslateMessage.label
                        dq RVA DispatchMessage.label
                        dq RVA ShowWindow.label
                        dq RVA PostQuitMessage.label
                        dq RVA LoadIcon.label
                        dq RVA LoadCursor.label
                        dq 0
user32.address:
RegisterClassEx         dq RVA RegisterClassEx.label
CreateWindowEx          dq RVA CreateWindowEx.label
DefWindowProc           dq RVA DefWindowProc.label
GetMessage              dq RVA GetMessage.label
TranslateMessage        dq RVA TranslateMessage.label
DispatchMessage         dq RVA DispatchMessage.label
ShowWindow              dq RVA ShowWindow.label
PostQuitMessage         dq RVA PostQuitMessage.label
LoadIcon                dq RVA LoadIcon.label
LoadCursor              dq RVA LoadCursor.label
                        dq 0
RegisterClassEx.label   dw 0
                        db 'RegisterClassExA', 0
                        rb RVA $ and 1
CreateWindowEx.label    dw 0
                        db 'CreateWindowExA', 0
                        rb RVA $ and 1
DefWindowProc.label     dw 0
                        db 'DefWindowProcA', 0
                        rb RVA $ and 1
GetMessage.label        dw 0
                        db 'GetMessageA', 0
                        rb RVA $ and 1
TranslateMessage.label  dw 0
                        db 'TranslateMessage', 0
                        rb RVA $ and 1
DispatchMessage.label   dw 0
                        db 'DispatchMessageA', 0
                        rb RVA $ and 1
ShowWindow.label        dw 0
                        db 'ShowWindow', 0
                        rb RVA $ and 1
PostQuitMessage.label   dw 0
                        db 'PostQuitMessage', 0
                        rb RVA $ and 1
LoadIcon.label          dw 0
                        db 'LoadIconA', 0
                        rb RVA $ and 1
LoadCursor.label        dw 0
                        db 'LoadCursorA', 0
                        rb RVA $ and 1

section '.data' data readable writeable
  s_winTitle db "My program's window title", 0
  s_winClass db 'FASMWIN64', 0
  ;wc WNDCLASSEX ? ; struct - macro too
  wc:
  wc.cbSize             dd ?
  wc.style              dd ?
  wc.lpfnWndProc        dq ?
  wc.cbClsExtra         dd ?
  wc.cbWndExtra         dd ?
  wc.hInstance          dq ?
  wc.hIcon              dq ?
  wc.hCursor            dq ?
  wc.hbrBackground      dq ?
  wc.lpszMenuName       dq ?
  wc.lpszClassName      dq ?
  wc.hIconSm            dq ?
  wc.Length = $ - wc
  ; msg MSG ? ; struct - macro too
  msg:
  msg.hwnd              dq ?
  msg.message           dd ?
                        dd ?
  msg.wParam            dq ?
  msg.lParam            dq ?
  msg.time              dd ?
  msg.pt.x              dd ?
  msg.pt.y              dd ?
  l_hWnd dq ?
  l_hInstance dq ?

section '.text' code readable writeable executable
  label_start:
    xor rcx, rcx        ; instead: mov rcx, 0
    push rcx            ;          push rax
    call [GetModuleHandle]
    add rsp, 8
    mov [l_hInstance], rax
    mov [wc.hInstance], rax
    mov [wc.cbSize], wc.Length;sizeof.WNDCLASSEX
    mov [wc.style], 3; CS_HREDRAW or CS_VREDRAW
    mov [wc.lpfnWndProc], procWnd
    mov [wc.cbClsExtra], 0
    mov [wc.lpszClassName], s_WinClass
    lea rcx, [wc]       ; instead: mov rcx, wc
    push rcx
    call [RegisterClassEx]
    add rsp, 8
    ;invoke CreateWindowEx, 0, s_WinClass, s_WinTitle, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 640, 480, NULL, NULL, [l_hInstance], NULL
    push 0      ; NULL
    push [l_hInstance]
    push 0      ; NULL
    push 0      ; NULL
    push 480
    push 640
    push 8000h  ; CW_USEDEFAULT
    push 8000h  ; CW_USEDEFAULT
    mov r9, 000CF0000h; WS_OVERLAPPEDWINDOW
    lea r8, [s_WinTitle] ; instead: mov r8, s_WinTitle
    lea rdx, [s_WinClass]; instead: mov rdx, s_WinClass
    xor rcx, rcx; instead: mov rcx, 0
    sub rsp, 32
    call [CreateWindowEx]
    add rsp, 32+64
    mov [l_hWnd], rax
    ;invoke ShowWindow, [l_hWnd], SW_SHOW
    mov rdx, 5  ; SW_SHOW
    mov rcx, rax
    sub rsp, 16
    call [ShowWindow]
    add rsp, 16
  label_msg_loop:
    ;invoke GetMessage, msg, NULL, 0, 0
    xor r9, r9          ; instead: mov r9, 0
    xor r8, r8          ; instead: mov r8, 0
    xor rdx, rdx        ; instead: mov rdx, 0
    lea rcx, [msg]      ; instead: mov rcx, msg
    sub rsp, 32
    call [GetMessage]
    add rsp, 32
    or rax, rax
    je label_end_prog
    ;invoke TranslateMessage, msg
    lea rcx, [msg]      ; instead: mov rcx, msg
    push rcx
    call [TranslateMessage]
    add rsp, 8
    ;invoke DispatchMessage, msg
    lea rcx, [msg]      ; instead: mov rcx, msg
    push rcx
    call [DispatchMessage]
    add rsp, 8
    jmp label_msg_loop
    
  label_end_prog:
    ;invoke ExitProcess, [msg.wParam]
    mov rcx, [msg.wParam]
    push rcx
    call [ExitProcess]
    add rsp, 8
    
;proc procWnd uses rbx rsi rsi, hWnd, msg, wParam, lParam
procWnd:
  push rbp
  mov rbp, rsp
  push rbx
  push rsi
  push rdi      ; instead: rsi
  mov [rbp+16], rcx
  mov [rbp+24], rdx
  mov [rbp+32], r8
  mov [rbp+40], r9
  cmp dword [rbp+24], 2; WM_DESTROY
  je label_destroy_wnd
  ;invoke DefWindowProc, [hWnd], [msg], [wParam], [lParam]

; macro generated, redundant
  ; mov r9, [rbp+40]
  ; mov r8, [rbp+32]
  ; mov rdx, [rbp+24]
  ; mov rcx, [rbp+16]

  sub rsp, 32
  call [DefWindowProc]
  add rsp, 32
  jmp label_finish
  
  label_destroy_wnd:
    ;invoke PostQuitMessage,0
    xor rcx, rcx        ; instead: mov rcx, 0
    push rcx
    call [PostQuitMessage]
    add rsp, 8
    
  label_finish:
    ;ret - macro too
    lea rsp, [rbp-24]
    pop rdi     ; instead: rsi
    pop rsi
    pop rbx
    pop rbp
    retn
;endp
    

sorry for the typos, I typed in the browser

ADD: it seems that everything has been expanded

; Define our program type/format
format pe console
; Define our starting point for executing our program
entry label_start
; Import the DLL functions
section '.idata' import data readable writeable
  ; Call the import process for the DLL and defined functions
  dd RVA msvcrt, 0, 0, dll_msvcrt, msvcrt_functions
  ; Import the defined functions
  msvcrt:
    dq RVA func_printf
    dq RVA func_system
    dq RVA func_exit
    dq 0
  ; Set our usable functions for coding later
  msvcrt_functions:
    printf dq RVA func_printf
    system dq RVA func_system
    exit dq RVA func_exit
    dq 0        
  ; Import the required DLL
  dll_msvcrt db 'msvcrt.dll', 0
             rb RVA $ and 1
  ; Define the functions to import from the DLL's list of functions
  func_printf dw 0
              db 'printf', 0
              rb RVA $ and 1
  func_system dw 0
              db 'system', 0
              rb RVA $ and 1
  func_exit dw 0
            db 'exit', 0
            rb RVA $ and 1
; Define our variables
section '.data' data readable writeable
  mess db 'Hello, world!', 0
  mess_len equ $-mess
; Execute the program (program's actual code)
section '.text' code readable writable executable
  label_start:
    push ebp
    mov ebp, esp
    ; This line invokes the write command which is defined by value 4
    sub ebp, 4
    mov dword [esp], mess
    ; Print's the message on screen
    call [printf]
    mov dword [esp], 0
    ; Exit the program
    call [exit]    

avidichard, just open examples under FASM folder. Some simple templates has to be there.

I completely agree, but no one is talking about a violation. I want to point out to you once again that even in the example from MSDN, this structure is only temporary, does not require saving anywhere and should not contain up-to-date information on the class registered with it at any time after its application.

How much harder is it?

; Define our program type/format
format pe console
; Define our starting point for executing our program
entry label_start
; Set our variables
section '.idata' import data readable writeable
  ; Import our DLL file
  dd rva msvcrt.functions
  dd 0
  dd 0
  dd rva msvcrt.dll
  dd rva msvcrt.functions
  dd 5 dup(0)
  msvcrt.dll db 'msvcrt.dll', 0
  ; Import the functions
  printf.function dw 0
                  db 'printf', 0
  exit.function dw 0
                db 'exit', 0
  msvcrt.functions:
    printf dq rva printf.function
    exit   dq rva exit.function
           dq 0
; Define our variables
section '.data' data readable writeable
  mess db 'Hello, world!', 0
; Execute the program (program's actual code)
section '.text' code readable writable executable
  label_start:
    ; Print's the message on screen
    push mess
    call [printf]
    push 0
    ; Exit the program
    call [exit]    

; Define our program type/format
format pe console
; Define our starting point for executing our program
entry label_start
; Set our variables
section '.idata' import data readable writeable
  ; Import our DLL file
  dd rva msvcrt.functions
  dd 0
  dd 0
  dd rva msvcrt.dll
  dd rva msvcrt.functions
  dd 5 dup(0)
  msvcrt.dll db 'msvcrt.dll', 0
  ; Import the functions
  printf.function dw 0
                  db 'printf',0
  getch.function dw 0
                 db '_getch',0
  exit.function dw 0
                db 'exit',0
  msvcrt.functions:
    printf dd rva printf.function
    getch  dd rva getch.function
    exit   dd rva exit.function
           dd 0
; Define our variables
section '.data' data readable writeable
  key  db '%s',0
  mess db 'Hello, world!', 0
; Execute the program (program's actual code)
section '.text' code readable writable executable
  label_start:
    ; Print's the message on screen
    push mess
    push key
    call [printf]
    call [getch]
    push 0
    ; Exit the program
    call [exit]     

Now, I really don't know what RVA does and you seem to use VERY often. I tried to comment this as I understood it from your example. But yeah, I got this illegal intruction. I also followed the tutorial I found here:

And I kind of lost track of all of what other people were talking about in this thread. I even saw someone talk about cell phones which is way outside my question.

My initial correction was about the probability of WNDCLASSEX having been changed. As for storing or not storing it, it a matter of a particular task. Generally people don’t tend to change their window classes a lot, so there’s no real winner strategy.

But, once again, my point was that saving hInstance in some WNDCLASSEX and taking it from there is not a recommended way to go. No matter whether the structure is passed from the stack of from the global variable.

Well, nobody said it really is noticeably harder, I just gave an example of a project where a simple $ - rva $ expression works at any line after the format directive. The difference is that EXEs are usually loaded at the base address specified in the headers while DLLs are not guaranteed to, so for DLLs the trick is one step longer as it requires the constants being fixed up by the loader, plus additional records in the fixups section. Not that it really is hard.

call label
label:
  pop rax
  sub rax, rva label
    

I tried again using another example I followed and I still have the illegal instruction on "call [printf]". If I remove the square brackets, then, it compiles. BUT, it returns nothing in the command line prompt, the message never appears.

or rax, -1
dw 0x15FF                ; This and the next lines will be decoded into a command:
dd my_label-$-4      ; call [my_label]
mov [my_var], rax
dw 0xFE74                ; jz $   (preventing the execution of data in the "my_label" variable)
; but we completely suspend the current flow of command execution
my_label  dq my_function
my_function:
  xor rax, rax
  db $C3                     ; retn

my_var  dq ?    ; my_var = 0
    

or eax, -1
dw 0x15FF                ; This and the next lines will be decoded into a command:
dd my_label-$-4      ; call [my_label]
mov [my_var], eax
dw 0xFE74                ; jz $   (preventing the execution of data in the "my_label" variable)
; but we completely suspend the current flow of command execution
my_label  dd my_function
my_function:
  xor eax, eax
  db $C3                     ; retn

my_var  dd ?    ; my_var = 0    

or rax, -1
db 0xE8                ; This and the next lines will be decoded into a command:
dd my_label-$-4      ; call my_label    <- error
mov [my_var], rax
dw 0xFE74                ; jz $   (preventing the execution of data in the "my_label" variable)
; but we completely suspend the current flow of command execution
my_label  dq my_function  ; Even if you try to imagine the possible value of this variable: 0x000000007FF800CC
; The lowest byte will be executed as an int 3 command, and further execution will be stopped.
; But I just came up with the value of this variable (to simplify understanding).
; And you will be very lucky if the processor can chew the data that the address consists of without any problems.
my_function:
  xor rax, rax
  db $C3                     ; retn

my_var  dq 2    ; my_var = 2
    

U work in 32bit mode.
Change dq to dd:

; Print's the message on screen
push mess
call [printf]
push 0
; Exit the program
call [exit]    

; Print's the message on screen
push ebp
mov ebp, esp
sub esp, 4
mov dword[esp], mess
call [printf]
mov dword[esp], 0
; Exit the program
call [exit]    

Overclick gave you a working example, but again he was too lazy to explain what the error was in your actions. When you remove the brackets, you are not calling a function whose address is in a variable, but this variable itself. Then the value of this variable begins to be decoded as commands to the processor. In the assembly language, there is no distinction between commands and data, but there are hardware limitations that do not allow explicitly declared data to start executing. Although if you mix code and data in one section, you may start executing data unintentionally. For example:

xor esp, esp
sub esp, 4
lea esp, [mess]
push esp
call [printf]
xor esp, esp
call [exit]    

; Import our DLL file
label_dll_import:
  dd rva msvcrt_functions
  dd 0
  dd 0
  dd rva msvcrt_dll
  dd rva msvcrt_functions
  dd 5 dup(0)
msvcrt_dll db 'msvcrt.dll', 0
; Import the functions
label_function_import:
  printf_function dw 0
                  db 'printf', 0, 0
  exit_function dw 0
                db 'exit', 0, 0
; Define functions
msvcrt_functions:
  printf dd rva printf_function
  exit   dd rva exit_function
         dd 0    

  dd rva msvcrt_dll
  dd rva msvcrt_functions
  dd 5 dup(0)
msvcrt_dll db 'msvcrt.dll', 0    

dd rva msvcrt.functions
dd 0
dd 0
dd rva msvcrt.dll
dd rva msvcrt.functions
dd 5 dup(0)    

dd rva msvcrt.functions, 0, 0, rva msvcrt.dll, rva msvcrt.functions
dd 0, 0, 0, 0, 0    

dd rva msvcrt.functions, 0, 0, rva msvcrt.dll, rva msvcrt.functions, 0, 0, 0, 0, 0
; OR
dd rva msvcrt.functions, 0, 0, rva msvcrt.dll, rva msvcrt.functions, 5 dup(0)    

I did find the "%s" push in a few examples and you also supplied it. But without it, the program does run. So is the "push '%s'" really necessary? and if so, why?

printf("My message %s, %2d-%2d-%4d", "Hello!", 13, 9, 2021);    

push ebp
mov ebp, esp
push 2021
push 9
push 13
push my_message.hello
push format_string
call [printf]
mov esp, ebp
...

section '.data' ...
format_string db 'My message %s, %2d-%2d-%4d', 0
my_message.hello  db 'Hello!', 0    

For such a small program, I am very impressed and I do love FASM for it's capacity and simplicity compared to MASM, NASM and YASM.

xor esp, esp ;this will immediately corrupt the pointer to the top of the stack and should lead to an error at the first access to the address 0.
sub esp, 4
lea esp, [mess] ; <-- *
push esp
call [printf]
xor esp, esp ; error
call [exit]

Quote:

dd rva label_msvcrt.functions
dd 0
dd 0
dd rva msvcrt.dll
dd rva msvcrt.functions
dd 5 dup(0)

I know this is also the same:

Code:

dd rva msvcrt.functions, 0, 0, rva msvcrt.dll, rva msvcrt.functions
dd 0, 0, 0, 0, 0    

But could these also be valid?

Code:

dd rva msvcrt.functions, 0, 0, rva msvcrt.dll, rva msvcrt.functions, 0, 0, 0, 0, 0
; OR
dd rva [b]label_msvcrt.functions[/b], 0, 0, rva msvcrt.dll, rva msvcrt.functions, 5 dup(0)    

Would those still work?

dd rva label_msvcrt.functions,\
   0,\
   0,\
   rva msvcrt.dll,\
   rva msvcrt.functions,\
   5 dup(0)    

struc PE32.IMPORT_SECTION.LIBRARY LibName, RvaArray, NamesArray, TimeStamp, FwdChain {
  .Names  dd 0+NamesArray
  .TimeStamp dd 0+TimeStamp
  .Chain dd 0+FwdChain
  .Library  dd 0+LibName
  .Functions dd 0+RvaArray
}
mscvrt PE32.IMPORT_SECTION.LIBRARY rva mscvrt.lib_name, rva mscvrt.functions, rva mscvrt.names;, 0, 0
end_empty PE32.IMPORT_SECTION.LIBRARY; 0,0,0,0,0
    

Or something like that. I'm sure this will need to be corrected, but I am just wondering how those lines could be implemented and which one would be considered the fastest, althout it's a simple print request so optimising is not going to show that much. I also would love more details, NOOB vocabulary explanation on the "rva" because I did not find anything comprehenssive for me yet and I did search. The only logical explanation I seen to understand is that "rva" returns the value of a label content but I think I am pretty much off with this understanding.

Also, this in the ".idata" section:
Code:

; Import our DLL file
label_dll_import:
dd rva msvcrt_functions
dd 0
dd 0
dd rva msvcrt_dll
dd rva msvcrt_functions
dd 5 dup(0)
msvcrt_dll db 'msvcrt.dll', 0
rb RVA $ and 1 alignment
; Import the functions
label_function_import:
printf_function dw 0
db 'printf', 0
rb RVA $ and 1 alignment
exit_function dw 0
db 'exit', 0
rb RVA $ and 1 alignment
; Define functions
msvcrt_functions:
printf dd rva printf_function
exit dd rva exit_function
dd 0


To me, this executes the code from up to down. does assembly stop executing the code once it meets another label? Logically, not, but practically, it actually does. for example, this portion:
Code:

dd rva msvcrt_dll
dd rva msvcrt_functions
dd 5 dup(0)
msvcrt_dll db 'msvcrt.dll', 0

format PE GUI 5.0 at 0x00400000 ; <- base address
  entry main ; <- label main = 0x000402000      / rva main = 0x00002000
section '.idata' ...
...
section '.text' ...
main:
    

the "dd rva msvcrt_dll" refers to the "msvcrt_dll db 'msvcrt.dll', 0" code which is executed, or read lower. In the case it does search for the reference and run it, once it went through the last line of the dd's "dd 5 dub(0)", it still executes the "msvcrt_dll db 'msvcrt.dll', 0" AND so on for the others bellow "msvcrt_functions" and "printf_function" and "exit_function". So I'm wondering how does the program logically treat this information? Because clearly, it does NOT run these lines of codes in the order we wrote them, it treats and executes them much differently and I'd like to know if someone can explain to me how the information coded is treated.