I don't see "on-premises" as a general option for a future disgruntled enterprise customer. I know that the binary choice of one vs the other is the current way of thinking. But actually, when you think about 'cloud' and 'local' in their limiting cases (ie, all cloud vs all local), then compare the two, you only really have somewhat of a case to go on-prem if you are a huge enterprise since the other limiting case is a single human being doing computing with himself, like playing cards on a PC. But even for large enterprises, detailed connections with the outside world are just as imperative as they are for a small business or even individuals doing anything on the computer. The above is true and will remain true, in my opinion, as long as the case for individual human beings doing computing remains impractical regarding establishing sets of durable end point to end point connections with the outside world. From this scenario the cloud is merely a kind of a superfluous man-in-the-middle. But that discussion is too far away from the OP's disaster shout-out.

There is no doubt that Big Tech will continue to shore up against competition and keep pouring resources into their model in the hopes that their "anything can fly if you give it enough power" model/belief has no limits. Noone really believes that, though. My point was to critique the assumption that nothing will happen that will upend the centralized model probably within the not-too-distant future, fx, <10 years, which, if true, puts a big hole in the linear-scalability-only prediction model.

There is more than one way to look at scalability where the typical way is linear (Big O(n)). But this leaves out another important factor, the centralized SQL/RPC's dependence on single-enterprise industries here called server farms. There is a probability and lifetime associated with these enterprises. GE and IBM have lasted a long time but both companies are fractions of their former sizes. The same is true for server farm enterprises. Just a wild guess but I'd say there is a 50% chance that Microsoft's Asure will collapse within 10 years. Same goes for AWS, Google and Apple. I might be wrong as much as an order of magnitude, but it is indisputable that single-enterprise centralized server farms' existence is a non-negligible factor. So when I say non-scalable, I am combining superficial linearity that the RPC/SQL algorithm suggests (O(n)), with their fallibility (fx, O_p(0.5) over fx 10 years). Then from that perspective, the current set of server farms is not scalable. And I haven't even considered other even very real factors like security with respect to facility centralization. Note that, when I say failure, I don't mean existential failure (ie, breaks down completely). I mean failure like for example, the enterprise's price keeps climbing losing more and more customers. Or attacks increase and the company fails to fix the problems in a timely manner if ever. Etc.

The only disaster here is why in the first place you would ever use a monopolistic, ultimately centralized and therefore non-scalable service, architected with an ancient and flawed for this purpose technology (SQL). Let me guess: expediency and convenience. What goes around, comes around.

I agree. When working on code with Copilot I start out with the code context. Then I explain my problem and include the compiler error message. Copilot commiserates and rewrite my code, improving it. Then it offers alternatives. The more descriptive your prompt, the better the answer. I never ever expect Copilot to design or architect for me. I can already barely remember the time when I had to look up obscure syntax and battle, in my case, Microsoft regarding documentation errors and get rebuffed with "Need more information" and "Not important enough" and issue is "closed".

Never have. Never will. Why would I trust a technology that's a throw-back from the main frame time-sharing era? Why would I trust a technology that by the very act of copying data elsewhere nullifies your real ownership of said data? Centralized computing has no plan B other than when disaster happens, just pick up the pieces and make the best of it. Centralized computing is not scalable. I often ask myself why no one else is working on a truly distributed solution. Crickets. I simply don't get it.

Here is a different view: Ever since programming began, defeating compiler-enforced typed safety became an obsession of many programmers. And IMO pointers were their main tool as it gave the programming arena a natural layer-of-indirection. Be that as it may, thankfully, there is a great movement in C++ from programming with pointers, pointer semantics, to value semantics. With that, C++ "is like a different language" paraphrasing Bjarne. Value semantic programming gets really difficult, but that laudable goal is the re-assertion of compiler-enforced type safety without man-in-the-middle pointers. And compiler-enforced type safety was the original goal of C++ which Bjarne has single-handedly urged the C++ maintainers to adhere to over the years. IMO this will separate the programming sheep (get it done fast) from the goats in the future. Just saying.

Microsoft Lumia 950. It cost a little over $100 and keeps me from having to engage in Big Tech's iPhone/Android duopoly. Does all I need it to do. Since Microsoft is steadily turning off more and more of its features through forced 365 subscriptions and certificate extortion, I'm thinking about upgrading to an HTC smartphone for $261 which was produced in 2012. I'll give it another few years, though, just to see what happens. Don't wanna be too hasty here.

I've been programming in MFC C++ since its inception. And Microsoft has been maintaining it completely. MFC has survived and been significantly enhanced by all of the C++xx upgrades. Just yesterday, after working all day with Copilot, we finally solved a particular coding goal of being able to instantiate either a common implementation or a specialized implementation controlled by one explicit template line of code. All type safe. All ODR compliant. Anyway, my point is, MFC has always been the most future-protected choice for me and well as close-to-the-metal performance, all without inserting extra layers of indirection. Ever since I read Jeff Prosise's book on MFC where he wrote about the speed and coding beauty of the low-lying connection to the OS, I was hooked. A layer of indirection means you are dependent on that vendor's development whims which jeopardizes your code. Yes, I am dependent on Microsoft, but my C++ code is by and large not and could be ported. That can't be said of my code if I were dependent on other layers and ephemeral programming languages. I want my code to survive forever. Is that so bad?

The New York subway system still runs on OS2. And Amtrak is probably still running on Visual Studio 6.0. The point being, it is really really hard to re-engineer an existing system. Sort of like re-building a skyscraper without tearing it down first. In other words, real code maintenance (aka, evolution) does not really exist yet. Monthly OS updates is not really a solution now is it.

My first degree was a BS in EE. Then later I studied on my PhD in Adult Learning (all but dissertation). Then I got my MA (equivalent) in Language Psychology, and only then did I go back and get my MS in CS. Today, I use the knowledge from all 4 university studies daily as a hard-core C++ MFC programmer 40 hours a week and have done so since 2012. It is completely exhilarating. Education rules.

There is no "everything else" when you are squeezing out the next dev action.

I guess if you are getting f****d in the a** and there is nothing you can do about it, then it is best not to think about it? Is that your position?

"probably SAS. In Oil and Gas, I would be inheriting FORTRAN and PL/I and APL. If on Wall Street, perhaps COBOL, CICS and IMS" Ask yourself where you will be regarding skills after you work at a job for 4-5 years using, say, Ruby (insert latest fad language). Are you going to let a know-nothing manager make that career decision for you?

Two natural languages on a daily basis, but only one computer language, C++. I hold two masters degrees, one in computer science and the other (bifag) in language psychology. So let me say this. From my viewpoint, learning several languages for real as an adult is exceedingly hard, bordering impossible. Our brains have long since been pruned mostly out of that capability. This means learning a fad computer language owned by a few gurus or even a large corp, that will he gone in a few years, is a ridiculous approach.

I'll stick with C++ MFC and GDI thank you. MS it's finally doing a great job on the docs. It only took them 40 years. Churchill was right: you can always count on the Americans to do the right thing...after they have tried everything else.

File transfer using Skype has always worked for me. Just don't make the mistake of centralizing your PCs under a Microsoft account. They will push you in that direction at every opportunity. Create an email account for each of your PCs and use that email to sign in to each of your PCs. No need for an A to B wire. My 12 PCs are mostly ethernet-connected desktops but some are Wifi-connected. Skype used to be P2P, but after Microsoft took over your files will still have to go through their server farm. They didn't used to. But consider this: Skype to Skype transfer of files, any size, anywhere, is still free. And that's probably why they are trying to extinguish Skype with their Teams product. But for now, Skype is certainly a proven technology and is to be preferred over some obscure A B connector technology. Finally, Microsoft PC file sharing ACL is a nightmare. Always has been. Always will be.

The link draws radio buttons, but doesn't really use MFC buttons. I am working on a solution that drops the need for CListBox.

I see many code projects that enhance the CListBox control, but none that lets each item be another control, like fx CButton. How would one implement that?

class MyListBoxView : public CFormView
{
...
CListBox m_wndListBox;

MyListBoxView::MyListBoxView()
: CFormView( IDC_LIST1 ) // ID is a LISTBOX control in another .rc file
{
Create( WC_LISTBOX, L"My devices", WS_CAPTION | WS_CHILD | WS_VISIBLE, CRect( 0, 0, 0, 0 ), this, IDC_LIST1, ( CCreateContext* )NULL );

**Create** fails at:

if (!_AfxCheckDialogTemplate(m_lpszTemplateName, TRUE))
{
ASSERT(FALSE); // invalid dialog template name

I have tried to do w_wndListBox.Create(...), but CFormView::Create is protected and can't be called from outside. I have also tried to call Create in MyListBoxView's ctor, using the static call form (CFormView::Create), but that fails because Create, of course, is not a static and you can't call non-statics from a static. So I must have the class and object structure wrong for these calls not to work.