Bored?

[TimoVJL]

If someone have a cloudy day, check this forum chain:

http://masm32.com/board/index.php?topic=6546.msg70177#msg70177

You learn how asm programmers hate C

I don't hate asm and i can compile that example C/C++ code with Visual Studio 2008 with Microsoft C/C++ compiler version 19.10 and with WinDDK 7600, and result exe is 7 kb using msvcrt.dll.

So C/C++ compiler isn't the problem, only the linked CRT.

[Vortex]

Hi Timo,

I think the main problem is that M$ is deliberately obfuscating their stuff, especially the header files. Very complicated files which are not easy to translate to other languages. The increasing level of obfuscation and complexity might be the reason of that animosity. On the other side, Pelles development suit is a nice package not complicated like M$'s Visual Studio. As you mentioned, C\C++ examples can be built with the minimal dependencies like msvcrt.dll  Sadly, not everyone is aware of this.

[jj2007]

Countless C/C++ coders searching the internet in a desperate attempt to understand their endless error messages. Trial and error as the ultimate programming paradigm

That is just a simple description of the situation. And btw, if I do something in C, normally I use Pelles C because it just works, instead of dumping incomprehensible error crap on the user. Practically all the projects you posted here just build "as is", without desperate google searches.

@JJ,
cl /GS- /TC /GL /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /O1 /fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MD /nologo /Fe /Fombr.obj mbr.cpp /link /OUT:mbr.exe /ENTRY:main /SUBSYSTEM:CONSOLE /DYNAMICBASE:NO /FIXED /MACHINE:X86 /OPT:REF /SAFESEH:NO /INCREMENTAL:NO kernel32.lib ucrt.lib

Builds a 3 KB exe.

I am sure you will not get it to work, as usual. :badgrin:

Isn't that "commandline" funny?

[TimoVJL]

messy, these options are important in that case:
cl /GS- /MD /ENTRY:main /FIXED

This Small Application Wizard could be useful.

[jj2007]

messy, these options are important in that case:
cl /GS- /MD /ENTRY:main /FIXED

Sure, let's make a test:

Code: [Select]

"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe" /GS- /MD /ENTRY:main /FIXED "Tmp.c" user32.lib kernel32.lib ucrt.lib

Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '/ENTRY:main'
Tmp.c
Tmp.c: fatal error C1083: Cannot open include file: 'XED': No such file or directory
So sad, as Donald Dumb would say

But let's test also the long commandline of aw27:

Code: [Select]

J:\Masm32\MasmBasic\Res>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe" /GS- /TC /GL /analyze- /W3 /Gy /Zc:wchar_t /
Zi /Gm- /O1 /fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /
Oi /MD /nologo /Fe /Fombr.obj Tmp.cpp /link /OUT:mbr.exe /ENTRY:main /SUBSYSTEM:CONSOLE /DYNAMICBASE:NO /FIXED /MACHINE:X86 /OPT:REF /SA
FESEH:NO /INCREMENTAL:NO kernel32.lib ucrt.lib
Tmp.cpp
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(79): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(110): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(141): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(153): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(163): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(174): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(184): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(194): error C2059: syntax error: '['
c:\program files (x86)\microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(206): error C2059: syntax error: '['
More trial and error...? Now I will tell you a secret: This ridiculously simple hello world proggie fails miserably with various versions of MCVC and GCC, despite the commandlines suggested by real experts^TM, but it builds fine with Pelles C - provided you do something very logical, that is, add a W to the line
HANDLE hFile = CreateFile(L"\\\\.\\PhysicalDrive0", ...

Of course, it will still fail miserably with the other compilers, but hey, wouldn't it be fun to spend some weeks on solving the puzzle? Especially if you are bored, of course

[TimoVJL]

Oops.
cl /GS- /MD test.c /LINK /ENTRY:main /FIXED /NOCOFFGRPINFO kernel32.lib

EDIT:
cl /GS- /MD test.c -link /ENTRY:main /FIXED /NOCOFFGRPINFO kernel32.lib

[jj2007]

Yeah, that looks ... different:

Code: [Select]

J:\Masm32\MasmBasic\Res>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe" /GS- /MD test.c /LINK /ENTRY:main /FIXED /NO
COFFGRPINFO kernel32.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '/LINK'
cl : Command line warning D9002 : ignoring unknown option '/ENTRY:main'
cl : Command line warning D9002 : ignoring unknown option '/NOCOFFGRPINFO'
test.c
test.c: fatal error C1083: Cannot open include file: 'XED': No such file or directory
Of course, with a lot of experience and a bit of trial and error^TM, you can overcome error D9002 (hint: four chars need to be changed in the commandline). Once you have solved this issue, you will stumble into a new, amazing puzzle called "error C2059", and here I am bit unfair and offer you the solution right away:

I tracked down the reason of those sudden compiler errors.

In the great tradition of windows.h it appears that Microsoft introduced tokens that cause name clashes with our codebase.

In our precise case, we had: #define Null (void*)0

Somewhere in our code, we need to use the offsetof macro and to make it available we #include <stddef.h>

I tracked down stddef.h in turns includes crtdefs.h which ends up including sal.h where our Null macro seems to clash with source code annotation in MS headers...

As a workaround, we did:....

There is no Null macro in aw27's code, but ... just try yourself, it's fun. There are people who play Zelda or Super Mario, but IMHO compiling a hello world proggie with a Micros**t compiler can be even more fascinating and challenging

[TimoVJL]

Sure i made a lot of mistakes.

test.c

Code: [Select]

void __cdecl mainCRTStartup(void)
{
__declspec(dllimport)void __cdecl exit(int status);
int __cdecl main(void);
exit(main());
}
int __cdecl main(void)
{
return 0;
}cl /GS- /MD test.c /link /FIXED /NOCOFFGRPINFO
creates 1.5 kb exe

test.cpp needs some changes

Code: [Select]

#ifdef __cplusplus
extern "C" {
#endif
void __cdecl mainCRTStartup(void)
{
__declspec(dllimport)void __cdecl exit(int status);
int __cdecl main(void);
exit(main());
}
#ifdef __cplusplus
}
#endif
int __cdecl main(void)
{
return 0;
}so this is the C/C++ compiler part of this story.
headers and CRT's are the next part.

Windows Driver Kit Version 7.1.0 have headers and libs for WindowsXP/Windows 7.
I collected header set from there.
An another is Microsoft Windows SDK for Windows 7, but it don't have msvcrt.lib for msvcrt.dll.

[jj2007]

Sure i made a lot of mistakes.
...
so this is the C/C++ compiler part of this story.
headers and CRT's are the next part.

No, Timo, you didn't do any mistakes. And I don't hate C, but I despise those who claim that there is a C "standard", that it is "portable" and other hot air promises. When you present a Micros**t C compiler with a hello world proggie that was designed for a version that is two years older or younger than the current one, it complains bitterly that it doesn't know how to build it. Throw it at GCC, and it will complain with loads of incomprehensible error messages. The whole "compatible and portable" story is just fake, it is a ridiculous religious belief. Assembler may be restricted to Windows XP and higher, but a) that covers 95% of the desktop market, and b) all my code builds out of the box with ML 6.15, 8.0, 9.0, 10.0, ... and JWasm, AsmC, UAsm64 and UAsm32. That is a standard.

[Vortex]

Jochen is right. Masm and the compatible Macro Assemblers are processing the same source code without those adventures. The problem is that compilers like MS VC and MinGW are very complicated. Plus, the obfuscated and complicated header files like hieroglyphs is another serious problem.

[TimoVJL]

If someone write portable C code, code is quite portable too.
Original example was for win32.
So i am bored to this topic.

[TimoVJL]

Activity in this site is quite low, so i think that people don't want and don't care about of this site's future.
Luckily now it is easy to export PellesC project to Visual Studio on experiment level.
Visual Studio is unnecessarily big and slow, but commonly used.

If we can made experiments in poide and later move easily the project to VS is a big help. For example VS debugger is far better in threaded code, like with COM.

One weak feature in VS is a weak support for msvcrt.lib/msvcrt.dll for small programs for older Windows.
Something like a msvcrtXP.lib could be useful with it. Why include useless code if and when we don't need it.

Any comments?

[ika]

I don't think I would use a program that converts a ppj into a Visual Studio project , but I would use a tool that does this the other way around. Lots of libraries in theory could work in Pelles C, but project files are only given for Visual Studio, and it is bothersome converting it myself.

[bitcoin]

One weak feature in VS is a weak support for msvcrt.lib/msvcrt.dll for small programs for older Windows.
Something like a msvcrtXP.lib could be useful with it. Why include useless code if and when we don't need it.

Any comments?

It is very difficult to create programs in the visual studio with a linking CRT. The studio for some reason inserts garbage there, which writes "there is no such file MSVCRT666.DLL" and requires the installation of a "redestributable package". You can either take MSVCRT.LIB from XP DDK or cut absolutely everything (nodefaultlib,no use this and that..). But - the studio does not know how to inline the code and you still need to put memset.c and memcpy.c into your project (because char a[20] = {0} is eq MEMSET). This is bad. I do not like the studio. When I learned about the Pelles C, I moved here.

[TimoVJL]

check msvc intrinsic

EDIT: this was helpful for console program

Code: [Select]

#pragma comment(lib, "msvcrtOS.lib")
#if _MSC_VER >= 17
# if defined(_WIN64)
#  pragma comment(linker,"/subsystem:console,5.2")
# else
#  pragma comment(linker,"/subsystem:console,5.1")
# endif
#endif
void __cdecl mainCRTStartup(void)
{
__declspec(dllimport) void __cdecl exit(int status);
int __cdecl main(void);
exit(main());
}
msvcrtOS.lib is made from OS msvcrt.dll