Symmetry

[Tuxman]

Now this is an interesting question when put into the context of x² usage statistics. Do you intend to make x² more family-friendly with blue/reddish gumball animations and a childlock on the Delete File button?

-- No kids here, none planned nor wanted. They look like work and I'm still childish enough.

[Kilmatead]

Nikos is just trying to change the subject, away from UI symmetry and onto the nuclear family - like 8 legs aren't enough to confuse the average load of washed socks. That's a dirty trick in more ways than one.

Do you intend to make x² more family-friendly with blue/reddish gumball animations

Judging by an email he just sent me, nikos does indeed seem to have coloured tags on the mind, though he's messing with the interface of the wrong programme. He'll do anything to knock me off a crusade once I get the steam churning...

I, in my muckier-than-thou attitude, define "city-boy" as anyone who doesn't own their own pair of wellies... it's a simple proof, but a positive one:

Your [software design], at least, is [a pain...]

Well, true, but if one draws a correlation between the mind of the creator and the created-UI, I'm at least vaguely improving, given how messed up my mind is. WinAPI is difficult, you know, considering a year ago I could only but write scripts. GCC v7 is out now, apparently - and it's still easier to talk about Vermeer's influence on the modern age than it is to actually transmute his essence onto the banal reality of checkboxes and listviews.

[Tuxman]

I, in my muckier-than-thou attitude, define "city-boy" as anyone who doesn't own their own pair of wellies

I do, but they have had the wrong size for almost twenty years now.

A propos size: I actually doubt that GCC is a nice environment for anything related to WinAPI development. Carefully adjusting your bits and bytes to work as low-level as possible and then using an inadequately crafted giant blob of overengineered software which had nothing to do with the WinAPI in the first place is like drinking coffee right from the pot: it works, but there are more convenient ways.

But, indeed, it could be worse - you could use some of those modernish JavaScript UI compilers instead.

[pj]

Ah hah! I knew the old cynic was still reading even when he pretends not to. Remember, a more symmetrical context menu can set you free! Really! Every now and then even PJ makes a worthy complaint.

As opposed to an UNworthy complaint?

Even though I tried to limit my "complaint" (i.e. "suggestion") to something totally logical and didn't bring up some of the other inanities of the UI (watch the buttons when you resize an "organize" dialog box ), I still got the same brush off that is all-to-often the response from this developer (refusing to speak his name, kind of like "Voldemort").

No different from my other reasonable suggestions (temper tantrums? Hardly!), and many of those have been seconded and thirded (persistent tab history, copyable toolbars, etc.).

[Kilmatead]

As opposed to an UNworthy complaint?

Well, worthy in the sense of the lad who cried wolf... one thing leads to another and before you know it, the stork is bringing you a special unwanted bundle of peculiarities. I'm doing my best to at least pester him into a hissy fit on this one, so maybe sometime in 2023 we'll see some type o' symmetry.

watch the buttons when you resize an "organize" dialog box

Oh, well spotted... Nikos, you've got a TOOLBARCLASSNAMEW with a horizontal WM_SIZE deficiency. How loverly.

[Kilmatead]

I actually doubt that GCC is a nice environment for anything related to WinAPI development. Carefully adjusting your bits and bytes to work as low-level as possible...

Not so bad as all that... MinGW takes much of the pain out of it... in fact about the only thing I've seen that needs special attention are AcceleratorTable definitions on x64 builds must be even-numbered arrays (even if that means superfluous allocations) because the struct tablesize is mis-aligned by 6-bytes compared to x86 builds. That said, that's a WinAPI fault in itself, and not compiler-specific. Really, outside of curious anomalies like that (and some funky linker directives), there's not much to complain about.

And the best part of GCC is that it takes up very little space (compared to the monolithic MS and Intel compilers), requires no installation whatsoever, and is thoroughly well documented (as open-source goes). Sure, it's a tad over-provisioned (Ada? Fortran? Really?) but I'm sure somebody out there appreciates the nostalgia.

Astonishing project, actually, considering it's wholly free, ISO-compliant (when you just have to satisfy your daily lambda-craving), well supported, and used by oodles of stoners looking for a quick fix. Heck, it even has its own curious support for nested-function definitions, just to stave off boredom. I'm a fan, anyway.

[Tuxman]

And the best part of GCC is that it takes up very little space (compared to the monolithic MS and Intel compilers)

Unless you already use Visual Studio which reduces the additionally used bytes to 0.

Sure, it's a tad over-provisioned (Ada? Fortran? Really?) but I'm sure somebody out there appreciates the nostalgia.

Fear not: GCC's newest hipster competitor LLVM has recently got a Fortran compiler too. I'm still waiting for a Modern COBOL version though.

considering it's wholly free, ISO-compliant (when you just have to satisfy your daily lambda-craving), well supported, and used by oodles of stoners looking for a quick fix.

The relative "freedom" of GNU licenses could (and should) be worth an entirely separate discussion. I don't really think a license that basically states that I am required to respect approx. 346,534 pages of "don't do that" is really "free" in its relevant meaning(s).

But the primary reason why I refrain from using the GCC compiler for my C/C++ things is that its ISO compliance, while granted for well-hung standards like C++0x or so, struggles when it comes to newer language features. I started doing things with C++17 when it was "feature-frozen" and available in Microsoft's compiler (VS 2015+) and I still could not figure out why current GCC versions reportedly can't understand what a <filesystem> is; plus, GCC seems to have a very different perception of C-isms like put_time. I thought the advantage of a standardized language with compilers for a shitload of platforms was that you would not have to rewire your precious features for every single one.

Microsoft's compiler never complained here.

[Kilmatead]

Unless you already use Visual Studio which reduces the additionally used bytes to 0.

Ah, but what was the overhead of the VS download in the first-place, never mind disc-space, registry flogging, and endless endless endless updates of .NET? (And I mean frikkin' endless.) A fully-stocked dual-compiling x64/x86 MinGW download is 45 megabytes (compressed). That's it. No runtimes, no DLL-hell, no muss no fuss. Add a few extra MB for the IDE of choice, and you're done. No further overhead, not even any need for environmental variables if you bother to get that granular. The MS download is... um... how many Gigs? And that's without even any offline MSDN dox, as have been absent since 2010, I think. Exactly what do they put in their multiple Gigabytes? Windows Phone SDK's and SQL updates? Hmm. I like my 45 megabytes, thank you. But then, I am just the gardener - I can live without Clouds and Servers and all that spooky stuff that... oh wait... isn't most of that just Linux under-the-bonnet anyway?

But the primary reason why I refrain from using the GCC compiler for my C/C++ things is that ISO compliance

If I recall correctly, ISO-compliance is sort of a "what goes around comes around" thing with both GCC and MS... back for C++11 GCC had the full support for years while MS just decided to ignore its users for some reason (the grumpy-gits on Stack Overflow never seem to shut-up about it). Since then MS learned its lesson and decided to get out in front this time... but just wait another decade, and the roles are bound to be reversed. Being in the wonderful position of simply ignoring the monstrosity that C++ has become, I, of course, am unruffled either way - you like the new toys and shiny stuff, but I'd wager most MS users are fairly indifferent and would probably prefer optimisations over gimmicky semantic "advances" that most will never bother learning. But... who knows? On Windows there are no doubt more of you and there are of me... but cross-platform? Oh, wait... MS cross-platform? Hmm. (True, GCC is not technically a real cross-compiler set, but at least they're not completely solipsistic.)

[Tuxman]

Ah, but what was the overhead of the VS download in the first-place, never mind disc-space, registry flogging, and endless endless endless updates of .NET?

You cannot really compare that. (Well, you could, but it would not be fair.) But I admit I started this, so you are probably fine here. Stupid me!

However, comparing "the Microsoft compiler" to MinGW stating "no runtimes, no DLL-hell" probably misses the point. Last time I checked MinGW (at least the 64-bit version), there were a lot of DLLs involved. Of course you only need one version of them for one version of your linked libraries - but that is also true for cl. If there was an acceptable C/C++ compiler for Windows which does not break WinAPI and/or C++17 support while not requiring me to deliver numerous DLLs with my application, I would try and give it a run for reasons outlined below - but there is none which is not Microsoft's. Well, I can arrange with that.

The good news is that Microsoft's cloud stuff is not "all Linux", their Azure thingy can run Windows and even the venerable FreeBSD. The question of the importance of cloud-related stuff is one we both would probably answer quite similarly because we are no young, ascending talents who try to sell security-untested lifestyle gadgets to PHBs (not even you).

you like the new toys and shiny stuff

Ha! Seven-and-a-half years of being me on netez and you still did not quite understand what is important to me. Remind me to never marry you.

I like to play with things (text editors, programming languages, weird operating systems), but I prefer my productivity with a low overhead. No graphical IDE for anything that does not have a GUI and no dependency hell for anything I want anyone else to use; which is why I try to keep as close to the standard library as possible, using header-only third-party libraries for most things that go further than what std:: gives me. (Take this, JavaScript with your abstruse npm disk-filling pile of dust!) -- Before C++17, the standard way for traversing the file system was to use the Boost libraries, a good example for how a collection of libraries should not be distributed. Simplicity and standard-compliance are not shiny stuff in my (limited) world.

The next step into simplicity is to get rid of the object-orientation which is probably overkill for most of the desktop/server applications I write - more C, less plus-plus. (Yup, still not bored). Now here is where my current problems begin: Microsoft declared that C is a third-class citizen in their ecosystem at best. The current C11 standard is supported by Microsoft's libraries, but their implementation lacks features like native threads, enforcing third-party solutions on Windows, bloating the innocent little language. As far as I know, none of the relevant C compilers for Windows come with a standard library with support for C11 threads. New toys? 2011! I did not even use a C compiler back then.

And of course Microsoft is cross-platform-aware - their Android apps are quite nice and Visual Studio is actively targeting ex-Delphi developers as of today, aggressively advertising the all-new Xamarin framework toy, allowing you to write horrible C# code for all relevant mobile platforms alike. I wish they'd port it to C++ though.

[Kilmatead]

Last time I checked MinGW (at least the 64-bit version), there were a lot of DLLs involved.

Well sure, as part of the compiler (no one ever said you had to use them, or worse, redistribute them). And almost all of them are for C++, not C. I was referring to just the simple ability to write a "clean" Win32 GUI-based application that didn't require any extra redistributables to run on any given machine. I always found it curious that C++ seems to expect people to use stuff that isn't actually part of the language in the first place - being a "purist" from my younger days, overblown "helper libraries" like Boost just seem heretical to me. Sure, few people are capable of writing their own RegExp library, so allowances can be made - but when almost everything that is needed to do basic tasks is already available in the WinAPI (with the default installed DLL's), why use "extra" stuff that only promises to make things easier? (WTL, MFC, yada yada). For example, as far as I know, pthreads (when implemented on Windows), more or less just wraps the WinAPI threading functions anyway and lets those suffer the overhead... which begs the question, why not just use Win32 threading? No need for <Threads.h> or any of that. Most of it's been there since at least Win2000, so why do you pine for c11 threading? C never had (nor needed) that stuff since its inception; the standards of today are just tomorrow's obsolescent detritus. Or is this a "if I learn it, they will come" sort of philosophy?

Simplicity and standard-compliance are not shiny stuff in my (limited) world.

And yet you never learned much of Win32. Why not? It's all there, and (more or less) always has been. Filesystem handling, threading, UI's, etc. (Ok, yes, that's not strictly true in the canonical sense, but it's true in the practical sense of "if it works on XP, it's already available".) True, it's all deplorably Windows-specific, but if you want one ring to rule them all, just stick your finger down your throat and use Java. And just get over the dirty feeling you have the morning-after.

And not to shoot the elephant in the room, but you are aware that clinging to standard-compliance as a way of protecting yourself is... well... very German? (I mean that in the nicest way possible - and I have 3 ex-girlfriends who all happen to be German themselves who will testify that I don't always accurately say what I mean. They forgave me. Eventually. ) For the record: 1) The Black Forest, 2) Munich, 3) Austria. #3 is the only one I regret losing. Long story. She always knew what I meant to say, which is a difficult trait to find in ladies of recent centuries.

And of course Microsoft is cross-platform-aware - their Android apps are quite nice and Visual Studio is actively targeting ex-Delphi developers as of today, aggressively advertising the all-new Xamarin framework toy, allowing you to write horrible C# code for all relevant mobile platforms alike.

Cross-platform in the sense that MS itself is trying to be cross-platform in a shallow form-factor sort of way. If .NET's the disease, UWP is the cure. At least, that's what the marketing lads keep chanting (using other words). I reject the so-called future. (Really, I do. It's my only luxury. Reading a lot of history [and Nietzsche] really does give one a perspective on the futility of hope.)

[Tuxman]

Well sure, as part of the compiler (no one ever said you had to use them, or worse, redistribute them).

I never really felt the urge to use MinGW for something loosely related to application development. I did some Cygwin stuff a few years ago and I vaguely remember that Cygwin always required me to spread its wannabe POSIX layer DLL with my applications or else. If MinGW comes without this regression, I'll just pretend I never assumed otherwise. -- And yet there is a lack of reason to use something else than cl as long as cl is available.

being a "purist" from my younger days, overblown "helper libraries" like Boost just seem heretical to me.

See, the newest C/C++ standards make most of those "helper libraries" (if C++2x comes with std::asio, add one more) obsolete by having that "shiny stuff" suggested as required language features, making it much more likely that code you write will run on someone else's machine without modifications - and, of course, without using a different operating system. You should rather like that. I agree that "WTL, MFC, yada yada" come with their own failures (the largest possibly being that there is no actively recommended and developed GUI framework for pure desktop applications anymore if you do not intend to dig into the ugly waters of the WinAPI), but new language features as such do not count into that.

With one of my newest pet projects (in C) I am trying to make sense of Winsock which has a couple of WinAPI-related syntax specialties, already killing my sense of asthetics. The Windows header files behave quite differently from the rest of C in terms of usage. Using the WinAPI in C is almost like using Qt in C++: Somewhere below there is the actual language... so I never even felt a traction strong enough to make me read about what that API can actually do. (This is the first time I even think about Win32 threads for anything - multi-threading adds complexity where it could not be necessary, but this time threads are a crucial part of the application design.)

Even worse: Most of my younger projects are aimed at multiple platforms. It violates my own sense of good software development to restrict myself to one operating systems without a technical need to do so. Artificially creating such a need (replacing language features by OS features which internally do the same thing anyway) is a bad move and will (probably) not pay off. Sure, you don't have this choice on x86 ASM where it is basically "call the OS APIs or die trying", but this is C - C can, in theory, do the same things (minus GUIs unless you tell it to) even on non-Windows platforms; as long as the libc supports them, that is. Writing deplorably Windows-specific software is fine as long as you do not intend to ever use a second operating system and/or to distribute it to a larger community of people - or if the software itself would not make sense on other operating systems in the first place.

Of course I could just use a higher-level language with more language overhead than actual lines of code. (Do I really sound like a Java guy to you? I need to work on that!)
I'm sure you could also light a cigarette with a flamethrower - but you probably shouldn't.

So let me counter your question:

why do you pine for c11 threading? (...) Or is this a desperate "if I learn it, they will come" sort of philosophy?

Why should I use an OS-specific implementation of (probably) identical machine code when the language I use (allegedly) provides a well-defined and portable way to achieve the same goals on older OS versions or even niche systems? C is unlikely to lose any features (minus some syntax weirdness as seen in K&R C) anytime soon, it will probably survive the WinAPI as it stands.

And not to shoot the elephant in the room, but you are aware that clinging to standard-compliance as a way of protecting yourself is... well... very German?

Hey, take that back! - Oh, right...
I am not sure how other countries treat their C/C++ compilers but in the end the standard decides about your code, not your nationality. (If the compiler speaks the chosen standard, of course.) I could imagine that Austrian German girls might be an exception to this rule, but it still stands as a rule. Compilers are rather female in some of their decisions.

[Kilmatead]

...there is no actively recommended and developed GUI framework for pure desktop applications anymore if you do not intend to dig into the ugly waters of the WinAPI

Ugly is as ugly does... one of these days I'll look into Qt as a going concern, but every time I sit down and say "Today's the day!" I find some reason to get up and clean the loo. Maybe it's just me? GTK+ finally got me to clean out the kitchen cabinets, so that was fun. I find the WinAPI amusing in a masochistic sort of way... there's something comforting about buggy things that haven't really changed in the whole of this century.

multi-threading adds complexity where it could not be necessary

But it's a really satisfying feeling once it's all working together and the pain is over (except for the living-in-fear-of-breaking-it shadow during the featurecreep phase) - just think what we'd be listening to if Johann Sebastian Bach hadn't embraced multithreading himself? It'd be the Mannheim Steamroller Christmas album all over again. Suffer for the good of future generations.

It violates my own sense of good software development to restrict myself to one operating systems without a technical need to do so. Artificially creating such a need (replacing language features by OS features which internally do the same thing anyway) is a bad move and will (probably) not pay off.

I have to agree conceptually... though not actually having ever written anything even vaguely useful in non-Windows my opinion on this is regrettably meaningless. I do, however, have a Mint KDE VM that is more demanding than an unfed puppy, so who knows? Suffering comes to us all in the end through the choices we make. Yes, Mint, yes, KDE. I know, I know... but... it's... sooooo... shiny...

C is unlikely to lose any features (minus some syntax weirdness as seen in K&R C) anytime soon, it will probably survive the WinAPI as it stands.

Yeah, but since the WinAPI is itself written in C (not C++), it's still got that old-slipper feel to it, once you get past the rough edges. And don't knock K&R - I spent many sleepless nights in prayer with that book while you were still in nappies. It was the first book (well, after Camus' L'Etrangère) that I actually wore out the binding on. I used to carry it with me when I was bundled into the back of the car for unwanted family holidays - if that ain't language portability, I don't know what is. It even went to Disneyland once, which seemed somewhat fitting.

Compilers are rather female in some of their decisions.

I really think that needs to be in a larger font, just to remind the JIT crowd what life in the real world is really like.

Compilers
are
rather
female
in
some
of
their
decisions

Ok, I'm happy now.

[Tuxman]

one of these days I'll look into Qt as a going concern, but every time I sit down and say "Today's the day!" I find some reason to get up and clean the loo.

I guess that's not what they meant by "Qt is everywhere".

But you would probably like it: Qt-based UIs are shiny! Its license suggests you not to link statically either, so the application itself can be almost as small as a pure WinAPI implementation, minus the numerous required libraries, of course. It seems that the Qt team is repeatedly breaking a majority of its APIs as well, perfect for sadists; Common Lisp's Qtools still don't support Qt 5.x because of missing upstream requirements. Portability for Windows developers who happen to know more than one programming language is an amusing topic. Yes, Qt; yes, KDE! ...

there's something comforting about buggy things that haven't really changed in the whole of this century.

... Have you considered to use a real Unix in your virtual machine instead? Motif is still a thing in 2017!

Mint was my next-to-last Linux desktop distribution; I gladly got rid of it some day. While I appreciate the focus on being relatively user-friendly, it hinders my productivity with its shiny effects. I discussed a similar issue on one of those BSD forums these days: Does Qt/KDE miss the point? It would not feel right to me to spend most of my time with my desktop environment instead of actual applications.

not actually having ever written anything even vaguely useful in non-Windows my opinion on this is regrettably meaningless.

I rarely write things which are only useful on Windows. Portability is still an issue: because of varying definitions of which "standard" is "the standard", working portability is mostly an accident. I sadly admit that a language with its own portable bytecode VM (still Lisp, not Java) works better for me than C/C++ in this regard, but giving up does not grant me a trophy either. As long as it's just a hobby which nobody pays me for, everything is fine.

And don't knock K&R - I spent many sleepless nights in prayer with that book while you were still in nappies.

I would never knock K&R. They invested too much time for a good cause (namely, C). - I find books to be too slow for me though. Learning by doing (and randomly reading other people's code) is my preferred way to grok the basics of a language to build upon. I wish I was able to understand the alleged greatness of the usual programming books one - according to the internet - should have on his shelf, but I am not patient enough for that. Live fast.
Disneyland, eh? Heretic!

Ok, I'm happy now.

Now that was easy. Females could learn a lot from you.

[Kilmatead]

Ok, I'm less happy now - it appears Qt is aimed squarely at C++, and is (much like raw COM) apparently somewhat painful to use in proper C (not impossible, just irritating); I am not slumming it in C++ just to become a cross-dressing masochist in my old age. And yeah, the redist's seem somewhat disturbingly multiple, as well. As GTK+ is the suggested alternative (being itself written in C), I might have to revise that instead. Bummer, all things Gnome just can't seem to shed that brown stain from their CV's.

And... double-bummer... a quick look shows that the "necessaries" for GTK+ aren't exactly minimalist either (19 DLL's , WTF?). Now I remember why I started learning Win32 UI in the first place...

I find books to be too slow for me though

I'm speaking about that mysterious age before this internet thing wrecked everyone's long-term memory: I was reading K&R before I could even afford the cheapest compiler available, which is otherwise known as "learning a language the hard way". I had to fudge my own C interpreter in Turbo Pascal just so I could learn to predict what "might" happen when I eventually obtained a real compiler. Code snippets were rather hard to find too (for a kid), since C wasn't exactly as widespread on third-hand IBM knock-off desktops back then, so nobody I knew could help. Thus, my dog-eared K&R was the Alpha and the Omega, the Second Book of Revelations, etc.

Learning in a vacuum is a lost art: books fill the void.

[Tuxman]

Indeed, the number of C UI frameworks which are not statically bolted upon the Win32 nightmare is small. GTK+ as the standard still has similar issues as Qt has, minus its shinyness but also including licensing restrictions which make redistribution gross, at best. Outside C, the grass is much greener, redder, bluer... deciding about which C++ UI framework to choose can triple the total project time!

Now I remember why I started learning Win32 UI in the first place...

Because Windows has a serious lack of decent UI frameworks with an available C wrapper, probably. The only good ones seem to be libui (which lacks a tree widget) and IUP (which lacks a public git-or-whatever repository which seems to be required for the youngsters of today to take notice of a software project).

Also, Tcl's Tk - but you're into shiny things so this is already out ...

I was reading K&R before I could even afford the cheapest compiler available, which is otherwise known as "learning a language the hard way". I had to fudge my own C interpreter in Turbo Pascal just so I could learn to predict what "might" happen when I eventually obtained a real compiler.

Wait - didn't Turbo Pascal have Borland's compiler built-in? So you had a compiler - for a language other than C though. But even then, you could have afforded the cheapest C compiler available: the first free C compiler was available in 1972. It stopped being free when AT&T decided to put a license fee on the Unix tapes.

Probably not too relevant for Windows-only guys, I assume.