Dos-like: Engine for making things with a MS-DOS feel, but for modern platforms
github.com
github.com
https://img.itch.zone/aW1hZ2UvMTIyODU3OC83MTY0MTEyLnBuZw==/o...
They have such a cozy feel, reminds me of simpler times.
It would be cool if there were a CSS framework where you could make webpages like that.
It was kind of a complete floating windows GUI in a TUI: http://setedit.sourceforge.net/se1.gif
I wonder if it would be possible to extend a terminal multiplexer to the point of providing such an intuitive interface to existing TUI software on modern *ix systems. I'm sure the effort would be quite non-trivial, but it would help a number of workflows. Adding support for the additional features that are found in these TUI environments (consider e.g. menubars) could then be done via custom terminal extensions.
Check out the VTM project[1]! It feels like that's the direction they're heading. No direct affiliation; they've filed some bugs on Windows Terminal, however. :)
These days, I use Tilde, which is modern, maintained, and packaged for contemporary distros. https://os.ghalkes.nl/tilde/
The one thing it doesn't do for me is pick up Git commit templates, so for that I have to have my default set to `mc`. I don't know why that one thing doesn't function.
someone made a turbovision (borland turbo pascal ui framework) lib for java https://jexer.sourceforge.io/
CRTs with that text mode (and including scanlines, but not only that) just seem very hard to reproduce on modern displays.
The fact that your photo does evoke the same feeling while I'm seeing it on a modern 5k display shows that it's possible, but the amount of tricks needed might be so much that it becomes whimsical somehow (or at least in contrast to just changing the font)...
I do. Brings back memories of Turbo-C.
> It would be cool if there were a CSS framework where you could make webpages like that.
A quick search brought this old project: https://github.com/6112/cursesjs
Never tried that, however. Ncurses is what is used under Linux and other UNIX like systems to draw terminal based GUIs, and allows some pretty good graphics.
https://en.wikipedia.org/wiki/Ncurses
https://christopherstoll.org/2015/12/29/ncurses-system-perfo...
More of my fond TUI memories from that era were the bespoke ones in the demo/art/music/bbs scenes. Those in many cases were still character based but seemed to make better use of the screen space and at least more aesthetically pleasing character sets.
Scream Tracker / Impulse Tracker comes to mind as one example:
https://upload.wikimedia.org/wikipedia/en/5/53/Screamtracker...
Which you can still enjoy today in a cross-platform clone via SchismTracker:
That same thing in say 96x50 would feel much better.
Edit, just viewed your tracker link! Yes, exactly.
For anyone searching for the Borland style text interface, it was actually called TurboVision, not BGI (which was a generic graphics library). TurboVision (and many GUIs of the time) largely followed the Common User Interface (CUI) spec by IBM for its interactions in text mode.
It is fair to say there was a lot of screen space devoted to borders and such, especially in 80x25 mode, but that helped make everything super clear and usable.
Thank you for the excellent link!
I do miss the simple UI offered by some BBSes (as well as their message editors, like in Renegade BBS). A lot of that is just nostalgia, of course.
https://diarywind.com/blog/img/g13/fcf379da7cb57db6feb94d563...
https://winworldpc.com/res/img/screenshots/10-for-dos-54195b...
I don't remember the price of Turbo Vision, but I remember it was obscenely expensive in my third-world eyes. It was sold separately until it was finally bundled with BC++ 3.1 (1992).
You might have disliked them but they were far from awful. They were some of the cleanest TUIs ever designed.
The other screenshot you shared isn’t a TUI by the way. It’s a GUI. It just happens it runs atop of DOS (much like early versions of Windows did). So it’s not really comparable to TurboVision.
Regarding TurboVision, I suspect you might be in the minority with your dislike for them too. Which I guess just goes to prove that everyone will have different preferences and thus you can’t please everyone all of the time.
https://github.com/herrnst/impulsetracker/blob/master/IT_S.A...
For that tracker to be a proper TUI it would have to use text characters for all of the UI elements, bevels included. You simply couldn’t do those 3-tone bevels with any alt character sets, let alone an 8-bit one from the era of DOS.
Nice, mostly square characters. Mix in a mouse, and the product was easy to use, clean, fast, productive.
That sort of aesthetic, in windows even, would be a lot of fun and quite useful, if a bit of a middle finger to modern sensibilities.
Who's stopping you?
Try jexer:
A web site that imposed this sort of interface would be a site I visited ONCE.
When DOS was the uncontested king of business computing, user interfaces were all over the place. Every app had its own UI, its own keystrokes, its own everything.
To steal some text I wrote for Wikipedia:
In WordPerfect, the command to open a file was F7, 3.
In Lotus 1-2-3, a file was opened with / (to open the menus), F (for File), R (for Retrieve).
In Microsoft Word, a file was opened with Esc (to open the menus), T (for Transfer), L (for Load).
It was a mess and a significant effort to learn multiple apps.
Then classic MacOS and MS Windows started to introduce the idea of uniform UIs, where programs had the same menu bar with the same core menus with the same commands on them, opened and navigated with the same keystrokes.
It made life so much easier. A lot of apps came across, even big-name ones -- for instance MS Word (v5.0, proprietary 2-line menus at the bottom of the screen; v5.5, CUA menu bar); WordPerfect (added CUA menus in v5); Borland Quattro; etc.
And if you have a standard menu bar, then you more or less need to have dialog boxes as part of the UI.
Once you go that far, you may as well apply it to multiple documents support and so on.
And so you end up with a familiar, more-or-less harmonious UI across different apps from different vendors, and for the first time it became possible to operate a program you'd never seen before first time.
This was a huge win for usability, accessibility, and it saved time, effort and stress for millions of people.
It was a triumph. That UI persists today in most modern FOSS apps and desktops, except for intentional rebels like GNOME 3, who want to make us all use phones with big screens.
If I am going to use a text editor, say, in the shell sometimes, then YES I want it to use the same UI I have in my GUI session, with the same keystrokes and menu options. Life is much to short to learn some crappy half-assed UI from the 1970s because a bunch of old dudes with beards have loved it ever since.
Even if I am an old dude with a beard now.
But you're crossing the streams a little here.
Yes, it was a net win for the shift to GUIs to include a shift to very, very consistent interfaces.
HOWEVER, it doesn't follow that goofy, hamfisted attempts to mimic those interfaces in text mode was a good idea. If you want that, just go use Windows (or the Mac).
Word for DOS 5.0 was a fantastic program that I could move around in VERY VERY VERY quickly. It was powerful, stable, and extremely usable once you learned its interface.
Word 5.5 for DOS ripped out the ESC menus for a crappy text-mode UI, and basically killed the product. (For my part, I immediately uninstalled it and reinstalled 5.0 so I could get work done.)
But I _strongly_ disagree. In fact I think I could reasonably say that I couldn't disagree more.
I thought it was a huge win when DOS and console-mode apps adopted the general Windows-like UI.
I worked in support back then. I had to learn many dozens of apps to support them.
For instance...
In word processors, on DOS alone I worked with MS Word, WordPerfect, DisplayWrite, MultiMate, WordStar (classic, 1512 (i.e. Express), & 2000 — all different), Samna Executive, PC-Write, VolksWriter, XyWrite, Protext, PFS:Write, and also LocoScript (from the Amstrad PCW, later on DOS). Probably others.
Spreadsheets: Lotus 1-2-3, Lotus Symphony, AsEasyAs, SuperCalc, Quattro, MS Multiplan. Probably more.
I had to learn all of them, all separately, either at least the basics (I think Samna is the only one that defeated me there), or in multiple cases, pretty much inside-out.
I mean, as an example, I didn't consider myself a guru, but I interviewed for https://www.newtonim.com/ in about 1992 and I got a record-best score (about 98%) in their test of my WordPerfect and 1-2-3 skills. Neither was even my favourite program of its type!
It was a massive pain.
I mean, yes, you're right, some of them were highly efficient interfaces. I didn't hate 1-2-3 or MS Word for their idiosyncratic 2-line menus. You had to memorize them to be fast and efficient, but it wasn't that hard and once you had, it was as you say very quick.
Unlike, say, WordPerfect with its wretched Ctrl-F3, Alt-F6, Shift-F2, Alt-Shift-F8 workflow. Horrible and basically impossible to discover. If you didn't have that little cardboard keyboard template, you were doomed.
But I didn't have the luxury of picking 1 app of each type and using only those. At work I used PCs with PC DOS, at home I used CP/M and Locoscript, later Acorn RISC OS, later still OS/2 2. I did charts and DTP on classic MacOS.
All totally different, and my job meant knowing _all_ of the leading contenders in all categories.
Sure it was possible to write attractive, efficient, DOS menuing systems. Novell's DOS menuing system on Netware clients and on the server itself was fast, easy, efficient, and attractive.
So was 3Com 3+Share -- probably last seen by most people in the config tool for the classic 3C509 NIC.
But they were totally different from one another.
So if you only used MS Word, good for you. I envy you the simplicity that may have lent.
But for those of us who changed apps considerably more than every day -- more like ever hour of every day -- no, the profusion of DOS UIs was a complete pain in the neck and made my job 10× more difficult.
So when they all went away, replaced by a text-only version of the Windows/CUA guidelines, I celebrated. It made my life so very much easier.
Which is why now, 3 decades later, I absolutely refuse to learn the horrid 1970s BS UIs of Emacs or Vim. I don't care how powerful they are. I'm not interested. I gave that rubbish up in about 1990-1991 and for me all those proprietary UIs died once the next-gen ones came along.
Comply with the standards, or FOAD.
Your background is not normal. Most people doing actual work in that era used the word processor they had, not seven word processors.
In a limited environment -- text mode -- efficiency and speed > cuddly GUIs. If you wanted the common interface, install Windows; don't fuck up the existing interfaces of tools people were VERY VERY good at to graft some horribly ugly faux-GUI on them.
>I absolutely refuse to learn the horrid 1970s BS UIs of Emacs or Vim
Given the longevity and popularity of these tools, coupled with their broad availability on so many platforms, this sentence reads more like "I'm proudly ignorant!" than anything else.
The CUA interface is perfectly efficient and works very well. It doesn't need a mouse, although you can use one if it's there.
As I said: I was a skilled user of a bunch of the leading pre-CUA DOS apps, and I can navigate a CUA interface using hotkeys very quickly and efficiently without a pointing device. Occasionally, over the years, astounded onlookers have asked how it's possible that I can operate Windows so quickly. The answer is that I don't use the mouse much, and the reason is that in my first job, my employers didn't own a PC mouse. They sold Macs; if you wanted to do graphical pointy-clicky stuff, you bought a Mac.
I decided that Windows looked like it was useful and could be big one day, so I installed Windows 2.01 and learned to use it... without a mouse. The same keystrokes mostly still work today, from obvious ones like Ctrl+S to save, Ctrl+X/C/V for Cut/Copy/Paste, to less-known ones like Ctrl-W for Close Window and Alt-F4 for Close Program. Alt-Space for the window control menu, then X to maXimise, etc.
It's a common but spurious argument to claim that because one knows one particular program well and can operate it very quickly, that this fact in some way indicates that the program's UI is particularly efficient or well-designed or something. It isn't. It just means that that individual knows it well.
The basic concepts of the desktop GUI were nicknamed WIMP: Windows, Icons, Menus, Pointer. Well, each of those works fine in isolation. Icons are a useful abstraction all on their own; for instance, iOS and Android make very extensive use of the "I" part without the "W," "M" or "P".
By the same token, the W and M parts -- windows and menus -- work very well without a GUI. It's very handy that the same keystrokes that let me drive Geany or Mousepad or Notepad also work fine in Tilde or MS-DOS Edit.
They're no less efficient. Ctrl+S Ctrl-W to Save then Close is just as quick as ^KS ^KD, or !wq, or C-s C-x, or Shift+F3, Ctrl+F4.
But what's a huge boon to my or anyone's efficiency is that once I've learned Ctrl+S, say, it works in thousands of programs on multiple OSes. C-s C-x or Shift-F3 don't work in anything except the one particular app they were designed for.
This is not a difficult or obscure principle.
Proprietary UI = bad. Open shared UI = good. :-)
A UI's utility isn't determined by whether or not it's shared with other tools. It's determined by *how well users can get work done with it* which is why a host of non-CUA interfaces persist today.
Text-mode CUA was and remains horribly ugly and clunky. If you want that, go use a GUI.
What I am saying is that in this case, I put it to you that this is more than simply a matter of opinion and personal preference.
There are demonstrable, measurable advantages to this approach. Knowledgeable users can work on unfamiliar programs immediately by using standard keystrokes and via prior knowledge of how the menus will work.
Unskilled users, so long as the machine has a mouse configured, can simply use the console/terminal app in the same way as they're used to, by point-and-click.
I get that you hate it. What I am trying to tell you is that I _really_ like it. It is a _strong_ preference of mine, I find it asthetically pleasing as well as convenient, and I hate and refuse to fight with non-compliant apps that don't use it. Including _both_ of the xNix world's favourite editors, Vim and Emacs -- I hate both -- *and* all the alternatives people recommend: Joe, Pico, Nano, etc.
I get that you have a preference. That is your choice. But you are trying to make out that it's a universal truth, that your opinion is an objective fact, and it's not.
Whether you, or anyone, likes it is neither here nor there. It helps. It works. It's useful. It makes life easier.
And if the price of that is that some people's aesthetic sensibilities are offended, well... sorry dude, tough.
Eventually, everything double scanned and pushed to 70hz vert refresh
On the 1st of April it would instead switch to a "DOS skin" using the fixedsys font and the original colour theme and box-drawing character layout. Virtually identical to the original, except that some things were centred and you could scroll with a mouse.
I thought it was hilarious.
Management... not so much.
For context, the first computer we got at home was a PC at some point in '94 or '95. We had MS-DOS 6.22 and Windows 3.11. Some years later we moved into Windows 95. While I didn't really use these kind of GUIs (DOSShell and so on) as often as I would like, I always thought they were very pleasant to use. There is something about that DOS font that makes me happy each time I see it, and there is a certain feeling of being a stereotypical movie-style hacker when you use these instead of modern, actually graphical UIs. And yes, the reminiscence of simpler times with simple software, way before the surveillance capitalism and the brutal omnipresence of ads, is easy to appreciate.
The nice thing is that early versions of Windows supported these GUIs as well. So, a few years later, during my degree in Computer Engineering, I learned some x86 assembly (using Turbo Assembler as a compiler); this was during the early 00s, and we still used EDIT.com as the main text editor, although there were some others available. I loved it since the first day, both in concept (super low level programming with direct access to the hardware, managing interruptions and so on) and in execution (everything was in that text mode I loved, since modern Windows and their restrictions didn't play nicely with such low-level programming). I learned a lot from Ralf Brown's Interrup.lst, and wrote a few simple GUIs of my own, using box drawing characters and all that. Aside from those I wrote for academic work, I mostly spent a lot of time creating a silly GUI that allowed you to modify the look of the console. There were a few resolutions available, from 40x25 to 132x60, and you could change the colours of the text, the background and the border (yes, there is a border, which you can set to a different colour than the background. And my program could get 2^18=262144 colours available, not just 16! Although 16 was the max simultaneous on-screen limit IIRC), plus the font (I was able to add an edition screen where you could see the aspect of all 256 characters, yet I could use box drawing and so on for the interface in this screen. Did you know that DOS allowed two different sets of characters in screen at the same time?). There were some other additions like pixel-level scroll as opposed to the usual line-level scroll, and background "music" using the PC speaker. It didn't have any practical purpose aside from these silly customisations (which, in the case of Windows, went away when you closed the windows, and some times, also when you moved from full screen to a window), but man, did I have fun coding it. It's still one of my best memories of programming, nearly 15 years later.
Then, in 2009, my last Windows 98-capable computer stopped working, and current hardware only supported Windows XP and newer, so all of this fun basically stopped being possible (especially considering that basically all state of the art hardware was already 64 bits, and 16-bit applications like EDIT.com weren't supported any more). With emulators it's not the same, because I know I'm not really accessing the low-level hardware registers. By that time I already had a job and there was less time for this kind of hobbies, so I eventually stopped. Currently my recreational programming is mostly oriented towards math (Project Euler and so on), which is very different, but I still remember those days very fondly. I still have all that code somewhere.
Yeah, it's all nostalgia, but that doesn't mean it doesn't hit hard.
The first version was a fairly literal replacement of the workflows. The users were pissed. They demanded the checkboxes be replaced with "Y" and "N" options to mimic what they were used to. It was interesting to see the reluctance to any change at all.
If you removed my keyboard workflow, I'd be pissed too. Muscle memory means you don't have to think about it; with the mouse, you always have to think about what you're doing, and can't think of other things (e.g. why you're doing it) while you're doing the rote bits.
Is there a particular reason you couldn't've supported the Y/N workflow? (i.e. “Y” is like “set, tab” and “N” is like “clear, tab”)
That frees them to think about other things. Arguably, more important things.
Low.
They were pissed we replaced the Y/N text items with a checkbox. Any deviation, including things like lower case text, were pushed back.
At this point, I'd probably factor out the UI, hand them the client-side source code and tell them to get on with it. If they want to customise the UI, then so long as you're not supporting it…
… but yeah; that's a less reasonable objection than I thought it was. (Still a change to their workflow, and still understandable, but there were legitimate business reasons that the workflow needed to be changed.)
I did have to do a quick check to see if this library required me to configure expanded memory, however.
Using XWindows just to manage xterms, with everything in text mode besides the window manager itself?
Welcome to 1994 using DG/UX with X terminals.
Michael Abrash's graphics programming tutorials - https://www.jagregory.com/abrash-black-book/
It was a great environment to learn in. I spent time there, on the Amiga, and other systems. I honestly love how easy and powerful systems are now, but miss swap meets and the like for meeting up, talking hardware, software, etc.
It was educational to try, but fundamentally not a path likely to result in anything but a painful educational experience.
A lot of people discovered just how limited DOS was because they were fascinated by computers, but DOS (and likely Windows on top of it) was the only thing they had at the time. Yet they wanted to push the boundaries and ended up finding the ceiling. At least that's been my experience.
That's why it was all so much fun. I had so much fun that I'm still actively maintaining one of those originally DOS QuickBasic game engines -- it was ported to FreeBASIC and modern OSes long ago, but it's still got that DOS look and various limitations.
However, while I certainly don't have nostalgia for DOS in general, there were some positive things about the platform and ecosystem. Some subset of applications had TUI interfaces that were very nice (e.g. Borland C++), and while I'm a die-hard Linux terminal user, I find myself occasionally missing some of the tightness of those interfaces. (I think the UNIX terminal heritage, such as the "alt" key translating to ESC+key, no key-down/key-up events, etc., can limit our modern TUI interfaces.)
I sometimes tinker with some 8086 emulator code for fun, which can lead me to diving into the internals of DOS. Looking at its API (and how the API evolved through the 80's), I can appreciate the simplicity that was necessary to run on machines with as little as 64KB of memory. So I may not have nostalgia for it -- there was certainly plenty of pain -- but it can still be very interesting to explore from an objective historical perspective. There may even be a few things we can learn from it.
The irrelevancy is the appeal. It's become something mostly disconnected from everything else.
A world of computing that's not focused around networking or communications where the relationship is between the user and the machine as opposed to the machine being a vessel for a relationship with others.
It is inherently a different kind of computing with a different kind of performance expected between the participants. It's like how people who restore classic cars don't do so because they need a way to get groceries and drive to the office. Anyone with their head on straight would admit modern cars are cheaper to maintain, safer, and have better fuel economy. Doesn't matter, it's not the point.
Another aspect to it is the low latency you get when using a machine with very few layers of abstraction between the software and the (usually CRT) display. Using something like WordPerfect for DOS is a dramatically different experience than modern MS Word or Google Docs. Vastly fewer visual distractions as well.
We did have fun, but we would've had more fun on a more capable, less slapdash OS. Which is why so many of us abandoned Win/DOS at our first opportunity -- either on (likely university-owned) Unix or BSD hardware, or on early Linux, or for some to the Mac or Amiga or even Atari, all of which were empirically better platforms than DOS/Windows at the time EXCEPT for gaming.
At the beginning of this year, I built an AMD K6 machine, got my Gravis Ultrasound card working again (which involved ordering a replacement mixer chip from China), and have had an absolutely wonderful time reliving my early computing experiences. And yes, that also includes fiddling with IRQ settings, maximizing low DOS memory, etc. Would I do day-to-day work in this kind of environment? Hell no! But it's a really fun distraction.
For a second I thought you are talking about UI in "modern" web apps. Ok some of them are pleasure to work with, but the rest ...
The other thing is we didn't have to worry about security (much). Because everything could be backed up, and a known safe system state was achievable, and you could even write protect non-hard drive based machines, you could run ANYTHING, and there was nowhere in the hardware for malware to hide if things got squirrely and you rebooted.
You could always just reboot from a write protected system disk, and get back to work. This is a level of security that hasn't been matched since, except for mainframes with their fixed assignment of resources.
I wrote a system that recorded inspections of equipment, involved hand held computers, and a weird Emulex serial card to talk to them. The code was all in Turbo Pascal, with PL/N running on the handhelds. I supported it for a decade until Windows and Networking made things obsolete. It was a great job.
I was a big fan of 80x50 or 80x43 character screen mode.
Oh boy, where do I start! You severely underestimate the state of the art for MSDOS bootloader viruses.
E.g., https://en.m.wikipedia.org/wiki/Michelangelo_(computer_virus...
I certainly have some fond memories but I'm pretty happy with modern UIs
But realistically, I also recall getting pretty frustrated at times. Such as when I just wanted to play Wing Commander: Privateer, but had to spend hours messing with memory settings in `autoexec.bat`/`config.sys` and rebooting just to get it to run. And then I had to spend hours more fiddling with the memory settings, IRQs and the like, just so I could get sound from my Gravis Ultrasound/Soundblaster instead of the PC speaker.
But still, I can't help but feel nostalgic!
Also, thinking about which IRQs are available when buying a hardware device and how that maps with possibilities for existing devices.
Even more fun - realizing that the solution is to swap network cards amongst a couple of computers because the other network card has more options. So you do the swap (and update the software to use the new ports) and then hope that both computers will even load afterward.
Had to do the planning by hand since this was before I was on the Internet and I don't remember seeing web apps that help with this.
Back in 1992 or so, I was an Amiga user. I was blessed with both advanced GUIs and advanced shells. AmigaOS wasn't quite Unix, but the shell had similar power. I had friends who used Apple Macintosh computers, and they also bragged about the stuff they could do. (And of course you had other things like NeXT, Acorn's RISC OS, SCO UNIX, and OS/2, all of which had pre-emptive multitasking, but weren't on my radar at the time.)
But the PC was everywhere, and the Amiga was fading, so I got a PC, even though it was ridiculously primitive. While building PCs was fun, everything was a struggle. DOS was crappy, you had to fiddle with memory managers, no multitasking, a terrible file system, and so on. Windows 3.0 was not the dominant player that it would become with Windows 95, and you still did many things in DOS, such as programming. On the positive side, the gaming situation was pretty much as good as it had been on the Amiga. The 1990s was a great time for games.
But it's insane that so much superior tech existed at the time, yet we lost of all that to MS-DOS. It wasn't really until Windows 2000 that we had something decent again, even then it was quickly derailed. I really appreciate that Apple came back and MacOS X became an alternative.
Even better - Free Pascal comes with Free Vision, which is mostly compatible with Turbo Vision. Turbo Vision was the toolkit Borland provided that would let you write your own text-mode GUI apps using the same widgets used to build the Turbo Pascal IDE.
If you check the website demos and the "dos.h" source on GitHub, this is a library for making GUI apps whose UI has the appearance of being made with MS-DOS.
Unless I am misunderstanding the connection you're trying to make, which is also possible
[0] https://github.com/Swordfish90/cool-retro-term
[1] https://camo.githubusercontent.com/a88479dfa171e61f02f831bff...
Related for current web
Not clear if I can use this or not.
It's available under either MIT or Unlicense (public domain)
The demos that work are stunning and inspiring.
I have my own parental control software I wrote. (Maybe one of these days I will open source it, but not in its current state.) I wanted to use text-to-speech to send audio messages to our son ("Your time is up in five minutes!" kind of thing). Windows has a bunch of different APIs for this – there is an older COM API (which supports IDispatch so you can use it from VBScript etc), a newer .Net API, an even newer WinRT one. I decided, for my purposes, the easiest thing to do was just call the .Net API from PowerShell. So, I embedded a PowerShell script in my executable.
All works – except suddenly Microsoft Defender says it is a Trojan. (Forget which one, it was one of those !ml ones, so it could have even been the same one.) Only when it sees the embedded Powershell script in the executable, took it out and it doesn't.
I found a trick – I gzipped the PowerShell script, and embedded the gzipped PowerShell script in the executable instead. I included in the executable a zlib decompressor library so it could decompress it at runtime. Suddenly, no more false positive, Defender thinks my executable is fine.
I also found it gets upset if a Windows service runs PowerShell as a subprocess with certain command line arguments (passing the PowerShell code to run on the command line)–it will block the PowerShell subprocess from starting. Again, various tricks – such as Base64-ing the code to be run, and having PowerShell decode it and then evaluate it dynamically – and it no longer complains. I suppose other approaches, such as putting the code to run in a temporary file, or passing it to PowerShell over a named pipe, might also do the trick.
Makes me think the whole thing is pretty stupid – if I can use these simple tricks to get around their false positives, why can't malware authors use the same tricks to turn true positives into false negatives?
I have not tried releasing anything for Windows ever again.
I completely understand that if someone doesn't use a platform themselves, there might be little motivation to test things on it. No hard feelings if someone doesn't care to do that. But it's not that much effort.