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.

Thanks Pelle!

Glad to see that things are still moving.
I don't use C as much anymore as I used to, but I have over the last decade or so send a lot of folks to this compiler, as it makes programming in plain C so much easier for most newbies than having to deal with the bloated corpses of Visual Studio or GCC...

Ralf

Quote from: Pelle on April 02, 2025, 08:39:41 PMMy 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...

If you decide not to continue updating on Pelles C at some point in the future (or Pelles C 13.0 is the final update you work on), could you make it open source?

Pelles C works well and it doesn't need constant new features. The biggest problem I see happening is future releases of Windows breaking Pelles C because of one reason or another. It's already becoming a problem. Microsoft's support for Windows 10 is ending in October and Windows 11 will be needed for official support from Microsoft.

Edit: Windows 11 Version 24H2 can be tested from within virtual machines using VirtualBox and VMware.

There are several parts of the C23 standard that I find useful but the vast majority of it isn't relevant or interesting to me. The #embed feature is interesting for example.

Quote from: CandCPlusPlus on April 09, 2025, 09:40:37 PMIf you decide not to continue updating on Pelles C at some point in the future (or Pelles C 13.0 is the final update you work on), could you make it open source?

Unlikely.

Quote from: CandCPlusPlus on April 09, 2025, 09:40:37 PMIt's already becoming a problem. Microsoft's support for Windows 10 is ending in October and Windows 11 will be needed for official support from Microsoft.

Not my problem.

Quote from: CandCPlusPlus on April 09, 2025, 09:40:37 PMEdit: Windows 11 Version 24H2 can be tested from within virtual machines using VirtualBox and VMware.

Emulation is emulation. Never the real thing.

polib don't like UTF8 def-files, have to change to ANSI format.

In version 12 I use the load last project option.  So when the IDE starts it loads the last project and all source files that were showing in the IDE Editor as a tab are showing just as they were when it was closed.

In version 13 the load last project option is checked and the last project is loaded. However the source files that were open in the Editor when the IDE was last closed are not being opened and showing in the IDE editor as they were when closed.

Have I missed checking an option or is this intentional behavior, or heaven forbid a bug?

John Z

Quote from: John Z on April 22, 2025, 04:11:48 PMHave I missed checking an option or is this intentional behavior, or heaven forbid a bug?

Looks like a bug, but I can't find any significant changes in this area since early 2020...

if *.ppx file have a locking problem, what happens ?

EDIT: delete .ppx and close project, after that are files listed in that xml-file normally ?

An example for test code:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

int __cdecl main(void)
{
HANDLE hDir;
DWORD dwRC;
PFILE_NOTIFY_INFORMATION pfni;
WCHAR fni[(sizeof(FILE_NOTIFY_INFORMATION)+1024)*1];
hDir = CreateFile(".\\", FILE_LIST_DIRECTORY,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL, OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS, NULL);
if (hDir != INVALID_HANDLE_VALUE) {
printf("start watch\n");
if (ReadDirectoryChangesW(hDir, &fni, sizeof(fni), FALSE,
FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_LAST_WRITE,
&dwRC, NULL, NULL))
{
pfni = (PFILE_NOTIFY_INFORMATION)&fni;
printf("%p [%ls]\n", (void*)pfni->NextEntryOffset, pfni->FileName);
//printf("%p [%*ls]\n", (void*)pfni->NextEntryOffset, pfni->FileNameLength, pfni->FileName);
}
CloseHandle(hDir);
}
return 0;
}


To add a bit more this is still using WIN 11 23H2 not the troublesome WIN 11 24H2. Version 12 on both OSs opened the project and the IDE starts as it was when closed.

Also all source files are in the Source file window and are accessed without any issue.

John Z

Shutting down the IDE is a complicated process: lots of events triggered, and messages sent or posted.

There is a "checkpoint" in the code after which the order of events can differ, possibly changing the result somewhat. If I move the saving of workspace windows before this point, the result seems more predictable (here on Windows 10).

Interesting:

Quote from: TimoVJL on April 22, 2025, 08:44:09 PMEDIT: delete .ppx and close project, after that are files listed in that xml-file normally ?

I first made a backup copy of the ppx file to be 'safe'.  Started V13 - this time there were to my surprise two open tabs.  Then I deleted the ppx file. clicked file save all two tabs still open then closed V13.

Went to look at the .ppx There was NO .ppx file recreated. With no ppx being recreated I started V13 and no files were opened.

Next I closed V13 again. Copied the backup copy to the correct ppx name then restarted V13.  It Opened with two tab showing files.

Now it gets interesting - I closed one tab, did a save all just because, closed V13.  When I restarted V13 TWO tabs were opened even though I closed V13 with one tab open.

Bottom line it under some conditions the .ppx is not being updated, however at least one somehow it was because now instead of no files it always opens with two files....

I manually edited the ppx removing one file.  The V13 always opens with the one file even if closed with two or none showing.

(Note all of the above used the X to close V13, you'll see why important below)

So I did some more testing it appears that when closing V13 with the X the ppx file is not updated, whereas closing V13 with File - Close Project it is updated.  I saw this by watching the file modified time.  So maybe it has been this way I'm not sure, I've almost always used the X because using File - Close Projects takes two steps to shutdown.

Next I deleted the ppx.  Opened V13, opened three files (3 tabs showing) - Used File - Close Project and it recreated the ppx file.  So to me it looks like the X is the issue.

John Z

https://github.com/scivision/C23-examples (https://github.com/scivision/C23-examples)

cc.exe wildcard don't work ?

test results:
c99\unreachable.c(13): fatal error #1014: #error: "unreachable() is not implemented for this compiler".
c23\nullptr.c(29): warning #2115: Local 'cloned_zero' is initialized but never used.
c23\nullptr.c(28): warning #2115: Local 'cloned_NULL' is initialized but never used.
c23\reproducible.c(10): error #2603: Invalid attribute [[reproducible]] for identifier 'sum'.

https://c-for-dummies.com/blog/?p=6173 (https://c-for-dummies.com/blog/?p=6173)
#include <stdio.h>
int main()
{
    int a = 0b11010;
    printf("Decimal: %d\n",a);
    printf("Hex: %x\n",a);
    printf("%b\n",a);
    return 0;
}


Quote from: TimoVJL on April 26, 2025, 09:23:41 AMcc.exe wildcard don't work ?

Compiler optimizer bug (terminates the loop/program, after first compile, with EXIT_FAILURE).
This will take a while to fix...

Quote from: TimoVJL on April 26, 2025, 09:23:41 AM

Code Select Expand

c99\unreachable.c(13): fatal error #1014: #error: "unreachable() is not implemented for this compiler".
c23\nullptr.c(29): warning #2115: Local 'cloned_zero' is initialized but never used.
c23\nullptr.c(28): warning #2115: Local 'cloned_NULL' is initialized but never used.


Sloppy tests...

Quote from: TimoVJL on April 26, 2025, 09:23:41 AM

Code Select Expand

c23\reproducible.c(10): error #2603: Invalid attribute [[reproducible]] for identifier 'sum'.


I could have sworn there was a compiler test for this, but apparently not. Yet another bug to fix.

Quote from: TimoVJL on April 26, 2025, 09:23:41 AM

Code Select Expand

[code]#include <stdio.h>
int main()
{
    int a = 0b11010;
    printf("Decimal: %d\n",a);
    printf("Hex: %x\n",a);
    printf("%b\n",a);
    return 0;
}


What is the problem? Seems to work here...

That bit-printing example was just for others to see some features, nothing more  ;) 

Quote from: TimoVJL on April 26, 2025, 03:21:06 PMThat bit-printing example was just for others to see some features, nothing more  ;) 

Ah! OK...

Checking the "reproducible.c" case some more, it appears to be wrong (as I read the C23 standard).

WRONG:
[[reproducible]]
int sum(int a, int b){
    return a + b;
}

CORRECT:
int sum(int a, int b) [[reproducible]] {
    return a + b;
}


Debug this code use the latest RC3, got an "Exception: Access violation".

#include <assert.h>

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

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


Already reported (somewhere else, I think). Will be fixed in the release version (coming soon, just waiting for some confirmations...)

What encoding is used for the option

 /Zc option enables colorized diagnostics

Quote from: Robert on May 20, 2025, 06:16:28 AMWhat encoding is used for the option

 /Zc option enables colorized diagnostics

ANSI escape codes:
https://en.wikipedia.org/wiki/ANSI_escape_code