Have you ever done C development like this, ever in your life?

I did. Between 1994 and 2003, we had applications run across Windows, HP-UX, Aix, DG/UX, GNU/Linux, BSD, Solaris.

An awful mess of #ifdefs, compiler specific behaviours, lack of POSIX compliance, OS specific extensions.

This on the server side, and lets not forget there are ZERO portable standards for writing portable GUI code in C.

Finally, C shouldn't never had become mainstream given its lack of safety, that we are still suffering in 2014. There were better systems programming languages in the late 70's, they just weren't at Bell Labs.

Everything else either implements a 3rd GUI, Swing, et al, or looks weird on a few of the platforms, GTK.

Oddly enough the best cross-platform lib I've seen, Qt, is written in C++.

C certainly isn't the be all and end all, however, it's far more portable, reusable, and linkable than C#.

From a language perspective, why in the world would you want GUI code in C or C++? Both languages make it very easy to shoot your foot off and have no idea what happened. However, C can be very elegant if used for the right reasons. C# is safer, but also not perfect. That's where F# comes in. :)

While not strictly C, ObjC/UIKit is a helluva language for doing GUIs.

I actually don't like GUIs in C++/Java, or C# because it's far too restrictive and you spend all your time making the class hierarchy happy and typing boiler plate rather than getting stuff done.

ObjC is a beautiful mix of scriptyness and performance / low memory utilization. If ObjC is too slow, C is right there, and if it's too complicated for C add in a little C++. My typical mix is usually about 90-95% ObjC, 5-10% C, and 1% C++.

I love that if you know an object supports a method you can just cast to id and call it. If an object is missing a method, you just add it. If a base class is stupid, you override it.

Java/C# are total pieces of crap in this regard, although C# is far better for having extension methods.

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

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?

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"); }

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.

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.

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.

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.

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.

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

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.

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

Microsoft (R) COFF/PE Dumper Version 11.00.61030.0 Copyright (C) Microsoft Corporation. All rights reserved.

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

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.

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

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

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

    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());
            }
        }

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.

"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

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

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)

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.

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.

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

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.

Seriously though: not only is C# a much easier language to learn which includes features and libraries that most developers expect from a modern language, that probably wasn't even what gum_ina_package was "Wow"ing at.

To me, the point is that the barrier to entry for writing apps across all platforms has now been lowered for C# developers - a group of developers, by the way, which is numerous.

Just what my iOS app needed, more shitty Windows devs, and dependency injection, or whatever the latest enterprise bullshit is. Why write code that 100 to 200 lines of code that actually work when you could make a giant UML diagram, a bunch of flow charts and write unit tests all day because everything you've ever heard of needs to be an object with a class hierarchy.

The Linux kernel doesn't have unit tests, DI, TLA, etc and works and every ASP.NET app you've ever seen has loads of them yet can barely accomplish anything before crashing / doing something weird?

Customers are gonna be fucking pumped when they find out we've added dependency injection and millions of lines of code that are pointless and unnecessary. Why release memory when you're done with it? Just don't do anything wave your hands and voila you're process is using 200 MB instead of 2 MB, yet it claims to have a 'garbage collector'

Have you ever considered that some people choose the languages and platforms they work with specifically to avoid the anti-patterns commonly found on the platforms and languages they refuse to work with?

There isn't even a Boost for C.

Honestly, I'd be surprised if you actually knew C with a statement like that.

You end up at exactly the same point you did with C, except now you have 100-500 MB of garbage to haul around with your application.

Cross platform dev and deployment is hard, Java and C# just push the work somewhere else while adding garbage that gets in the way.

If you want to make GUIs for iOS,Android,Windows,OSX, and Linux use HTML/CSS/JS.

If you want to process data on iOS,Android,Windows,OSX, and Linux use C/C++, using only the std C/C++ libs, or a portability library.

You mean someone else, which is the entire point of why you would use any platform/library/framework.

Oh? You have a cross platform path separator builtin? Wow that must be totally worth 200 MB of garbage.

I'm sure the client will be fine with fucking around with the CLR / JVM all day instead of just downloading a 200 KB executable. It's just what they need, now not only do they need to update your application but they have a dependency nightmare too.

To be fair I haven't tried to release an app for Windows/OSX from Xamarin but my understanding is that it requires the .NET or Mono frameworks which on most computers is a 100 to 200 MB install.

For Java you're for sure going to have to download the JRE. When you start the app it eats gobs of memory.

Maybe it's changed but even Xamarin itself requires Mono to be installed, this is the kind of shit I'm talking about, you should download the app, drag it to applications, done. Or on Windows click Next a whole bunch of times.

Even the monstrosity that is XCode is a one drag install.

http://www.mono-project.com/Small_footprint