Hacker News Reader

Comment by gum_ina_package | Hacker News Reader

The amazing thing is that you can potentially write all your code in C# and have backend/frontend logic for the web (ASP.NET), Windows, Windows Phone, and even iOS/Android (via Xamarin). Wow.

View on HN

The amazing thing is that you can potentially write all your code in C and have backend/frontend logic for the web, Windows, Windows Phone, OSX, FreeBSD, OpenBSD, Tru64, VAX, Arduino, Linux Kernel, Windows Kernel, Mach, Hurd, and practically every processor or operating system ever built, and even iOS/Android (via Xamarin). Wow.

You can even link to and reuse that code from languages such as: C++, C#, Java, Ruby, Perl, Python, assembler, lua, scheme, lisp.

The future is gonna be so 1970.

There's even a text editor that runs on all those platforms!

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.

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

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.

What a well-structured and bullet-proof response. Congratulations, you're now revered amongst your peers and are considerably more employable thanks to your insightful observation. High five!

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.

Yay!

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?

Have you ever actually used C in a real project? I can't seem to get away without using any compiler specific constructions, much less operating system specific call routines.

There isn't even a Boost for C.

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

Have you ever tried to get C# code deployed on Linux, OSX, and Windows?

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.

>Java and C# just push the work somewhere

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

No I mean somewhere else, because for the most part the cross platform stuff doesn't work.

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.

What in the world are you talking about? Apps in Xamarin can be as much as 10mb for a full app. Its linker is smart and knows not to bring in stuff it doesn't need. If you don't, it's around 40mb.

I'm talking about releasing a cross platform app for Windows, Linux, OSX, Android, and iOS, and the differences between Java/C# and C.

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.

The most basic mono install currently takes about 3.7 MB of disk space, this includes about 1.7 MB for the JIT and 2 MB for mscorlib.dll.

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

> he amazing thing is that you can potentially write all your code in C and have backend/frontend logic for the web, Windows, Windows Phone, OSX, FreeBSD, OpenBSD, Tru64, VAX, Arduino, Linux Kernel, Windows Kernel, Mach, Hurd, and practically every processor or operating system ever built, and even iOS/Android (via Xamarin). Wow.

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.

The only portable GUI code that I've ever seen work somewhat reliably is HTML/CSS.

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 platform perspective, Qt is good for all the desktop environments, but for mobile, .NET/Xamarin is the way to go.

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

I actually had a super hard time with F# and XAML, this was back in F# 1.0/1.1 days.

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.

Too bad you missed out on Flash / Flex. At one point it was absolutely brilliant.

Solution: Lua.

But what about Linux?

Mono! Lots of ASP.Net projects (like Nancyfx or SignalR) are actually built on Mono. I think there's some hope that web dev on Windows isn't dead.

I tried Keepass2 with mono on Linux and it's pretty slow and unnatural UX experience. Much like running Wine. On OSX Keepass2 mono just froze constantly and looked weird. I've had similar experience with other cross-platform apps.

Total cross-platform is a pipe dream. Just like Java or more recently HTML5/JS cross-platform mobile apps, they are almost always a half-baked solution compared to proper native OS apps. The UX and performance will never be consistent enough to make it better than just investing in native development (Note I'm talking about software, not simple content consumption apps where HTML5 in browser is fine).

Having primary operating system -> tablet -> phone is a good enough goal. They should focus 100% and make it as stable ass possible.

How is supporting two desktop operating systems any less realistic than supporting a desktop operating system and at least two separate mobile form factors on three different platforms? Both have the potential to suck if one platform doesn't get enough attention.

I think Qt does it decently, as far as the desktop platforms are concerned.

I mean look at something like Origin or the Battle.net desktop app.

I would also say that wxWidgets makes it pretty easy, particularly as you have the source. I know there is a mass of #defines in it etc. but I have found it very useful and reliable across the 3 major platforms (Win, Linux, Mac). And it renders natively on them, unless you force wxUniversal (which does its own rendering of controls, like Qt does). I would even argue that Qt does a worse job of making stuff look native, particularly on Mac OSX; wxWidgets controls are native on Mac OSX, as underneath it is Obj-C mm files everywhere.

KeePass is a bad example. It's a Windows Forms app. If they wanted to properly support Linux, they could continue to share most of their C# code, but write a tailored UI using something like GTK#.

Nobody is truly advocating "write once, run anywhere".

Mono makes no pretext of offering cross-platform GUI live, and so any app that attempts to use the same GUI on multiple platforms using winforms on Linux or gtk on win32 is going to be ugly. They're up front about this.

Naturally mono probably has some quirks, which you need to keep in mind during development. However, you can make successful apps using it. The Unity3D engine uses mono on linux, and the games using it run fine (even on my laptop).

in theory Microsoft COULD support linux directly,would be a bit of work, but they would not even need mono.

Now from a business persperctive would it make sense? i dont know,Microsoft business relies heavily on Windows. But hey,anything's possible.

Problem with mono is ,mono or not,.net dev without VS kind of sucks,and VS is Windows bound.

Miguel de Icaza considers Linux dead (http://tirania.org/blog/archive/2013/Mar-05.html). It shows. Last time I tried to compile latest version of mono on ubuntu (a couple of months ago) it was a painful process of missing dependencies and compiler errors. In the end, I couldn't make it run.

Reply on news.ycombinator.com