Pelles C forum

http://www.smorgasbordet.com/pellesc/download.htm

/Pelle

Thanks
What features we should to test first ?

What a happy day :)

C:\code\PellesC13b\Include\Win\winbase.h(23): fatal error #1035: Can't find #include file <fileapifromapp.h>.

Hi Pelle,

I share the happiness of Timo. Many thanks for the release candidate. I will test it.

OMG - Welcome back!
Sequestered to make the new version - We were all concerned.

Thanks for #13 will test shortly

John Z

Hi Pelle!

Very happy to learn that you're alive and (presumably) well and still interested in this project that you started 20+ years ago.
Our cohort grows smaller each year but our friends have come to rely on us being there for them.

I will test v13-RC1 and report my findings.

Quote from: TimoVJL on April 02, 2025, 02:34:55 PMThanks
What features we should to test first ?

What a happy day :)

C:\code\PellesC13b\Include\Win\winbase.h(23): fatal error #1035: Can't find #include file <fileapifromapp.h>.

Confirmed:

C:\PellesC\Include\Win\winbase.h(23): fatal error #1035: Can't find #include file <fileapifromapp.h>.

Woot, great news! I, as well as many others, were wondering what had happened to you and if we'd ever see a new version, I'm so glad it's here! Testing now.
Thanks, Pelle!

Happy Times  ;D

Glad to hear from you Pelle and that V13 candidate is here.
I will download and start testing

Hi Pelle!

I share the happiness of other users. Very good to hear from you again!

Thank you for this new version. I will be testing it soon.

Marco

Quote from: TimoVJL on April 02, 2025, 02:34:55 PMThanks

Thank you.

Quote from: TimoVJL on April 02, 2025, 02:34:55 PMWhat features we should to test first ?

Well... apparently the Windows API include files! They are all new...
Otherwise I don't really know. Rebuilding all tools with the most recent tools tend to reveal all major/obvious bugs. It's the lesser used features that needs testing, I guess...

Quote from: MrBcx on April 02, 2025, 04:26:01 PMVery happy to learn that you're alive and (presumably) well and still interested in this project that you started 20+ years ago.
Our cohort grows smaller each year but our friends have come to rely on us being there for them.

Cool, thanks.
My interest has certainly gone down a bit in recent years. I wanted to finish the C23 version, since I hate leaving projects unfinished, but it's hard to be interested in "C2Y" (the next C standard). We don't even have much of "Wintel" anymore, so I'm not sure where to focus now...

Quote from: MrBcx on April 02, 2025, 04:37:01 PMConfirmed:
C:\PellesC\Include\Win\winbase.h(23): fatal error #1035: Can't find #include file <fileapifromapp.h>.

"...so you wanted <fileapifromapp.h> to be included in the Setup? Why didn't you say so...?"

Now in Release Candidate #2 (from the same place) ...

Quote from: Pelle on April 02, 2025, 08:46:09 PM

Quote from: MrBcx on April 02, 2025, 04:37:01 PMConfirmed:
C:\PellesC\Include\Win\winbase.h(23): fatal error #1035: Can't find #include file <fileapifromapp.h>.

"...so you wanted <fileapifromapp.h> to be included in the Setup? Why didn't you say so...?"

Now in Release Candidate #2 (from the same place) ...

That's more like it! 

I completed test building hundreds of apps, large and small, CLI, Desktop, and DLL and have encountered zero issues.

Thanks Pelle!

Quote from: MrBcx on April 02, 2025, 10:02:01 PMThat's more like it! 
I completed test building hundreds of apps, large and small, CLI, Desktop, and DLL and have encountered zero issues.
Thanks Pelle!

Great, Thanks!  :)

poasm 13
with INVOKE

error: Invalid use of 'MessageBox'.
MessageBoxA PROTO :QWORD,:QWORD,:QWORD,:DWORD
MessageBox EQU MessageBoxA
something have changed ?

error: Invalid address specification.
MessageBoxA PROTO :QWORD,:QWORD,:QWORD,:DWORD
MessageBox EQU <MessageBoxA>


Quote from: TimoVJL on April 03, 2025, 09:18:31 AMsomething 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:
MessageBox EQU <MessageBoxA>
I think some errors comes from the (late) addition of OPTION RIPRELATIVE ...

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.

Quote from: Vortex on April 03, 2025, 11:15:53 AMKindly, 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)

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 (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.

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

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

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


Quote from: sunshine on April 03, 2025, 01:52:26 PMCould 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...

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

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.

Hi Timo,

This text equate is not correct :

MessageBox EQU MessageBoxA
The Masm reference reads :

QuoteTEXTEQU

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 :

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

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


Time to update pope.exe to point new folder or put it to own folder ;)
Windows Registry Editor Version 5.00

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

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.
 ;D  ;D  ;D  ;D  ;D  ;D  ;D  ;D

Quote from: sunshine on April 03, 2025, 01:52:26 PM

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().

Quote from: Phil on April 04, 2025, 01:25:16 PMNext Time tell us you will not be here.

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

Quote from: TimoVJL on April 04, 2025, 11:51:12 AMTime 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...

Quote from: Pelle on April 04, 2025, 02:20:54 PM

Quote from: sunshine on April 03, 2025, 01:52:26 PM

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:
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`:
push rbx
sub rsp,20
...
jmp _Exit
add rsp,20
pop rbx
ret
I think the `jmp _Exit` here cause rsp to be misaligned.

Quote from: sunshine on April 04, 2025, 02:59:44 PMSo, the `jmp exit` in main has no problem.

Then we agree.

Quote from: sunshine on April 04, 2025, 02:59:44 PMBut 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...

Yes.

I found pocc can automatically use JMP to replace CALL if the caller is a simple wrapper:
void close(void) {
    CloseHandle(hFile);
}
asm:
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.

I agree with everyone else about the return. We have been worried!  ;)

Project properties for linker don't have LARGEADDRESSAWARE:NO advanced option

To avoid that.drectve SEGMENT
db "-largeaddressaware:no "
.drectve ENDS


Hi Timo,

Working on your example, I am receiving an error message :

;hello64x2.asm

includelib "kernel32.lib"

tp_ExitProcess typedef proto :dword
externdef __imp_ExitProcess : ptr tp_ExitProcess
ExitProcess equ <__imp_ExitProcess>

.drectve SEGMENT
db "-largeaddressaware:no "
.drectve ENDS

.code

mainCRTStartup PROC

    sub rsp, 28h
    invoke ExitProcess, 0

mainCRTStartup ENDP

END
E:\PellesC\sample>\PellesC\bin\poasm.exe /AAMD64 Test.asm
E:\PellesC\sample\Test.asm(22): fatal error: Error reading from file 'E:\PellesC\sample\Test.asm'.
The source code is a plain ANSI text file. Poasm Version : 13.00.1

Quote from: TimoVJL on April 05, 2025, 07:42:29 AMProject properties for linker don't have LARGEADDRESSAWARE:NO advanced option

Yeah, I guess. A bit of work though with multiple (translation) dialogs, help-file, and revised logic. Will take some time...

Hello,

About the error message :

E:\PellesC\sample\Test.asm(22): fatal error: Error reading from file 'E:\PellesC\sample\Test.asm'.
Adding a blank line after the END statement is solving the issue.

Quote from: Vortex on April 06, 2025, 12:49:06 PMHello,

About the error message :

Code Select Expand

E:\PellesC\sample\Test.asm(22): fatal error: Error reading from file 'E:\PellesC\sample\Test.asm'.
Adding a blank line after the END statement is solving the issue.

You get this error when the last line is not properly terminated (no line-break).
Producing a better diagnostic would mean special handling, and more code. This seems silly considering it's uncommon, usually only happening with files from (very) old editors.