NO

Recent Posts

Pages: 1 ... 5 6 [7] 8 9 10
61
Bug reports / Re: Linker Error (I'm fairly sure this isn't my fault!)
« Last post by Mikael on April 28, 2022, 04:18:08 pm »
Oh.  :(

Any idea when it may happen? I'm just starting on a major project, and VirtualAlloc2 is *required* for the foundational layer. Do I have to use Microsoft's compiler? I'd rather not, because I just feel so much more at home with Pelles!
62
Beginner questions / Re: What's wrong with this dll?
« Last post by frankie on April 28, 2022, 04:07:07 pm »
I'll have a look next days.
63
Bug reports / Re: Linker Error (I'm fairly sure this isn't my fault!)
« Last post by frankie on April 28, 2022, 04:04:19 pm »
Sorry, but "VirtualAlloc2()" is from SDK WIN10, and is not available yet in actual PellesC libraries.
64
Bug reports / Linker Error *SOLVED*
« Last post by Mikael on April 28, 2022, 03:40:15 pm »
This compiles cleanly as it should:


#define WIN32_DEFAULT_LIBS
#include <Windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
    VirtualAlloc(
        NULL,         // BaseAddress
        65536,        // Size
        MEM_COMMIT,   // AllocationType
        PAGE_NOCACHE  // PageProtection
    );
    return 0;
}


But this fails with POLINK: error: Unresolved external symbol 'VirtualAlloc2':


#define WIN32_DEFAULT_LIBS
#include <Windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
    VirtualAlloc2(
        NULL,         // Process
        NULL,         // BaseAddress
        65536,        // Size
        MEM_COMMIT,   // AllocationType
        PAGE_NOCACHE, // PageProtection
        NULL,         //*ExtendedParameters
        NULL          // ParameterCount
    );
    return 0;
}


Both functions are located in kernel32.lib and should be found by including Windows.h so I don't think I'm doing anything wrong here.



65
The problems with Pelles C is most libraries out there doesn't support it (there is no ifdef for Pelles C at all!). Pelles C also too different to GNU and LLVM and even different from MSVC. Believe me or not, I downloaded the code for MSVC and I expected it should work with Pelles C then it turns out it doesn't work. LLVM success because it was developed a way it could serve as the drop-in replacement for GCC. Clang and GCC are mostly compatible. Only after Clang gains enough support to stand against GCC it started to introduce incompatible to GCC changes (it own extensions, different designs,...).

To my observation, the header name on Pelles C is sometimes different than GCC (OpenGL header come to mind), the way Pelles C define Win32 also different. The __WIN32__ macro of MinGW GCC is not defined on Pelles C. Either does __WIN64__ (on Pelles C it's _WIN64 isn't it?). This alone drags in so many problems.
Yes you're right, but the point is that MSVC and GCC have defined their standards (both are famous to be not fully compliant to C standards), while PellesC has as main goal the strict adherence to the C standards.
MSVC programs are absolutely deviated from standards so it is normal that you need to adapt them.
I can't say if this is good as "commercial" strategy (withstanding that PellesC is completely free for personal or commercial use), but to use it you have to code in compliant C even when MS extensions are on...
66
General discussion / Re: Not enougth people for exchange
« Last post by 1e9t8m29 on April 27, 2022, 07:39:51 pm »
I agreed with the OP. There is no one there. People occasionally visit and sometimes post something but generally speaking there is no longer any new activities.
67
Today it's mostly about GNU and LLVM, not only Pelles C but other compilers of the past, DMC, Watcom,... all faded into oblivion. Pelles C is better as it could keep up with the latest standards. DMC, Watcom,... are way too outdated.

The problems with Pelles C is most libraries out there doesn't support it (there is no ifdef for Pelles C at all!). Pelles C also too different to GNU and LLVM and even different from MSVC. Believe me or not, I downloaded the code for MSVC and I expected it should work with Pelles C then it turns out it doesn't work. LLVM success because it was developed a way it could serve as the drop-in replacement for GCC. Clang and GCC are mostly compatible. Only after Clang gains enough support to stand against GCC it started to introduce incompatible to GCC changes (it own extensions, different designs,...).

To my observation, the header name on Pelles C is sometimes different than GCC (OpenGL header come to mind), the way Pelles C define Win32 also different. The __WIN32__ macro of MinGW GCC is not defined on Pelles C. Either does __WIN64__ (on Pelles C it's _WIN64 isn't it?). This alone drags in so many problems.
68
https://github.com/oz123/awesome-c

Well, I tried some of them like libU, TBOX and PBL:

https://github.com/oz123/awesome-c#frameworks

Not works. Most of the time the errors spit out directly from the header files.

Isn't the world is too GNUism so that they only list GNU compatible compilers (GCC, Clang,...) and Pelles C is not even listed on C compilers!

https://github.com/oz123/awesome-c#compilers
69
Beginner questions / Re: invalid directory
« Last post by 1e9t8m29 on April 27, 2022, 04:52:53 pm »
I don't know why Pelles C still keeps creating Pelles C Projects directory on the user's Documents library (map to My Documents in user home directory). This causes so many problems! Move the Pelles C Projects directory out of the Documents library solved the problem. I suggest changing the default location of Pelles C Projects to be the user's home directory rather than the Documents library (user's My Documents).
70
Beginner questions / What's wrong with this dll?
« Last post by 1e9t8m29 on April 27, 2022, 04:49:19 pm »
Download this and you will have dw.dll:

https://dbsoft.org/dwindows/dwindows-win64-3.2.zip

Pelles C currently not work with dwindows. There are many errors spit out on dw.h and the most important is Pelles C said dw.dll is invalid.

Please have a look at this.

Thanks.

Update: this is the bug report to dwindows developer on the dwindows forum:

https://dbsoft.org/forum/showthread.php?tid=87
Pages: 1 ... 5 6 [7] 8 9 10