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.
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.
> 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.
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.
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.
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?
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#.
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.
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;
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.
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.)
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());
}
}
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 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)
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 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.
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.
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 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.
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).
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.
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".
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 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.
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.
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.