"The State of C++ on Windows"

[Lynn McGuire]

"The State of C++ on Windows"
https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/

According to Microsoft.

Lynn

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<q2nm2r$jdr$1...@dont-email.me> thusly:

>"The State of C++ on Windows"
> https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/
>
>According to Microsoft.

Not really; it's according to Kenny Kerr. He is the primary author of
the C++ projection for WinRT and he's done quite a good job at it IMO.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Cholo Lennon]

Lucky me that I don't have to program for Windows/Microsoft anymore...

It's been a long road since DOS days... DOS API, Win16/VB3/MFC/OLE,
Win32/MFC/ATL/WTL/COM/VB5-6, .NET/C#, Managed C++, C++/CLI (my last
engagement with Windows back to 2007) and after that WinRT, UWP, WRT,
C++/CX, C++/WinRT, .NET Core... wow, what a mess! :-O What else is
next? The neverending story of Windows development.

At least C++/WinRT looks promising because it's only standard C++17.

--
Cholo Lennon
Bs.As.
ARG

[Alf P. Steinbach]

Microsoft claims, at <url:
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt>,
that

“With C++/WinRT, you can author and consume Windows Runtime APIs using
any standards-compliant C++17 compiler.”

Has anyone tried to use MinGW g++?


Cheers!,

- Alf (not very up-to-date)

[Sam]

Sure. The language itself it's written in will probably be C++17. But, the
historical problem with Microsoft's APIs isn't the core language itself,
it's the limited lifetime of their APIs.

What were the leading MS-Windows APIs five years ago? Ten years ago? Twenty
years ago? Are they worth anything today? Can you actually put them to use,
right now? Of course, the answer is no.

But just yesterday, I was hacking something on Linux, and used a little bit
of something that, oh, I don't know, I learned 20 years ago, perhaps?

Every Microsoft technology comes with a built-in expiration date. If you are
a Microsoft Windows developer, your main job description is to generate
recurring revenue to Microsoft; to purchase their documention, MSDN
subscription, et. al., in order to actually be able to do something on
Microsoft Windows. And Microsoft has every reason to periodically obsolete
and replace every technology on their platform; otherwise there would be no
reason for anyone to continue paying Microsoft for their development tools
and documentation, or to pay for training.

Meanwhile, everything I ever learned on Linux continues to be valid today.
It never went to waste.

Whatever this thing "C++/WinRT" turns out to be, it's a safe bet that in 2-3
years time it will be replaced with another shiny new ball, and every last
bit of time everyone spent to learn it will go completely to waste, like all
their alphabet soup of the years past.

[Chris Ahlstrom]

Lynn McGuire wrote this copyrighted missive and expects royalties:

> "The State of C++ on Windows"
> https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/
>
> According to Microsoft.

At the moment I have a project that builds and runs on both Windows and Linux.
It uses Qt 5 for the GUI, and host-specific APIs for the audio and MIDI
support. I am in the process of refactoring it for C++14.

That's about as much as I care about C++ on Windows. Not big fan of Microsoft
"technology". Tends to be a will-o-the-wisp. At least Qt 5 seems to be
<cough> stable.

--
Q: How many marketing people does it take to change a light bulb?
A: I'll have to get back to you on that.

[Paavo Helde]

On 3.02.2019 15:34, Sam wrote:
> Alf P. Steinbach writes:
>
>> On 03.02.2019 08:48, Cholo Lennon wrote:
>>>
>>> At least C++/WinRT looks promising because it's only standard C++17.
>>
>> Microsoft claims, at <url:

>> https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt>,

>> that
>>
>> “With C++/WinRT, you can author and consume Windows Runtime APIs using
>> any standards-compliant C++17 compiler.”
>
> Sure. The language itself it's written in will probably be C++17. But,
> the historical problem with Microsoft's APIs isn't the core language
> itself, it's the limited lifetime of their APIs.
>
> What were the leading MS-Windows APIs five years ago? Ten years ago?
> Twenty years ago? Are they worth anything today? Can you actually put
> them to use, right now? Of course, the answer is no.

Playing the devil's advocate, I have found the Windows API itself pretty
stable. The Windows API calls I wrote into my programs 20 years ago are
still working fine: LoadLibrary(), GetModuleFileName(), VerQueryValue(),
RegOpenKeyEx(), MessageBox() etc.

I guess you are complaining about not the Windows API, but about API-s
for various overhyped software frameworks developed by Microsoft as it
thinks it has to bring something new to the market every now and then.
You cannot compare these API-s to the Linux API-s. These framework API-s
would be more similar to API-s of specific applications or frameworks
built on top of Linux, e.g. Netscape, Firefox, Qt etc. And for example,
even though the Netscape NPAPI outlived Netscape for many years, it is
now being deprecated and mostly removed from the browsers. The same has
not happened to MFC which is about the same age and is still supported
by MS.

I am not a MS supporter, but back-compatibility is actually one of their
strongest points.

[Bart]

On 03/02/2019 14:57, Paavo Helde wrote:> On 3.02.2019 15:34, Sam wrote:
>> What were the leading MS-Windows APIs five years ago? Ten years ago?
>> Twenty years ago? Are they worth anything today? Can you actually put
>> them to use, right now? Of course, the answer is no.
>
> Playing the devil's advocate, I have found the Windows API itself pretty
> stable. The Windows API calls I wrote into my programs 20 years ago are
> still working fine: LoadLibrary(), GetModuleFileName(), VerQueryValue(),
> RegOpenKeyEx(), MessageBox() etc.

I agree. I still use the same API calls that I started using in the
early 90s. And backwards compatibility has been superb, even being able
to run the same binaries decades later (until they stopped Win64 from
running Win16 programs, but a current win32 will still run them).

(I didn't progress to later APIs, eg. GDI to GDI+, because they started
using real C++ interfaces. Although the old interfaces like GDI are
labeled C++, they are really C. I normally access WinAPI from different
languages, and C++ is much harder than C for that purpose.)

> I guess you are complaining about not the Windows API, but about API-s
> for various overhyped software frameworks developed by Microsoft as it
> thinks it has to bring something new to the market every now and then.
> You cannot compare these API-s to the Linux API-s. These framework API-s
> would be more similar to API-s of specific applications or frameworks
> built on top of Linux, e.g. Netscape, Firefox, Qt etc. And for example,
> even though the Netscape NPAPI outlived Netscape for many years, it is
> now being deprecated and mostly removed from the browsers. The same has
> not happened to MFC which is about the same age and is still supported
> by MS.
>
> I am not a MS supporter, but back-compatibility is actually one of their
> strongest points.

Despite my comments above, MS' APIs are actually pretty terrible. Just
compare CreateFile() to C's fopen(). They like to make them as complex
and elaborate as they can, and every function seems to invent yet
another set of typedefs, structs, macros, and messages.

However, I understand that X11 isn't much better.

[Cholo Lennon]

Not me, but it would be a good exercise in order to test the Microsoft
marketing :-)

[Öö Tiib]

On Sunday, 3 February 2019 15:50:38 UTC+2, Chris Ahlstrom wrote:
> Lynn McGuire wrote this copyrighted missive and expects royalties:
>
> > "The State of C++ on Windows"
> > https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/
> >
> > According to Microsoft.
>
> At the moment I have a project that builds and runs on both Windows and Linux.
> It uses Qt 5 for the GUI, and host-specific APIs for the audio and MIDI
> support. I am in the process of refactoring it for C++14.
>
> That's about as much as I care about C++ on Windows. Not big fan of Microsoft
> "technology". Tends to be a will-o-the-wisp. At least Qt 5 seems to be
> <cough> stable.

Most big bonus of Qt5 (as compared to Qt4) is that
it runs on Android and iOS. Getting other platform-
agnostic stuff running on the phones and tablets
(like say SDL2) is way more painful. That is important
since desktops (and it doesn't matter if Windows,
Linux or OS X) are for armchair mushrooms, alive
people use handheld devices more than desktops.

[Alf P. Steinbach]

Isn't it impractical to develop on a phone?

I don't like typing on my phone, an Android thing.

Not to mention text selection and text operations in general.


Cheers!,

- Alf

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> Isn't it impractical to develop on a phone?
>
> I don't like typing on my phone, an Android thing.

Phone applications aren't developed on the phone itself.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Alf P. Steinbach]

On 05.02.2019 16:03, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> Isn't it impractical to develop on a phone?
>>
>> I don't like typing on my phone, an Android thing.
>
> Phone applications aren't developed on the phone itself.

But, then according the text I responded to, the developers are
“armchair mushrooms”, and that can't be right either?


Cheers!

Alf (probably an armchair mushroom (at least he uses a chair, and every
time he sticks his head up it's cut off, just like a mushroom)).

[james...@alumni.caltech.edu]

On Tuesday, February 5, 2019 at 8:01:22 AM UTC-5, Öö Tiib wrote:
...

> (like say SDL2) is way more painful. That is important
> since desktops (and it doesn't matter if Windows,
> Linux or OS X) are for armchair mushrooms, alive
> people use handheld devices more than desktops.

My desktop computer is far easier to use than any of my smaller devices.
My external mouse and keyboard are easier to use than my laptop
machine's built-in devices, and far easier to use than those of my cell
phone. I don't have a tablet yet, but if and when I get one, I expect it
to present the same kinds of problems with input that my cell phone
does. My desktop also has an external display that is much larger than
the displays built into any of my other devices. Why would I have to be
an "armchair mushroom" to appreciate these advantages?

Note: you might suggest that I should connect my external mouse,
monitor, and keyboard to my laptop, and of course that does resolve the
issues I've mentioned above. However, my desktop machine is much smaller
than my laptop, has twice as many HDMI ports, twice as many Ethernet
ports, and four times as many USB ports, and an MMC port. It does not,
unfortunately, have a battery. In any situation that doesn't require a
battery, and which does allow me to use an external mouse, monitor,
and keyboard, why should I connect them to my laptop instead of my
desktop machine?

[Öö Tiib]

On Tuesday, 5 February 2019 17:36:09 UTC+2, Alf P. Steinbach wrote:
> On 05.02.2019 16:03, Juha Nieminen wrote:
> > Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> >> Isn't it impractical to develop on a phone?
> >>
> >> I don't like typing on my phone, an Android thing.
> >
> > Phone applications aren't developed on the phone itself.
>
> But, then according the text I responded to, the developers are
> “armchair mushrooms”, and that can't be right either?

Part of my point was that we are. And we are tricky market, it is
awfully hard to sell anything to us. Lot of us use Vim or Emacs
despite there are plenty of free more sophisticated development
tools. OTOH when I try to develop by not typing (for example
using voice and/or gestures) then it looks insane from side and
also such alternative interfaces are slow and inconvenient.

[Manfred]

Not me, when I walk down the street and I see all those droids walking
with their eyeballs fixed on their displays, "The Walking Dead" comes
immediately to mind.
Just another reply from an "armchair mushroom".

[Richard]

[Please do not mail me a copy of your followup]

Sam <s...@email-scan.com> spake the secret code
<cone.1549200863....@monster.email-scan.com> thusly:

>-=-=-=-=-=-

>
>Alf P. Steinbach writes:
>
>> On 03.02.2019 08:48, Cholo Lennon wrote:
>>>
>>> At least C++/WinRT looks promising because it's only standard C++17.
>>
>> Microsoft claims, at <url: https://docs.microsoft.com/en-us/windows/uwp/cpp-
>> and-winrt-apis/intro-to-using-cpp-with-winrt>, that
>>
>> “With C++/WinRT, you can author and consume Windows Runtime APIs using any
>> standards-compliant C++17 compiler.”
>
>Sure. The language itself it's written in will probably be C++17. But, the
>historical problem with Microsoft's APIs isn't the core language itself,
>it's the limited lifetime of their APIs.

Just how much Windows programming have you done? Because backwards
compatibility is something that MS works very hard to achieve and when
it comes to the desktop APIs (which is what I now best), they have
been very, very stable for a very, very long time.

>What were the leading MS-Windows APIs five years ago?

Define "leading". Why does it need to be leading?

>Ten years ago? Twenty
>years ago? Are they worth anything today? Can you actually put them to use,
>right now? Of course, the answer is no.

OK, now I think I have the answer to my question above because you're
just wrong on this.

>Every Microsoft technology comes with a built-in expiration date. If you are
>a Microsoft Windows developer, your main job description is to generate
>recurring revenue to Microsoft; to purchase their documention, MSDN
>subscription, et. al., in order to actually be able to do something on
>Microsoft Windows.

Again, you don't seem to actually know what it is like to develop for
Windows. You don't need an MSDN subscription; you can't actually
purchase documentation anymore, it's all been on the web for free for
at least a decade, maybe 20 years at this point. You don't need to
purchase anything to use their development environment (Visual Studio)
for at least a decade, IIRC.

>And Microsoft has every reason to periodically obsolete
>and replace every technology on their platform

Nonsense. They don't do this.

>otherwise there would be no
>reason for anyone to continue paying Microsoft for their development tools
>and documentation, or to pay for training.

Most people don't pay for development tools and noone pays for
documentation. You're not supposed to use the free edition of VS if
you have >5 employees (IIRC) or something like that if you work on
closed source products. If you work on open source, you can use VS
community without any employee limit, IIRC. I haven't looked at the
license details in a while because it hasn't ever been a problem at
any place I've ever worked or in my own personal use.

>Meanwhile, everything I ever learned on Linux continues to be valid today.

...and everything I've ever learned on Windows over the past 30 years
is still valid today as well. Does it mean that Windows has stood
still as a target for developers? Nope, they've added new things and
those new things have (gasp) new APIs. The same is true on Linux,
just the dividing line between "OS" and "commonly used tools and
techniques" is at a different point for Linux. Tons of web stack,
virtualization and container techniques and tools exist now for linux
that didn't exist 5, 10, 15 or 20 years ago, depending on the tool.

Old stuff stays the same and new stuff is added all the time, whether
it is Linux or Windows.

[Richard]

[Please do not mail me a copy of your followup]

Bart <b...@freeuk.com> spake the secret code
<DID5E.535793$3si.1...@fx08.am4> thusly:

>Despite my comments above, MS' APIs are actually pretty terrible. Just
>compare CreateFile() to C's fopen(). They like to make them as complex
>and elaborate as they can, and every function seems to invent yet
>another set of typedefs, structs, macros, and messages.

If you want to use fopen, then use fopen. If you need more control,
then you can use CreateFile. It does things that fopen can't and
doesn't expose.