Hacker News Reader

Comment by gecko | Hacker News Reader

C# is a much higher-level language than C, with a much richer set of libraries that can be relied upon to be everywhere. That's why it matters.

View on HN

C# is both higher-level and lower-level than C.

If you try and add a "JumpList" to a program in C, you end up using Windows-specific extensions / APIs that make it no longer crossplatform. C# + Low-level Win32 APIs is closer to the OS than the generic C-libraries designed on a DEC PDP-11 40 years ago.

http://windows.microsoft.com/en-us/windows7/products/feature...

Besides, your typical C-program will not understand SEH Exceptions or DLLs (concepts that are extended as part of the "Win32 Runtime". Its not like Win32 is POSIX compliant ya know...

You can rely on C# being on all platforms by default? Linux and OS X? Really?

Last time I used Windows (several years ago), there were always apps that needed to download and install the latest version of the .NET runtime... - is that still a thing?

int main(){ puts("Hello World"); }

This doesn't work in Windows. The standard entry point to Windows is "int CALLBACK WinMain( _In_ HINSTANCE hInstance, _In_ HINSTANCE hPrevInstance, _In_ LPSTR lpCmdLine, _In_ int nCmdShow );"

C never really "ran" on Windows. C is built on top of abstractions to even run on Windows. A SegFault in standard C is supposed to be passed to a signal handler (in Linux/ OSX).

A SegFault in Win32 is passed to the SEH exception handler, to the __except{} statement in some function as the stack is unwound. (Oh yeah, __try{} and __except{} don't exist in "normal C", do they?)

--------------

The "OS Language" of Windows is C++ (through COM and COM+ interfaces). The "OS Language" of Linux and OSX is C.

The sooner you realize this, the easier programming on Windows is going to be. Windows never really supported C as a first class citizen. C code cannot easily call core Win32 libraries like DirectX. (It can, but it is significantly harder than just using the C++ COM interfaces)

C# works very closely with COM interfaces in Win32. And thus, C# is the second language of choice of Windows. The only reason C# hasn't overtaken C++ in everything seems to be politics.

Mind you, Microsoft fully supports C# Device Drivers. The lowest level hardware interactions in Windows can be done with C#.

  int main(){ puts("Hello World"); }

> This doesn't work in Windows.

Sure it does. Windows has console programs. Though I'd argue that your use of non-standard main is not something I'd do, but IIRC even that works on Windows, at least it did with older compilers, haven't done much windows C programming with the newer ones.

What you point out is an _abstraction_ that compilers include as part of their kits.

You claim to be a low-level programmer who understands C. The truth is right in front of you. Decompile those programs, look at their symbol tables. Notice, every Win32 program starts at WinMain, called with the arguments that I listed above.

Come back when you've done this simple exercise. Realize, WinMain is the _true_ starting point of "C Programs" in Windows. The rest are compiler abstractions.

http://msdn.microsoft.com/en-us/library/windows/desktop/ff38... >>> How does the compiler know to invoke wWinMain instead of the standard main function? What actually happens is that the Microsoft C runtime library (CRT) provides an implementation of main that calls either WinMain or wWinMain.

The true starting point for PE executables is AddressOfEntryPoint in the PE header, with a few parameters pushed on the stack. WinMain is a compiler abstraction; it is not looked up by name.

You can't code in a high-level language like C without working with abstractions. Whether you look at the main() level or the WinMain() level, there will still be library initialization hooks running before your end-user code gets to run.

I'm gonna upvote your comment as you are one of the few people in YCombinator who seems to know what they're talking about. Good job catching that, and you're right. The PE Header contains the entry point. (And the MZ Header is potentially a 2nd entry point left in for DOS Compatibility purposes)

The rest of the people here talking as if C is some sort of ultra-portable magic language need to learn about the low level details that differ between OSes.

My primary point remains however, the easiest and most straightforward way to interface with Windows libraries is through C++ and C#. Even C itself is a high-level language built on top of abstractions built by compilers and linkers.

Show me where in the ANSI standard it says this is illegal. Implementation details do not matter. The Microsoft C compiler will compile a ANSI C89-conforming program into a runnable executable on Windows. The rest is undefined.

And while we're on implementation details, please note that most UNIX platforms do not start at main either. Most platforms include some soft of crt0 that must be linked which contains the real entry point. The dynamic linker will also run code prior to main.

But the C standard only defines what the environment looks like when execution begins and makes no statement on what might run before or how the program got into memory in the first place.

Come to think of it, I don't think I've used any platform where main() is the real entry point to the executable. On Linux the real entry point is _start, all of the bare-metal embedded stuff I've touched does a whole bunch of hardware setup in crt0 before it calls main(), etc...

main() is the entry point function in newer OS X versions. Why ship crt0 in everything when you can put it in dyld?

crt0 would still get linked into static binaries in OSX, I presume.

What static binaries would those be?

https://developer.apple.com/library/mac/qa/qa1118/_index.htm...

> Realize, WinMain is the _true_ starting point of "C Programs" in Windows

Actually I do know that, but you simply said "int main() blah blah blah" doesn't "work" (to quote you there). If you're going to require me to be precise, maybe you should look in the mirror first.

Asm output from a c program that prints hello world to the screen. You can figure out the other sections I'm sure.

No win main or other similar concepts here and built using vs2012.

Dump of file consoleapplication6.exe

File Type: EXECUTABLE IMAGE

_main: 00401000: 68 48 20 40 00 push offset ??_C@_0M@KIBDPGDE@Hello?5world?$AA@ 00401005: FF 15 00 20 40 00 call dword ptr [__imp__puts] 0040100B: 83 C4 04 add esp,4 0040100E: 33 C0 xor eax,eax 00401010: C3 ret

  Summary

        1000 .rdata
        1000 .reloc
        1000 .rsrc
        1000 .text

I've tried to do programs with /nostdlib before, how did you implement the startup and shutdown functions that are required?

Sorry about that I didn't see your reply! Because I have to use phone it's challenging to type out all I did. While I achieved it, I wouldn't say it's sensible or easy!

Anyway, you have to turn off c++, c++ exceptions, security checks in compiler options. In linker set the entry point to main and turn off error reporting. From there it's finding the right lib which is dependent on arch, etc.

To be honest it's not worth doing. I only knew of it because I had to patch a vs2010 exe to run on windows 2000.

Microsoft seems to think that it'll work: http://msdn.microsoft.com/en-us/library/bb384838(v=vs.110).a...

MS also has more people using a 14 year old OS than their latest and greatest.

> The "OS Language" of Linux and OSX is C.

Not quite. Significant parts of XNU (the Mac OS X kernel) are written in C++.

And significant parts are written in Assembly as well. But Assembly isn't the "OS Language" of either Linux nor OSX :-p

What I mean by OS Language, is the language that interacts with core OS Libraries. The OS Language of Android is Java. iOS is ObjC. OSX core is either ObjC or C. Linux is definitely C based. (ioctl)

Microsoft is either C++ or C#. (DirectX, Ribbons, etc. etc. are behind COM interfaces that are most easily interfaced by C++ or C# code)

If nothing else, OS X's I/O Kit API is C++ish (it's 'Embedded C++').

Wow, is that thing really embedded C++? Bjarne always said that embedded C++ deserved to die if it wasn't already dying, mainly because it appears to remove all the useful bits of C++ to make it some static-typed-only inheritance mush put on top of C, as I understand (most likely wrong).

Yup http://en.wikipedia.org/wiki/I/O_Kit. I mean Embedded C++ is not really a language, any C++ compiler can be turned into an "Embedded C++ compiler" by turning some features off. As to the Bjarne quote, a lot of things that are nice in application development can become tricky when you are closer to the metal.

Thanks for the link. The bare metal thing is probably why C guys typically see C++ as bloated and why I look at C and think "how do you write anything?!?!!"; I live happily in C++ land you see.

I always thought that the whole WinMain() thing was an ugly mistake. The right way to do this would be to organise the libraries and startup code so that the simplest Windows GUI program was not 50 or 100 lines of boilerplate, but was instead something like;

  #include <windows.h>
  void main()
  {
    WinGuiInit();
    WinGuiMessageLoopRun();
  }

Or similar. Extra functions and parameters as required to setup custom icons, window classes, message handlers, whatever.

What always jumped out at me when I looked at Windows code was all the capitalized type macros/typedefs.

It's done like that in C# (for WinForms, at least).

    namespace WindowsFormsApplication1
    {
        static class Program
        {
            /// <summary>
            /// The main entry point for the application.
            /// </summary>
            [STAThread]
            static void Main()
            {
                Application.EnableVisualStyles();
                Application.SetCompatibleTextRenderingDefault(false);
                Application.Run(new Form1());
            }
        }

At least they provide the mainCRTStartup thing [1] so you can use main() in GUI executables. Regarding boilerplate, Win32 was designed as a very low level API, with MFC and other high level libraries to make things easier.

[1] http://stackoverflow.com/questions/11785157/replacing-winmai...

I didn't know about the mainCRTStartup thing, thanks. But it should have been the default - to me WinMain() is just a failure to understand what is best exposed and what is best encapsulated. My boilerplate reduction proposal is to provide a few helper functions to optionally avoid exposure to some of the pipework - just to make life a bit easier when starting out. MFC on the other hand is a massive new layer of compromises and other crud slapped over the top of the Win32 API - somehow managing to make it even more cryptic (YMMV). Also MFC postdated the Win32 API by a few years, so presumably wasn't considered as the first choice solution at the start. The first Petzold book was a C thing, MFC and C++ came later.

If by "boilerplate" you mean creating/registering a window class before creating a window, you don't need to do that if your application's UI largely looks like dialogboxes - DialogBoxParam will create a message loop automatically and all you need to give it is the layout template and the message calback WndProc.

(I've been working with Win32 for around a decade now, it's got its warts but really isn't that bad once you get used to it. You can do a lot of interesting things with it.)

Sure I am not arguing about the whole of Win32, just the fact that it would have been easy to modify the API a bit so that main() was the entry point for a normal windows app.

Have to disagree with you there. Windows is older than COM. It's actually older than C++. The classic core Windows libraries and interfaces like GDI are plain old C. Not even a hint of C++.

COM is language agnostic. You can consume COM servers in Delphi that have been written in VB. Again, no C++, not necessarily. The only "true" C++ API I'm aware of is GDI+. Everything else to my knowledge was and is either straight C or COM.

And I have to disagree with one of your statements a little bit:

"The classic core Windows libraries and interfaces like GDI are plain old C."

__cdecl: this is the native C calling convention Calling function pops the arguments from the stack.

__stdcall: this is the standard Win32 library interface Called function pops its own arguments from the stack.

Calling conventions explained here: http://msdn.microsoft.com/en-us/library/k2b2ssfy.aspx

All MS platforms yes, why would MS care about OSX or Linux.

is that still a thing?

come on, you make it sound like Windows is the only OS that has prerequisites for software?

Last time I checked, yesterday, I wanted to get a file server running on my Debian machine and I had to apt-get install 5 different packages I didn't yet have.

So, yes, that's still a thing, and it always will be. Although afaik since Windows 7 .Net 4 or at least 3.5 should always be there, and 4.5 on Windows 8.

One of the main differences is that apt will do that for you. You made it sound like you had to manually research and ask apt to download each library, when actually you probably just typed 'apt-get install samba' and it took care of researching and downloading all that crap for you.

In Windows, that doesn't exist. The installer either bundles it for you (which can be bad if you weren't expecting it, although is usually fine) or it leaves it in your hands to find and download the correct version yourself.

So yes, not exactly the worse thing ever (still an improvement over the old DLL-HELL) but it's nowhere near how friendly a decent package manager is, either.

Comparing to Debian isn't exactly setting the highest bar for usability. FWIW, OS X manages to support native code without requiring runtime downloads or other manual dependency management.

C# is ..., with a much richer set of libraries...

Citation please. AFAIK, there are significantly more C libraries than C# libraries.

Maybe OP means the C# standard library is richer... I'd believe that.

> C# is a much higher-level language than C, with a much richer set of libraries that can be relied upon to be everywhere. That's why it matters.

Actually this is not true. I've just been tasked with maintaining some C# code that is used as a business tool.

No problem, I thought, I'll just use Xamarin and Mono on my Mac. I made progress, but as soon as the C# code went to use the OleDbConnection stuff (to write to an MS Access database and make Excel files) it threw a DLLNotFoundException. So now I have to find a Windows machine to do the rest of my debugging.

Reply on news.ycombinator.com