Release Candidate for version 13.00 is now available

[Pelle]

something have changed ?

Yes. Everything (in a sense). New MASM-mode specific expression format, only converted to the older/generic expression format after macro evaluations.

Looks like I can reproduce the problem. I will think about a fix...

EDIT:
This should be the correct form now:

Code Select Expand

MessageBox EQU <MessageBoxA>
I think some errors comes from the (late) addition of OPTION RIPRELATIVE ...

[Vortex]

Hi Pelle,

It will be my homework to read the updated manual of Pelles C, no problem. Kindly, could you mention about the amendments of the Poasm syntax? I think I will have to modify my Poasm source code archive.

[Pelle]

Kindly, could you mentioned about the amendments of the Poasm syntax? I think I will have to modify my Poasm source code archive.

Well, the thing is... it's not so much changed syntax as it is interpretation of the syntax.
The general idea is to find a more predictable internal format, where things not just happen by pure chance...

I think it's mainly about adding < and > in some places where it previously just "happened" to work without them. I also need to fix OPTION RIPRELATIVE handling for INVOKE.

I have collected many (old) X86 examples, but not so many X64 examples. If you have more (different) problems, please post them... (in a new bug thread)

[sunshine]

Hi Pelle,

I'm glad to see you back on the forum. I just tested this 13.00 RC2 version on Windows 11 24H2 and encountered *** Error code: -1073741819 *** again. Could you fix this in the 13.00 release?

We discuss this in detail in this topic, https://forum.pellesc.de/index.php?topic=11474.0

According to my analysis, `jmp _Exit`, `jmp exit` and `jmp abort` do not push the return address onto the stack, so the stack frame is not aligned to 16 bytes, which causes problems on Windows 11 24H2. Therefore, compiling and running the following three codes will encounter unhandled exceptions.

Code Select Expand

int main(int argc, char *argv[]) {
exit(0);
return 0;
}


Code Select Expand

int main(int argc, char *argv[]) {
printf("%s\n", argv[0]);
_Exit(0);
return 0;
}


Code Select Expand

int main(int argc, char *argv[]) {
printf("%s\n", argv[0]);
abort();
return 0;
}


[Pelle]

Could you fix this in the 13.00 release?

Since I basically boycott Windows 11, this seems unlikely. Sorry...

EDIT (after your EDIT): I will look at the alignment problem...

[sunshine]

Thanks. Another problem also relate to the alignment, you can test it on Windows 10.

Code Select Expand

void myAssert(void) {
    assert(0);
}

int main(int argc, char *argv[]) {
    myAssert();
}

I found that `myAssert` did not allocate its own stack frame space, but called `__crt_assert` using the CALL instruction.

[Vortex]

Hi Timo,

This text equate is not correct :

Code Select Expand

MessageBox EQU MessageBoxA
The Masm reference reads :

TEXTEQU

Assigns textitem to name. The textitem can be a literal string, a constant preceded by a %, or the string returned by a macro function.

Syntax
name TEXTEQU ⟦textitem⟧

https://learn.microsoft.com/en-us/cpp/assembler/masm/textequ?view=msvc-170

The string literal on the righ side of TEXTEQU should be enclosed between angle brackets. The correct syntax :

Code Select Expand

MessageBox EQU <MessageBoxA>
Concerning the API function names, all the TEXTEQUs found in the Masm include files are following this rule :

Code Select Expand

MessageBoxA PROTO STDCALL :DWORD,:DWORD,:DWORD,:DWORD
IFNDEF __UNICODE__
  MessageBox equ <MessageBoxA>
ENDIF


[TimoVJL]

Time to update pope.exe to point new folder or put it to own folder

Code Select Expand

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\*\shell\Open With Pope\command]
@="\"c:\\code\\bin64\\pope.exe\" %1"

[Phil]

Hi Pelle, very happy to know you are alive. Next Time tell us you will not be here. We imagined a lot of (bad_ things, at leat me.
              

[Pelle]

Code Select Expand

int main(int argc, char *argv[]) {
    exit(0);
    return 0;
}


I can't see how your first example can fail: clear a register and then jump - no stack operations involved. Stack should be properly aligned when entering main().

[Pelle]

Next Time tell us you will not be here.

Well, not everything can be perfectly planned. Sometimes life just happens... 

[Pelle]

Time to update pope.exe to point new folder or put it to own folder

Code Select Expand

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\*\shell\Open With Pope\command]
@="\"c:\\code\\bin64\\pope.exe\" %1"

OK, this should be possible to add...

[sunshine]

Code Select Expand

int main(int argc, char *argv[]) {
    exit(0);
    return 0;
}


I can't see how your first example can fail: clear a register and then jump - no stack operations involved. Stack should be properly aligned when entering main().

This time `main` is too simple, so it's optimized assembly code looks like a naked function:

Code Select Expand

xor ecx,ecx
jmp exit
ret
So, the `jmp exit` in main has no problem. But the `exit` in crt64.lib is not naked, and it jumps to `_Exit`:

Code Select Expand

push rbx
sub rsp,20
...
jmp _Exit
add rsp,20
pop rbx
ret
I think the `jmp _Exit` here cause rsp to be misaligned.

[Pelle]

So, the `jmp exit` in main has no problem.

Then we agree.

But the `exit` in crt64.lib is not naked, and it jumps to the `jmp _Exit` here cause rsp to be misaligned.

Will be solved by a recompile...

[sunshine]

Yes.

I found pocc can automatically use JMP to replace CALL if the caller is a simple wrapper:

Code Select Expand

void close(void) {
    CloseHandle(hFile);
}
asm:

Code Select Expand

mov rcx,hFile
jmp CloseHandle

But the assembly code for calling _Exit, exit, abort and assert is fixed no matter the caller is a simple wrapper or not. Please check this.