I built a Win 3.1 app during a company hackathon just for fun. Here, I detail learnings and process for how a new old app can be created with the aid of modern tools and hindsight of old technologies. And perhaps what lessons can it offer us today.
Without the benefit of modern libraries and languages, I had to read up and take care of many low level details, socket programming, HTTP, JSON parsing, UI design in code all under tight memory constraints. Nevertheless, it was a terrific lesson in understanding how things work under the hood.
I had to do things the old-fashioned way reading books and header files due to the dearth of online documentation. I can empathise with the plight of the programmers of yesteryears who had to code without the benefit of online search engines.
With this blog post, I hope you'll find it interesting to learn about developing a modern-ancient app for Win 3.1.
bet you had fancy pants autocomplete also! That was a game changer when it came along....otherwise you had to refer to docs/books.... not to mention the limited screen size.... two monitors? no one was that rich :)
I expected to be compiled in some kind of VM, not on an actual computer with Windows 3.11 :-).
I feel "old-style" documentation is much better than we have now. My most productive _python_ only work times were when I had only the python .hlp file and a _physical_ paper book.
I've been programming since 1983. The internet opened up publishing to the masses, which means that non-professional people could also publish, resulting in much more documentation than ever before.
But now the amateur documentation writers are competing with the professional ones; the quality of the professional documentation is still as high as ever, but it can be drowned out by the amateur quality documentation.
All in all, finding the information you need is MUCH quicker via a search engine, but the signal-to-noise ratio is lower.
The quality of Microsoft's own documentation has also fallen considerably; the latest nail in the coffin is that docs.microsoft.com thing that started to replace MSDN several years ago, that created tons of ridiculous fuckups in the "migration process". While doing that they also "open sourced" their documentation on GitHub, which to me sounds more like they're just trying to rely on free labour from the "community" to fix the mess.
One of the more memorable WTFs I've seen is this, which is still wrong as of this post:
See what's missing? The newer version is not the correct one... in "migrating" the document to the new site, for a reason that completely defines all rational explanation, the return type of the function declaration became void. There are plenty of pages on the new site with this serious error, and they've remained unfixed for well over a year. People report such problems on their GitHub, and they get fixed --- individually --- as they're reported, but it still boggles the mind how such a blatant and widespread error could go through (and the old, correct, content deleted flippantly) without someone in power shouting "STOP!":
It depends on which docs you are looking at, but some are very broken, with broken links, broken tables, broken text formatting...
Do you know of any way to get a handle to the old docs or perhaps a full MSDN dump of 3 years ago or so? (other than the web archive)? Perhaps the latest MSDN offline release or something?
The low quality of the technet "answers" are mind-boggling. Why doesn't Microsoft pull the plug on this?
Also, what's the purpose of the people who will answer nearly any question with a very low-quality (but wordy) answer? What are they getting from this effort?
You see it on SO too, people answering basic questions 2 seconds after they're postedd with long pastes from documentation that are sorta related to the original question.
I still miss the old MSDN offline help system. Once you got the hang of it, most of the time, you could find what you needed right away by typing the right thing in the Index.
Also, putting your cursor on a keyword, hitting F1, and getting the right result immediately. If I let myself I get so frustrated and angry by the massive regressions we've made over the last 20 years.
I work like this every day in my game that I am building. I’m almost the only one using the engine, and 90% of my work is in lua. I use the source code and the lua 5.1 reference for everything.
I hardly google something in a week of work, since there is nothing online about anything. It is like heaven compared to other ”google driven” programming things I have done. I feel very productive pretty much all the time, even when debugging mysterious real time issues.
From what I recall of that era, it's the exact opposite: invalid elements (like <noscript>) are simply ignored, and their contents shown. That's how <noscript> works: newer browsers which understand JavaScript know the <noscript> element and ignore its contents; older browsers which do not understand JavaScript don't know the <noscript> element so its contents are shown. The same trick is used for <noframes>: browsers like Netscape which understand frames don't show the contents of that element, while other browsers which don't understand <frame> and <frameset> will show the content of the <noframes> element, so it can be used as a fallback.
Strict validation of HTML came later with XHTML, but AFAIK all browsers which understand XHTML also understand JavaScript.
XHTML came after HTML 4.0, so it had its advent around the rise of JavaScript's popularity.
However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me.
From RFC 1866:
> markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly...
> For example:
> <div class=chapter><h1>foo</h1><p>...</div>
> => <H1>,"foo",</H1>,<P>,"..."
I feel obligated to comment, so that others are not led astray by parent comment, which is INCORRECT:
<noscript> works just fine in pre-JS browsers, at least all of the ones I've tried.
It works exactly as designed: Text between <noscript> and </noscript> is displayed in browsers without JS enabled (or supported).
I am not aware of any browsers where this is not the case, and I've tested in many, including Mosaic 1.x-3.x, NN 1.x-4.x, Opera up to 3.62, and others.
(You probably happened to visit my site during an upgrade. Sorry about that.)
Windows (not only the 16-bit 3.x, but going as far as the newest 64-bit ones) uses an event loop for the GUI: your program runs a loop calling the GetMessage function, which blocks until the next window message is available. As long as you don't take too much time processing each window message, you don't have to even think about cooperative task scheduling, since Windows will do it for you while waiting on GetMessage.
(In fact, AFAIK even in modern Windows you should avoid taking too much time to process each window message, since blocking the event loop thread makes the UI for your program unresponsive.)
I remember the user experience, I was wondering about design decisions during development.
You are guaranteed no context switches unless you explicitly request one - did it simplify some parts, or alternatively made it more complex? It's an asynchronous application.
Windows NT and Windies 95 were the first versions to have preemptive scheduling. Windows 3.11 and older would only switch tasks when he program requested new messages from the queue. Thus was totally annoying because most applications were written badly and had moments where they would go off and do things and not return to their message loop for several seconds or worse, hanging the entire system during that time. Windows felt very sluggish because of that.
We use Visual Basic 6 for a lot more than we should at work...going back to that from using Python, Ruby, and even PHP was a shok.
I thought porting a Python script to VB wouldn't be a big deal, but like you said, things youtake for granted like JSON and certain dictionaries are just lacking.
I haven't touched VB6 in ages - I tend to wonder what it would be like "going back to it".
Not too long ago I remarked here on HN that I expected VB6 programmers might become in demand in the future (when, I don't know), similar to how COBOL programmers were/are.
Basically, for the need to convert apps, written internally for a business, from VB6 to something else (likely to VB.NET or C# - maybe on Mono - but there are other options too).
I expect this to happen when Microsoft finally kills off the VB6 runtime DLL - but so far they haven't; from what I understand, it's still available in Win10...
I'm one of the "programmers of yesteryear", part-time in the early '80s on CP/M them on to Windows 3.1 after graduation in 1984.
Doing things the old-fashioned way was harder but less was expected of you, time-wise. Getting a "database" (a set of BTrieve files, usually) set up would take days, editing on floppies, etc. It was just expected that making software was a long process.
Some of your UI might have been easier to build with VB than VC. VB4 was the last version to support 16-bit Windows applications. You might have better luck finding VB6 libraries/code-samples that run in VB4 than you had finding C89 libraries.
Reading this article and others by the same author on his travails of getting Windows 3.11 to install and then bridging it to modern(-ish) tech was like being transported back to the 90s when I was first learning about computers. Seeing those screenshots of the unmistakable Win 3.1-style dialogs was a real nostalgia hit. What a treat.
10 points (well, an upvote, I guess) for anyone who knows why the Windows DOS-mode installer says "Press F3 to exit"
There was never any that much hardwired functions for F1 and F2 on PC (apart for the convention that F1 is almost always help).
On the other hand there is a related issue: on DEC (and some other) terminals with LK201-style keyboards (which in turn inspired the "modern" PC/AT keyboard layout with F1-F12) the keys in positions of F1-F5 had fixed functions. This is the reason why there are about four different escape sequences across vt220-compatible terminal emulators for F5. There simply was not any DEC terminal that had F5 on its keyboard (F1-F4 are almost always mapped to PF1-PF4).
> Seeing those screenshots of the unmistakable Win 3.1-style dialogs was a real nostalgia hit. What a treat.
When I first saw that UI in 1990 or so, I was so confused how one program could accidentally cause another one not to respond. And how all the filenames had to be in 8.3 format.
Press F3 to exit setup without rebooting; A bug in the MS-Client installer prevents a file necessary for Windows 3.1x support from being installed. This isn't necessary if running solely under DOS, but it doesn't hurt in anyway, so let's install it just to be safe.
Warning: [Omitted] source link is blocked as malware by Firefox, quote gleaned from [DDG] search results.
Windows 3.1 and 16 bit would be a little too painful for me. Windows 95 was quite nice with 32 bit and preemptive multitasking though. I kind of miss this or Windows 2000.
Last time I "used" NT4 it was to set up a machine for a specific piece of software so I could test a SICK 2D LIDAR unit (one of the blue "coffee pot" units) I had purchased off Ebay; sometime around 2014/15 IIRC.
Initially turned out that it had been set to RS485 mode, and I didn't have an adapter, and I didn't even know if it worked if I was able to get it into that mode. So with the help of a sympathetic engineer at SICK, he had me send to unit to them and he reset it (to RS232) and tested it. When I got it back, I tested it with the machine again and it worked perfectly. He didn't charge me anything for the service.
You don't see that kind of support anymore - almost no company will say "yeah, sure, send us a unit you bought second-hand off Ebay to us and we'll take a look at it, fix it, etc - and no charge to you, either - even though you're just a hobbyist and have no support contract" - it shocked me.
There's also Win32s for writing 32-bit applications in Windows 3.1! It could be done because Windows 3.1 in 386 mode uses a 32-bit kernel that saw relatively few changes between 3.1 and 95. The main difference between 3.1 and 95 is that 3.1 uses a single 32-bit task for all of the GUI, but there is really a lot of 16-bit code in Windows 95 (unlike NT for example).
/me feels an urge to read Unauthorized Windows 95 back to back.
This presents c89 as the most antiquated thing in the world, but VS didn't support mixed declarations and code in a .c file until 2015. There is still a lot of code out there that avoids this to be able to work with MS's compilers.
... in C mode, which is basically C89 (+ whatever is needed for recent C++ versions). Compiling C code in C++ mode is a common way of working around this. But MSVC is not a C compiler, it's a C++ compiler, so their unwillingness to invest in C is probably understandable.
If there are gripes about c89 I don't want to think about how different c++ support would be relative to the late 90s or early to mid 2000s, let alone now.
Shortly after my comment I remembered that even in c99 or c++, there are patterns where mixed declaration and code are messy. WndProc switch statements is one example. You can't jump past a declaration of the same scope, so a case label can't declare anything unless you add curly braces.
Unfortunately, even this isn't perfect. For example, when running Tetris from WEP, the colors are off/weird (I'm guessing a color depth issue). It is, however, good enough to run just about any old crap I've given it.
Same with Delphi. We did decades of applications going from Turbo Pascal in the 80s to Delphi in the 90s and 00s and 10s without hardly any changes (this was possible because I wrote a tooling to convert the DOS Pascal graphics code to Delphi Windows automatically so we ran 1 version of code that compiled on both) right up until the company was sold a couple of years ago.
There's an option to disable the WYSIWYG editor now :)
Unfortunately, it still doesn't work as good as before: text like `Object`s (no space between the ending ` and next text) doesn't work anymore, and according to Slack's support this is 'working as intended'.
> Therefore, if one wants to write an app using Windows OS standard APIs, WFW 3.11 is the oldest one can go back without putting in even more exponential effort.
In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-)
More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality. I'm a long-time Win32 programmer who started in the tail-end of the Win16 days and one of the things I've wanted to write if I had the time and need was a Win32 native Slack client, to show that it can be done with far less resources, but you've gone even further with Win16. Win32 has native TLS support (via SChannel library, not well-documented but examples exist) and you'd be able to even use it practically (32-bit applications will run on all current versions of Windows, both 32 and 64-bit.)
Note that C89 only prevents declarations of variables in the middle of a scope; you can simply create an inner scope with new variable declarations at its start. Like so...
Another small tip: if you make it a dialog-based application, you won't have to bother with WM_PAINT and drawing text yourself --- you can just make the "statusText" and "settingsText" edit controls, and use SetWindowText (or SetDlgItemText) to set their content. They will paint themselves automatically just like the listboxes that you used for the chat contents and userlist. At least you'll save some of those 676 bytes that way...
I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.
Before Electron people had the arguments about bloated apps when it came to WPF and Qt. And Java apps, like WPF (and most Qt apps I’ve used lately) lacks true integration with native OS widgets so as a user I get an uncanny-valley feeling.
At least with Electron you’re essentially forced to style everything - and ever since Windows 8 (or Windows Vista) Microsoft has been actively uglifying native widgets.
I did consider Java as I was writing it, but at the same time Java is actually pretty fast, but there is no doubt that it doesn't use native components most of the time (there is a gnome toolkit bindings for Java, so it is possible).
Still Java feels speedy, I think because it is compiled and doesn't need wacked workarounds like not having non-floating point numbers.
Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries. Designers by the dozens would be hired, then get fed up with these limitations and quit, complaining that they wanted to have the freedom to make UIs in HTML and CSS, and that users are used to interacting with Web UIs so everything should look like that.
Later, at a different job, the UI was Electron based, but designers no longer worked in HTML, they used some other tools and it had become the job of engineers to write the HTML and CSS to match.
These trends seem to be driven partly by conventional wisdom about the lowest common denominator among young people in the workforce, e.g. javascript and html are so much easier, let's build everything on those, and next thing you know those have become a given and the next crop of kids will use something new on top of that. Or maybe something like QT will win and native code will become a first class citizen again with secondary support inside browsers via WebAssembly?
Some years ago I worked on a very popular Windows desktop C++ program that had to stay small and backwards compatible, which meant only Win32 APIs and homemade libraries.
That's funny, because it's exactly the type of job I'd love doing --- and I have been working on stuff like that (native code, mostly Win32, with some hardware/drivers/embedded stuff) for a long time; if you haven't guessed already, I try to stay very far away from the web stuff, even though I know HTML/CSS/JS and can use it if needed.
I mean I am not a fan of C++ (though I don't hate it either), and I love how easy and well libraries for e.g Python works together and how easy they are to find and install, but I don't think it is necessary to go all the way to native code -- Java/Kotlin on the JVM performs pretty well (and you can always outsource the heavy parts to C).
> More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality.
If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface?
No one needs to be convinced that a native Slack client for each platform would be much better, I wish they would build those clients. The problem is most companies can’t reasonably justify the costs of building multiple native clients when a single cross platform one is good enough.
Qt and to some extent GTK+ come close. GTK+ can be programmed in Vala which is a fine language that transpiles to C and supports idioms such as asynchronous programming.
I just want to step in quick to advocate. Please do not use Qt for the web. Their web export tools aren't just unfinished, they're actively hostile to web paradigms. The finished product doesn't render to the DOM, it's completely screenreader inaccessible, it overrides browser preferences. In a lot of ways, Qt on the web is even worse than Flash was.
You know all of the arguments against Electron that people trot out about how it's not real native, and it doesn't follow the right UX conventions or paradigms? Qt on the web is exactly like Electron on native, except way worse and without any sign that it's going to improve, because fundamentally Qt is structured around the idea that it should be able to spit out a binary blob of pixels instead of hooking into web-native primitives like the DOM.
Look into something that's showing more promise, like .NET and Razor. The Rust community is also doing some good work here, although I don't know that they have any UI frameworks that are mature enough to be reliable in an enterprise setting.
These aren't true cross-platform efforts yet, since they're still forcing you to think about HTML. But if I was going to bet on any project ending up with a real cross-platform solution that felt good on the web, some kind of export option from an Open Source Windows Forms or similar is probably what I would bet on. Either Microsoft or (possibly) the Rust community are the two parties that I think are most likely to end up producing a true native UI toolkit that can actually export to the web in a usable, acceptable way.
Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019.
> GTK+ can be programmed in Vala
Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can easily cost weeks to fix.
You can also write GTK+ in JavaScript for that matter, or Python. Vala is a very underrated language though and it should be very easy for a good JavaScript programmer to pick it up.
I mostly program for Windows and use C# for the GUI.
Cross-platform story is complicated, though. I have good experience creating a custom GUI framework for embedded Linux: drm/kms, gles, NanoVG, [DllImport], everything on top is custom C# code in .NET core 2.2. But that approach is not for everyone. I only needed 10-15 screens with simple GUI on them, it’s a 5” touchscreen with no other user-facing devices. Creating more advanced UX this way would consume too much time.
There’re Avalonia and Xamarin. Didn’t used them at that time because I needed full-screen GUI for a single-application Linux, without any desktop environments or user mode OS components. For desktops and especially mobile apps they might work OK.
It’s unpopular opinion here, but I think Electron is not that bad for GUI, esp. when writing TypeScript instead of JS. I think it’s similar story to Unity3D or PHP: low entry barrier attracted inexperienced programmers, then the whole ecosystem is judged based on the output of these inexperienced people.
> Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug.
Have you seen the state of Javascript 'ecosystem' and job market?? Both statements are false.
The real reason is that C++ toolkits don't have platform and device independence. HTML and CSS are really good and powerful design tools, especially compared to composing raw pixels like you'd (essentially) be forced to do with Qt and GTK.
The ignorance in this thread is rather concerning.
Let me correct: GTK+ is not C++, it's C. Qt is very cross-platform: it supports about 10 platforms, including Linux, Windows, and macOS. You are not doing anything close to compositing raw pixels in Qt or GTK+. They have layout managers that are specifically made for typical application UIs, and they have lots of ready-made widgets. Qt also has QML, which is a declarative UI descriptions language kind of like HTML/CSS but much more productive because (gasp) it's actually designed from the ground up for applications, not websites.
It would have been relatively straightforward for Microsoft to support 16-bit on 64-bit, but they decided not to. I can't help but feel that that is just more evidence that whoever is running Windows development these days hates everything that used to make it a good desktop.
64-bit Windows has never supported 16-bit. This has nothing to do with "whoever is running Windows development these days"
Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64. They figured, rightly, that by the time x64 became widespread, 16-bit would be obsolete.
> This has nothing to do with "whoever is running Windows development these days"
> Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64.
These two statements are at odds. Microsoft used to take compatibility extremely seriously. It would have been relatively trivial to allow 16-bit applications to run, and obviously there is desire to do so since WineVDM exists, they just arbitrarily decided not to.
I suspect this is because they've become infected with developers who use Linux a lot and think nothing of breaking compatibility every release, let alone in cases like this.
Wasn't 64-bit windows 2k/64 itanium-based, not x86-based? If so it would have required supporting existing binaries compiled for a different architecture. My understanding is that the only 16-bit support in 64-bit windows is a few specific loaders for things like 16-bit installers (please correct me if I'm wrong)
Yes, the initial 64-bit OS was IA64 and that was the perfect excuse to dump NTVDM, instead of trying to do a W16OW64 or something of that sort. x64 XP and 2003 further solidified that decision because they were "professional" SKUs and Microsoft could dictate that they didn't care about DOS/Win16 for the "new" platform.
Virtual 8086 mode was gone, but they could have just emulated it. The real reason 16-bit apps don't run is Microsoft didn't think it was worth the effort.
> Write your apps in Python and release them on iOS, Android, Windows, MacOS, Linux, Web, and tvOS using rich, native user interfaces. Multiple apps, one codebase, with a fully native user experience on every platform.
This sounds great, but it seems there's no out-of-the-box support for a rich text textbox?
I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.
I'm still trying to figure out if there's a GUI that supports different text with mixed colors and features out of the box, and that's not horribly broken in OS X
It was more or less a rethorical question (I guess that’s why I’m being downvoted), because there is no competitor. If there was, then Electron wouldn’t be so extremely popular in the first place, and we’d see a lot more popular apps made with all the tools mentioned in the other replies to my post.
You are being downvoted because the idea that electron is the only way to get cross platform GUIs is absurd and comes from inexperience and a lack of research. FLTK, Juce and Qt are just some of the options for creating cross platform UIs that end up being much smaller and MUCH faster than electron. Electron is popular because people learn javascript and don't want to learn C++. I can't completely fault this mentality for toy programs, but at some point the false sweeping statements get pretty old.
I think misunderstood what I said - I can understand not learning C++ for toy programs, but at some point making thousands of users use an electron program is pretty silly.
It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy.
The truth is, everybody knows about Qt, GTK and so on, and everybody knows Electron is heavy but you have to be realistic. As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, or do you go for the solution which, while not ideal, allows you to develop a cross platform app in a much shorter time?
These days many people run Electron apps without even knowing it, showing that it's an ok solution.
> It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy.
I don't think I said all that
> As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time,
This I think is a big assumption. Making a GUI isn't really that difficult. Most of the time in a program doesn't go into making the actual UI. I never hear someone who is experienced in making UIs say that electron saves them so much time, it is always people assuming it takes an army of C++ people to do what one person can do with electron, which is bizarre, especially over the course of something that is more than a prototype.
If you don't know the difference between "inexperience and a lack of research" and "ignorant, incompetent and lazy" then I don't know what to tell you. It seems like you are hallucinating some sort of persecution.
It is not a big assumption, I've done it many times. What is it that you think electron gives you that cross platform GUIs don't have? Making the actual UI is usually pretty trivial, it isn't even logic, just data through function calls.
Sure, I’m just saying there is a huge gap and other tools, even though they technically work, haven’t proven to be good enough to become as widely adopted as Electron.
Thanks, I'm assuming there is some core application capability that people are getting from Electron. In terms of 'write once run anywhere' Java has that covered but doesn't offer a means to spec UIs with HTML/CSS, so if that is the deal killer then it would be nice if Java added that capability for applications.
Edit >> looks like JavaFX WebView is a thing now, plus the jxbrowser embeds chromium in a Java App... not sure of the performance of either of these implementations
That's the biggest lie ever, with these newfangled "cross-platform" solutions.
I want to watch the guy who has to sit down and port electron to a platform it doesn't run on yet. It's just a few lines of code, right?
Java had the same problem, everyone who ran Linux in early 2000s remembers. It's still not something I would want to port, but at least it runs on more systems ootb than electron.
There is Delphi and Lazarus as open-source clone of it
Lazarus can use the Windows API on Windows, gtk/qt on Linux, and carbon/cocoa on Mac.
There is also a custom drawn mode that draws the GUI directly rather than using platform apis. That also runs on Android, but it not maintained anymore, so only up to Android 5 or something
Delphi is supposed to run on Android and iOS.
And Delphi 1 ran on Windows 3.1, so you could have used the same GUI since then
There is Delphi and Lazarus as open-source clone of it
Shhh! Ixnay on the Lazarusay. If people find out, I'll lose my magical secret weapon for blasting out little windows gui apps.
Seriously though, if you ever find yourself needing a few buttons on a windows desktop that do simple things, Lazarus is amazing for whipping that up in a few minutes and still looking professional.
Actually, s/Slack/Tidal/ if you want to add insult to injury. Electron app for Windows and Mac (but well, nice features overall). However, no Linux build.
Slack does have (very-long-time-beta) Linux build[0], though I personally prefer to just use Slack through my browser instead of suffering through an Electron app.
It feels a lot closer to write for MCUs if you write for 16-bit programs nowadays. The only difference is that MCUs are much more barebone and so less managed, but the constraints set by hardware however is the most distinctive common spot.
Super late, but the term MCU refers to the actual chip -- analogous to SoC for the main chip on a raspi.
You don't call the raspi an SoC, and it's debatable that you'd call a prototyping platform like Arduino an MCU. The MCU is the main Atmel AVR, Microchip PIC, or similar part that drives such a board.
There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?
And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.
Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution
And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example
It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected
Yeah but then the dev has to investigate how to solve certain patterns in Qt's ways which they already know how to solve in the web frameworks, and just like with natural languages, sometimes there are no straightforward ports for concepts, and it requires a ton of extra work that you couldn't foresee until getting halfway through the whole project. Adopting new tech is not without serious costs and risks. Also, no GUI framework I've ever seen has figured out a decent composability solution nearly as well done as the DOM, for better or worse. Not to mention the gigantic web ecosystem that just works in Electron.
Sorry, but if the way forward really is that every desktop application of the future has to ship with a full copy of Chrome, come with all the bloat and baggage of the web platform and continue its questionable UI conventions - all just because companies are too cheap to offer some training - then I really don't see how that is a desirable future.
Electron is bad enough from a user perspective, but it's downright horrible to see how it's instilled a rather defeatist approach in front-end developers.
"But I already know Javascript, it's too hard to figure out something else"
I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. So an electron app could be just a web-site, but they often are much more.
That's true but some of that could already be implemented in browsers itself. E.g. web page could request to be in a separate window with different icon and ask for OS-wide api permissions. Now we have to run several fully-featured browser (Elecron) instances, not sharing system libraries, under different versions. This reminds me "write once, run everywhere" Java with bundled binary JREs because of incompatibilities between vendors... But there is some progress - for example IBKR TWS client can't play sounds as it was linked with an old libavformat.so which I no longer have in the system. Browsers have most of libs statically linked.
Web pages are constrained by the functionality made available to them by the browser - which is (purposely) very limited. Electron apps run on a native JavaScript interpreter (NodeJS) and have full access to the OS.
As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.
> most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS
Huh? Okay, maybe Swing doesn't support native-looking widgets (I have less experience with it), but I can personally attest that Qt and Tk (or more precisely Ttk) apps nowadays use a platform-native look-and-feel on Windows, macOS, and Linux alike, by default (i.e. with zero effort on the part of the app developer). It might not be absolutely pixel perfect, but it's way closer than an Electron app.
Most likely, the real solution here is to make a very highly performance tuned Electron for Wayland, and make it possible for multiple Electron apps to share at least some part of the footprint of that runtime.
> But we are finally seeing emergence of desktop applications from major players for Linux because of electron
It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.
Fixed costs vs variable costs. That fixed cost of Electron does come with some sizable benefits, so if you don't take advantage of them ofc Electron will just be bloat.
I think you could get pretty far without Electron. While a closer Slack experience would require some HTML rendering (VS languages have had an embeddable web view for a long time), alot of the formatting could be native (probably have to do some parsing) as could things like file uploads, image display, etc.
As a side note, since TFA mentions you can't run 16b apps on 64b Windows, I'd like to mention that otvdm/winevdm actually allows you to do it by running Win16 apps on Win32 using Wine!
You can probably run this app using WINE on any modern Linux 64-bit system. Or maybe even Mac OS X Catalina.
(The Linux x86 maintainers are semi-seriously considering deprecating the horrible machinations needed for 16-bit on 32-bit to work, but 16-bit on 64-bit Will be supported for the foreseeable future.)
Thanks! given the amount of complaining about slack on HN I thought someone would have produced a native open source client by now. I might look into it.
It's also probably possible to use a current compiler, maybe clang or gcc, to compile such code (officially only up to VC++ 4.2 is supported), although it might require some hacks.
247 comments
[ 2.8 ms ] story [ 249 ms ] threadWithout the benefit of modern libraries and languages, I had to read up and take care of many low level details, socket programming, HTTP, JSON parsing, UI design in code all under tight memory constraints. Nevertheless, it was a terrific lesson in understanding how things work under the hood.
I had to do things the old-fashioned way reading books and header files due to the dearth of online documentation. I can empathise with the plight of the programmers of yesteryears who had to code without the benefit of online search engines.
With this blog post, I hope you'll find it interesting to learn about developing a modern-ancient app for Win 3.1.
https://github.com/yeokm1/w31slack https://github.com/yeokm1/http-to-https-proxy
Gives just a 404.
I had dual screens at home in late 1995 for sure, can’t remember if I used a dual screen setup any earlier than that.
I feel "old-style" documentation is much better than we have now. My most productive _python_ only work times were when I had only the python .hlp file and a _physical_ paper book.
What are your impressions?
But now the amateur documentation writers are competing with the professional ones; the quality of the professional documentation is still as high as ever, but it can be drowned out by the amateur quality documentation.
All in all, finding the information you need is MUCH quicker via a search engine, but the signal-to-noise ratio is lower.
One of the more memorable WTFs I've seen is this, which is still wrong as of this post:
https://docs.microsoft.com/en-us/windows/win32/api/wininet/n...
Compare to the old version of the page on MSDN:
http://web.archive.org/web/20080828050103/http://msdn.micros...
See what's missing? The newer version is not the correct one... in "migrating" the document to the new site, for a reason that completely defines all rational explanation, the return type of the function declaration became void. There are plenty of pages on the new site with this serious error, and they've remained unfixed for well over a year. People report such problems on their GitHub, and they get fixed --- individually --- as they're reported, but it still boggles the mind how such a blatant and widespread error could go through (and the old, correct, content deleted flippantly) without someone in power shouting "STOP!":
https://github.com/MicrosoftDocs/windows-driver-docs-ddi/iss...
It depends on which docs you are looking at, but some are very broken, with broken links, broken tables, broken text formatting...
Do you know of any way to get a handle to the old docs or perhaps a full MSDN dump of 3 years ago or so? (other than the web archive)? Perhaps the latest MSDN offline release or something?
I don't even mind paying.
Also, what's the purpose of the people who will answer nearly any question with a very low-quality (but wordy) answer? What are they getting from this effort?
You see it on SO too, people answering basic questions 2 seconds after they're postedd with long pastes from documentation that are sorta related to the original question.
I hardly google something in a week of work, since there is nothing online about anything. It is like heaven compared to other ”google driven” programming things I have done. I feel very productive pretty much all the time, even when debugging mysterious real time issues.
It's designed for compatibility, and I've tested a lot of Netscapes and IE4, but nothing on Win311 yet.
If you want to leave a comment, you can do so right on the message board. It should work, more likely with JS off.
Many of the 3.1-era browsers didn't have a concept of JS yet. If you're relying on noscript at all it won't work.
I did try and check if this was the case, but both links in your profile that it could have been lead to "not found" dreamhost sites.
Strict validation of HTML came later with XHTML, but AFAIK all browsers which understand XHTML also understand JavaScript.
However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me.
From RFC 1866:
> markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly...
> For example: > <div class=chapter><h1>foo</h1><p>...</div> > => <H1>,"foo",</H1>,<P>,"..."
[0] https://www.w3.org/MarkUp/html-spec/
<noscript> works just fine in pre-JS browsers, at least all of the ones I've tried.
It works exactly as designed: Text between <noscript> and </noscript> is displayed in browsers without JS enabled (or supported).
I am not aware of any browsers where this is not the case, and I've tested in many, including Mosaic 1.x-3.x, NN 1.x-4.x, Opera up to 3.62, and others.
(You probably happened to visit my site during an upgrade. Sorry about that.)
(In fact, AFAIK even in modern Windows you should avoid taking too much time to process each window message, since blocking the event loop thread makes the UI for your program unresponsive.)
You are guaranteed no context switches unless you explicitly request one - did it simplify some parts, or alternatively made it more complex? It's an asynchronous application.
I thought porting a Python script to VB wouldn't be a big deal, but like you said, things youtake for granted like JSON and certain dictionaries are just lacking.
Not too long ago I remarked here on HN that I expected VB6 programmers might become in demand in the future (when, I don't know), similar to how COBOL programmers were/are.
Basically, for the need to convert apps, written internally for a business, from VB6 to something else (likely to VB.NET or C# - maybe on Mono - but there are other options too).
I expect this to happen when Microsoft finally kills off the VB6 runtime DLL - but so far they haven't; from what I understand, it's still available in Win10...
Doing things the old-fashioned way was harder but less was expected of you, time-wise. Getting a "database" (a set of BTrieve files, usually) set up would take days, editing on floppies, etc. It was just expected that making software was a long process.
Edit: oh, I see what happened now. We made a mistake, intending to set the URL for https://news.ycombinator.com/item?id=21831931. Sorry!
10 points (well, an upvote, I guess) for anyone who knows why the Windows DOS-mode installer says "Press F3 to exit"
On the other hand there is a related issue: on DEC (and some other) terminals with LK201-style keyboards (which in turn inspired the "modern" PC/AT keyboard layout with F1-F12) the keys in positions of F1-F5 had fixed functions. This is the reason why there are about four different escape sequences across vt220-compatible terminal emulators for F5. There simply was not any DEC terminal that had F5 on its keyboard (F1-F4 are almost always mapped to PF1-PF4).
When I first saw that UI in 1990 or so, I was so confused how one program could accidentally cause another one not to respond. And how all the filenames had to be in 8.3 format.
Amiga had spoiled me.
Press F3 to exit setup without rebooting; A bug in the MS-Client installer prevents a file necessary for Windows 3.1x support from being installed. This isn't necessary if running solely under DOS, but it doesn't hurt in anyway, so let's install it just to be safe.
Warning: [Omitted] source link is blocked as malware by Firefox, quote gleaned from [DDG] search results.
Didn't crash and was smooth as butter.
Have you kept a nt4? Do you still use it? What do you think is the closest equivalent: win200, reactos??
Initially turned out that it had been set to RS485 mode, and I didn't have an adapter, and I didn't even know if it worked if I was able to get it into that mode. So with the help of a sympathetic engineer at SICK, he had me send to unit to them and he reset it (to RS232) and tested it. When I got it back, I tested it with the machine again and it worked perfectly. He didn't charge me anything for the service.
You don't see that kind of support anymore - almost no company will say "yeah, sure, send us a unit you bought second-hand off Ebay to us and we'll take a look at it, fix it, etc - and no charge to you, either - even though you're just a hobbyist and have no support contract" - it shocked me.
/me feels an urge to read Unauthorized Windows 95 back to back.
I'm sure writing mIrc was not "zero pain" back in the day. And Jabber needs a XML parser which is more complex than a JSON parser.
Also, an IRC client is a joke, it can be compiled and built even on BSD 4.3, released in late 80's.
The suckless guys created some IRC clients in few lines, and the sj client is not that difficult.
Heck, you could write an IRC client with Bash and even with Netcat/ed.
https://wiki.freepascal.org/Win16
Unfortunately, it still doesn't work as good as before: text like `Object`s (no space between the ending ` and next text) doesn't work anymore, and according to Slack's support this is 'working as intended'.
Hey, what's wrong with Trumpet Winsock? :-)
In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-)
More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality. I'm a long-time Win32 programmer who started in the tail-end of the Win16 days and one of the things I've wanted to write if I had the time and need was a Win32 native Slack client, to show that it can be done with far less resources, but you've gone even further with Win16. Win32 has native TLS support (via SChannel library, not well-documented but examples exist) and you'd be able to even use it practically (32-bit applications will run on all current versions of Windows, both 32 and 64-bit.)
Note that C89 only prevents declarations of variables in the middle of a scope; you can simply create an inner scope with new variable declarations at its start. Like so...
Another small tip: if you make it a dialog-based application, you won't have to bother with WM_PAINT and drawing text yourself --- you can just make the "statusText" and "settingsText" edit controls, and use SetWindowText (or SetDlgItemText) to set their content. They will paint themselves automatically just like the listboxes that you used for the chat contents and userlist. At least you'll save some of those 676 bytes that way...At least with Electron you’re essentially forced to style everything - and ever since Windows 8 (or Windows Vista) Microsoft has been actively uglifying native widgets.
which is funny when you see that Qt runs on microcontrollers now.
Still Java feels speedy, I think because it is compiled and doesn't need wacked workarounds like not having non-floating point numbers.
Update: ah, Microsoft released their own port in 1997: https://www.cnet.com/news/ie-gets-java-for-windows-3-1/ - I wonder how long they maintained that for.
Later, at a different job, the UI was Electron based, but designers no longer worked in HTML, they used some other tools and it had become the job of engineers to write the HTML and CSS to match.
These trends seem to be driven partly by conventional wisdom about the lowest common denominator among young people in the workforce, e.g. javascript and html are so much easier, let's build everything on those, and next thing you know those have become a given and the next crop of kids will use something new on top of that. Or maybe something like QT will win and native code will become a first class citizen again with secondary support inside browsers via WebAssembly?
That's funny, because it's exactly the type of job I'd love doing --- and I have been working on stuff like that (native code, mostly Win32, with some hardware/drivers/embedded stuff) for a long time; if you haven't guessed already, I try to stay very far away from the web stuff, even though I know HTML/CSS/JS and can use it if needed.
If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No one needs to be convinced that a native Slack client for each platform would be much better, I wish they would build those clients. The problem is most companies can’t reasonably justify the costs of building multiple native clients when a single cross platform one is good enough.
Qt, as well as Windows, macOS and Linux actually can do Android [0] and iOS [1], and Web is halfway there [2].
[0] https://doc.qt.io/qt-5/android.html
[1] https://doc.qt.io/qt-5/ios.html
[2] https://wiki.qt.io/Qt_for_WebAssembly
You know all of the arguments against Electron that people trot out about how it's not real native, and it doesn't follow the right UX conventions or paradigms? Qt on the web is exactly like Electron on native, except way worse and without any sign that it's going to improve, because fundamentally Qt is structured around the idea that it should be able to spit out a binary blob of pixels instead of hooking into web-native primitives like the DOM.
Look into something that's showing more promise, like .NET and Razor. The Rust community is also doing some good work here, although I don't know that they have any UI frameworks that are mature enough to be reliable in an enterprise setting.
These aren't true cross-platform efforts yet, since they're still forcing you to think about HTML. But if I was going to bet on any project ending up with a real cross-platform solution that felt good on the web, some kind of export option from an Open Source Windows Forms or similar is probably what I would bet on. Either Microsoft or (possibly) the Rust community are the two parties that I think are most likely to end up producing a true native UI toolkit that can actually export to the web in a usable, acceptable way.
[0] http://www.beeware.org [1] https://dan.yeaw.me/posts/gui-widget-for-beeware/
Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019.
> GTK+ can be programmed in Vala
Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can easily cost weeks to fix.
Which one would you recommend?
Cross-platform story is complicated, though. I have good experience creating a custom GUI framework for embedded Linux: drm/kms, gles, NanoVG, [DllImport], everything on top is custom C# code in .NET core 2.2. But that approach is not for everyone. I only needed 10-15 screens with simple GUI on them, it’s a 5” touchscreen with no other user-facing devices. Creating more advanced UX this way would consume too much time.
There’re Avalonia and Xamarin. Didn’t used them at that time because I needed full-screen GUI for a single-application Linux, without any desktop environments or user mode OS components. For desktops and especially mobile apps they might work OK.
It’s unpopular opinion here, but I think Electron is not that bad for GUI, esp. when writing TypeScript instead of JS. I think it’s similar story to Unity3D or PHP: low entry barrier attracted inexperienced programmers, then the whole ecosystem is judged based on the output of these inexperienced people.
Have you seen the state of Javascript 'ecosystem' and job market?? Both statements are false.
The real reason is that C++ toolkits don't have platform and device independence. HTML and CSS are really good and powerful design tools, especially compared to composing raw pixels like you'd (essentially) be forced to do with Qt and GTK.
Let me correct: GTK+ is not C++, it's C. Qt is very cross-platform: it supports about 10 platforms, including Linux, Windows, and macOS. You are not doing anything close to compositing raw pixels in Qt or GTK+. They have layout managers that are specifically made for typical application UIs, and they have lots of ready-made widgets. Qt also has QML, which is a declarative UI descriptions language kind of like HTML/CSS but much more productive because (gasp) it's actually designed from the ground up for applications, not websites.
[0] https://github.com/otya128/winevdm
It would have been relatively straightforward for Microsoft to support 16-bit on 64-bit, but they decided not to. I can't help but feel that that is just more evidence that whoever is running Windows development these days hates everything that used to make it a good desktop.
Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64. They figured, rightly, that by the time x64 became widespread, 16-bit would be obsolete.
Don't believe I said otherwise.
> This has nothing to do with "whoever is running Windows development these days"
> Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64.
These two statements are at odds. Microsoft used to take compatibility extremely seriously. It would have been relatively trivial to allow 16-bit applications to run, and obviously there is desire to do so since WineVDM exists, they just arbitrarily decided not to.
I suspect this is because they've become infected with developers who use Linux a lot and think nothing of breaking compatibility every release, let alone in cases like this.
It didn't exactly run 16-bit installers. https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27...
> Write your apps in Python and release them on iOS, Android, Windows, MacOS, Linux, Web, and tvOS using rich, native user interfaces. Multiple apps, one codebase, with a fully native user experience on every platform.
I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.
I'm still trying to figure out if there's a GUI that supports different text with mixed colors and features out of the box, and that's not horribly broken in OS X
I was actually thinking of giving it a go, but the idea of a Python backend and a Delphi frontend is as attractive as recoding everything in ASM.
> false sweeping statements
OK.
The truth is, everybody knows about Qt, GTK and so on, and everybody knows Electron is heavy but you have to be realistic. As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, or do you go for the solution which, while not ideal, allows you to develop a cross platform app in a much shorter time?
These days many people run Electron apps without even knowing it, showing that it's an ok solution.
I don't think I said all that
> As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time,
This I think is a big assumption. Making a GUI isn't really that difficult. Most of the time in a program doesn't go into making the actual UI. I never hear someone who is experienced in making UIs say that electron saves them so much time, it is always people assuming it takes an army of C++ people to do what one person can do with electron, which is bizarre, especially over the course of something that is more than a prototype.
Kind of: "inexperience", "lack of research", "don't want to learn C++"
> Making a GUI isn't really that difficult.
Also a big assumption, especially for cross-platform GUIs.
It is not a big assumption, I've done it many times. What is it that you think electron gives you that cross platform GUIs don't have? Making the actual UI is usually pretty trivial, it isn't even logic, just data through function calls.
Edit >> looks like JavaFX WebView is a thing now, plus the jxbrowser embeds chromium in a Java App... not sure of the performance of either of these implementations
That's the biggest lie ever, with these newfangled "cross-platform" solutions.
I want to watch the guy who has to sit down and port electron to a platform it doesn't run on yet. It's just a few lines of code, right?
Java had the same problem, everyone who ran Linux in early 2000s remembers. It's still not something I would want to port, but at least it runs on more systems ootb than electron.
Lazarus can use the Windows API on Windows, gtk/qt on Linux, and carbon/cocoa on Mac.
There is also a custom drawn mode that draws the GUI directly rather than using platform apis. That also runs on Android, but it not maintained anymore, so only up to Android 5 or something
Delphi is supposed to run on Android and iOS.
And Delphi 1 ran on Windows 3.1, so you could have used the same GUI since then
Shhh! Ixnay on the Lazarusay. If people find out, I'll lose my magical secret weapon for blasting out little windows gui apps.
Seriously though, if you ever find yourself needing a few buttons on a windows desktop that do simple things, Lazarus is amazing for whipping that up in a few minutes and still looking professional.
[0] https://slack.com/downloads/linux
Slack calls don't work reliably in Chrome/Electron on linux anyway, so no loss here.
You don't call the raspi an SoC, and it's debatable that you'd call a prototyping platform like Arduino an MCU. The MCU is the main Atmel AVR, Microchip PIC, or similar part that drives such a board.
Even at an absolute worst case it still beats the pants off Slack.
An earlier blog post shows this http://yeokhengmeng.com/2016/09/windows-for-workgroups-3-11-...
Wikipedia says "However, no single process can use more than 16 MB.". Not sure where is the source of that though.
https://en.wikipedia.org/wiki/Windows_3.1x
It’s a limitation from the 286 Protected Mode.
Creating a native Windows app to mimic the Electron Slack client would not be a trivial task.
And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected
They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.
"But I already know Javascript, it's too hard to figure out something else"
In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration.
If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?
As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.
Huh? Okay, maybe Swing doesn't support native-looking widgets (I have less experience with it), but I can personally attest that Qt and Tk (or more precisely Ttk) apps nowadays use a platform-native look-and-feel on Windows, macOS, and Linux alike, by default (i.e. with zero effort on the part of the app developer). It might not be absolutely pixel perfect, but it's way closer than an Electron app.
It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.
Or even Delphi! Delphi 1 targeted Win16.
(The Linux x86 maintainers are semi-seriously considering deprecating the horrible machinations needed for 16-bit on 32-bit to work, but 16-bit on 64-bit Will be supported for the foreseeable future.)
https://api.slack.com/
I am going to be using this line a lot in the future.
Not true, you can downgrade the SMB version requirement in the Windows 10 registry.
The sixth edition on words begins to use the. Net CLR and other non-native toolchains as Microsoft changed them. So, those are less valuable to me.
If you want to do native Windows development, that is probably the single best book you could buy.
It's also probably possible to use a current compiler, maybe clang or gcc, to compile such code (officially only up to VC++ 4.2 is supported), although it might require some hacks.