David Schwartz

I think the problem we're sort of debating here is abstraction levels. The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up. Thus, I was familiar enough with it to recognize what a HUGE accomplishment it was that Delphi was able to totally hide it! That said, it took me a while to get comfortable with Modal vs. Modeless forms and the quirks they have at their edges. Over the years, I've seen so much code where the authors of certain forms were NOT really aware of the differences, which is usually when the app's Architect mandated a specific calling sequence for creating and disposing of forms that was likely an attempt to impose some (misplaced) consistency everywhere in the app. This always leads to some strange contortions in certain places in the code. I'm consistent enough in my own use that I pretty much don't worry about it. It's when I have to deal with code written by several different devs who themselves aren't consistent. I've got other beefs about how forms are managed, or mis-managed, by most Delphi devs, but that's more of a religious debate that nobody ever wins. (It's what inspired my CodeRage 9 talk.) Anyway, it seems reasonable that the normal abstraction levels that we're using to create and interact with forms should reflect a consistent implementation under the hood. I doubt 90% of Dephi programmers have ever seen what's involved in the Win Msg Loop, nor should they need to be aware of it. Except for the quirks that David points out. (Or why, although Forms are normal objects, nobody wants to create or use normal properties to move data in and out of them like every other type of object they'd do that for... but I digress.)

I don't know if it helps, but I gave a talk at CodeRage9 where I covered this topic as part of a larger discussion. Here's a link to the sample files: https://www.dropbox.com/scl/fi/l3026lqvdaqgu9pwbgwey/CodeRage9_code.zip?rlkey=iim76ulqxf7shg2zv4zx155oc&dl=0 You can view it here

I use TMS WEB Core to build web apps in Delphi. They run in the browser, and don't require any knowledge of javascript. I'm also learning how to use Latenode to build proxies to 3rd-party services that I can call from my client app so I don't need to implement them in a dedicated back-end service. It's similar to Zapier and Make, but I think more powerful and generalized.

Really, how ? procedure TMain_form.WebFormClose(Sender: TObject; var Action: TCloseAction); begin Action := caNone; end; Clearly obvious to even the most casual observer, right?

Setting ModalResult can be overridden, as well as Close, in some damned obscure ways. That's all I'm saying. But calling Close after setting ModalResult is completely unnecessary. And if setting ModalResult isn't closing the form, then tossing a call to Close in there may or may not work, or may not do what you expect. This is based on my experience. YMMV.

If it's a TreeView or a ListView, make sure you don't have an OnChange handler wired up -- or if you do, you want to put a flag in it that says: if ignore_this then Exit; And have a var at the top of the implementation section var ignore_this : Boolean; Set it to true before you start your loading up, and false when you finish. Or you could un-hook the OnChange event before you start and replace it when you're finished.

Unless you have a clear understanding of ALL the hidden things that Delphi does, you should NOT DO ANY OF THEM! "Hoping you're right" is not a reliable way of writing code. That Close call might not even be getting executed because the assignment to ModalResult calls a method that has side-effects. One of those side-effects is that the assignment is NOT made and is ignored. I've seen that happen from time to time. It's best to avoid any kind of state-altering logic inside of event handlers, because they can end up causing infinite loops, or triggering other things that you aren't aware of. What you're doing here can alter MULTIPLE states!!! As a result, the DB could be on a different record or even closed when the ShowModal gets control back. Just. Do. One. Thing. At. A. Time.

Actually, it turns out he's a contractor and I think they "parked" him on this project until his contract runs out. I've had that happen a couple of times when the client was obligated to pay the job shop the full amount of the contract and the contractor left (or was kicked-out) and I was hired to fill out the remainder of the term. It's not fun, but they're not expecting much.

It never seems like there is. What is this thing simulating?

I’m looking for a tool that lets you hook into a browser window while a web app is running and access the DOM, allowing some AI prompts (eg., ChatGPT) that I've written to execute, maybe via a popup menu. What I need is the ability to simulate an EXPORT and IMPORT process in a web app that doesn't offer it, taking the data from the fields in the current window and letting you save it as, say, a JSON file; as well as letting you open such a JSON file (eg, with edited values) and use the data in it to fill the fields where the data is intended to go. I use RoboForm regularly, which has a way of doing this, but it's mainly for managing login forms like LastPass, 1Password, etc., so it's clearly possible to create such a bridge using a browser plugin. It lets you save and fill forms, but the data is saved to its own internal storage; I need it sent to a JSON file that I can save to disk or pass on to some other app somehow in terms of the EXPORT process. Importing would require opening the JSON file on disk or maybe have it pasted from the clipboard. I don't really care what browser, but Chromium is the most prevelant. Just wondering if anybody here knows of something that might do this. Maybe a debugging tool, or a type of "screen scraping" tool, or just something like RoboForm that does exactly what I want.

Yes, that's what I was thinking, and why I mentioned RoboForm. Thanks. I posted this on Reddit and a guy replied saying he pasted my question into ChatGPT and tweaked the prompt a bit, and it spat out all of the code needed for a Chrome plugin -- he said he tried it and it worked fine. Although, I'm a little skeptical because he changed the description just a tad, and it's not exactly what I asked for. But it was a valid approach. (I'm thinking he tweaked it to make sure I tried it myself and didn't just blindly copy-and-paste, which I know can be rather dangerous.... or maybe ChatGPT changed it.... hmmmmm)

Please don't take this personally, but who in the hell hired you for this role? And WHY??? Like the other guy said, this is a task even highly experienced Delphi experts would be nervous taking on. I mean this in the best way possible: turn around and run away as fast as you can from this project!!! You're extremely likely to get fired long before it's finished, and they'll likely come up with some totally off-the-wall reason -- they can't exactly say it's because you're unqualified, because THEY KNEW THAT ALREADY! You may have learned something from it, but you won't be able to use them as a reference, and all you'll be able to say about it was you made some money and hopefully have all of your limbs still intact. I've got a few jobs like this in my past that I don't talk about ... hired for something I knew nothing about, thrown into the fray, didn't know what I was doing, then confronted by an upper-level manager who I'd never met who yelled at me and threatened to fire me, then did. The whole time I was wondering, "What in the heck am I doing here?" I once talked to a guy who left engineering to be a recruiter. He said he did really well at it, in a very simple way: He'd invite a bunch of mid-level managers to a free lunch and ask them if they had any projects that were behind. They'd all raise their hands and he'd ask how many of them had at least ONE they ran that they didn't think would actually finish on-time or on-budget, and they all raised their hands. Then he asked, "who's going to take the fall for that?" They all got really silent and he didn't say anything for a good minute or so. Then he said, "the CONTRACTOR!" He said he had one of the highest closing rates of anybody at the company using that approach. And I had a few jobs come to mind that seemed to fit that perfectly. And a few more over the following years, only at that point I had learned to recognize it. I don't mind being hired as a "fall guy". The annoying part is, nobody wants to tell you, even though it becomes pretty obvious before long. It's not fun. The worst part is, they usually make up some cock-and-bull story that they tell the recruiting firm that makes you persona non grata with them after that. Maybe I'm naive, but I couldn't imagine that the recruiters weren't in on the gig as well. Ask some questions about the history of the project and see if you can figure out why it has taken them so long to do this. There's definitely some politics involved; maybe the person who kept blocking it finally left, or a new manager came aboard and he wants to get this thing killed ... there's something going on there with this project. You're the wrong person for the job, so why did they hire you? (Maybe I'm totally wrong, and it turns out to be the best job of your life and everything works out great! Time will tell.)

I'm sure most of us here have spent many hours trying to solve this very problem early on in our Delphi years. There are several ways of solving this. None of them are "right" but they all work. Some seem more elegant that others, but that's always a matter of taste. Frames are nice, but they can be a PITA to work with in the IDE vs. at run-time. (Or they used to be, anyway.) Good luck with it.

I don't mean to sound mean or burst your bublle, but I think you're being set up for failure. You're also talking about a year or two of learning. What you're asking about isn't going to be found in a book. You'll learn it by working on a bunch of different systems and applications over time. If you want to learn OOP/OOD, then take a class -- learn Java or Typescript or C#. This is not the right project to learn it on. Find a project that's already up and running, with the latest (or very recent) version of Delphi, that's on Win 10 or 11, and where there are some others there who can mentor you and answer your questions. The fact that they hired someone who knows nothing about Turbo Pascal or Delphi or anything related to the application, rather than an expert with many years of experience with it, tells me they do not expect a good result in a timely manner. I've been working with Delphi since it was released and can practically write it in my sleep. But the last several jobs I've had all began by being told, "DO NOT TOUCH THE CODE! Just READ it and become familiar with the overall design." They typically expected it to take 3-6 months before they'd let somebody new touch anything, and that's in a situation where there were several experienced Delphi people on the project. Then they'd have me write up something where I had to show them exactly what lines of code I was proposing to change, in what order, and how to test that the changes worked and there were no side-effects. I was every bit as much of a "Delphi expert" as they were, and in some cases, even moreso. Still, it takes a LONG TIME to learn how a non-trivial piece of software is designed, even if you're an expert in the language. If you don't know either the language or the design environment, you're a goner. At my last job, after a month they gave me something that their IT Mgr had "analyzed" and concluded it would take a week AT MOST, to simply "migrate" this one Delphi app from WinXP to Win10. It turns out that the details the IT Mgr had given me were completely BOGUS -- he just looked at some activity going on in the file system for 30 minutes and made up some crap about what he thought was going on. He thought he was watching files being processed and inadvertently deleted. What he was actually watching was a bunch of temp files being created and deleted by a DLL. When he tried it in Win10 and watched it run, it did not behave the same way. Well, DUH! The problem was the DLL was V1.0, released initialy when WinXP was released, it did not run correctly on Win10. To add insult to injury, their license prohibited us from using it the way we were -- which the IT MANAGER should have figured out already, but didn't. That's all I managed to learn in the first week. And some VP had the gall to ask "Did you get it migrated yet? Yes or no?" I wanted to say, "What part of 'the DLL won't run on Windows 10' don't you understand?" Basically, the findings I reported made a bunch of people look like fools, and they weren't happy. But all of this "analysis" was done before I was even hired, and nobody bothered to explain any of it to me first. My point is, you're very likely on a fool's errand here. Your employer could hire experts like me or many of us here and we'd come in, and after studying that app for a week or two basically say, "it's impossible to do what you're asking". YOU don't even know what you don't know -- and THEY KNOW THAT! It might be 6 months of struggling to learn Delphi and all that stuff before you finally come to the same conclusion. You're being set up. My experience migrating old apps like this into the current version of Delphi and Windows is ... it might work ... but more than likely it's going to take some signficant rework and testing to find any parts that depend on obsolete Windows APIs, DLLs, and other libs that may be obsolete and cannot be replaced easily. Meaning that while your desire to learn Delphi and OOP and all that stuff might seem applicable, that's not what's going to keep that app from being easily migrated. Yes, it might compile. Most likely, it won't. And if you don't understand how components and libraries work, or if there are any DLLs or Windows APIs that won't work, you've got a LOT more work ahead of you that's got little if anything to do with Delphi programming. That DLL I mentioned that we couldn't use ... the company refused to sell us the latest version, claiming (rightly so) that their license did not support our use-case. They wanted to sell us access to their own online REST service that they estimated would cost $10k-$15k PER MONTH!! Management looked like someone just stuck a pipe up their butts when they heard that! "Oh, it's just a simple migration" they were told. "It's just a few days of work" they were told. "It won't take much effort at all" they were told. I had to find a replacement for that DLL and ended up finding a library written in Delphi, and it cost under $100. Then my boss had to deal with HIS boss arguing about "spending so much on such a basic library" for a week... I hope you can see that NOTHING I've mentioned here has ANYTHING to do with DELPHI, OOP, or any of the stuff you're asking about. It's just that you don't know that, and your bosses think that's the problem that needs to be solved, just like my managers did before they hired me to work there and assigned ME to do that simple little "migration" from WinXP to Win10. Honestly, I wouldn't touch that project with a 10-foot pole. Been there, done that, and there's no nice outcome. Everybody is going to be looking to shift the blame, and it's all going to land in YOUR LAP. If you're a contractor, I'd bail out of there fast. Somebody well above your pay grade f*cked up and they're looking for someone to blame it on.

I spent some time asking around and posting things in different places, including going to an Apple Store and talking with their "experts", trying to get an answer to a simple question: I have an Intel Mac Mini running a VirtualBox VM that has Win 10 running in it. I use Delphi to build stuff, mainly web apps using TMS WEB Core. My goal is to MOVE that VM over to a new M4-based Mac Mini. It seems that when you cut through all of the handwaving and BS that Apple, VMWare, and Parallels Marketing machines have published, the answer is a flat NO, IT'S NOT POSSIBLE. Can anybody prove that is INCORRECT? If so, please answer these questions: * What version of Delphi is it? * What version of Windows did you have on the Intel box, and what version are you running on the Mac? * What VM platform (VirtualBox, VMware Fusion, or Parallels) and VERSION are you using? * What Mx chip is in your new Mac? * How EXACTLY did you MOVE the earlier VM running Windows 10 over to the new M-series Mac?

Before there was a GUI app like Delphi or VB, there was TurboVision (IIRC) and it was a C++ framework that let you write code that generated a GUI. And around that time there was the Windows SDK that required you to use two different languages to write a GUI-based app for Windows, and neither of them had a GUI. It sucked. It could be argued that both of these approaches embraced console apps that ran GUIs. In fact, before Windows, there were C libraries that let you build GUI apps entirely in code. I used a popular library called Vitamin C. Delphi is sort of a misnomer. It's really two things: an extended version of the Pascal language called Object Pascal; and a GUI-based development environment built with a very innovative (at the time) event-driven library that implemented a bunch of visual controls, called the Visual Control Library, or VCL. Delphi was supposed to be TurboPascal 8 IIRC, but it was released under its code name of "Delphi". Internally, it still uses product numbering relative to the original release of TurboPascal. And you can still compile old versions of TP code with it. So technically speaking, if you don't USE any of the VCL library units, it's just using stdin, stdout, and stderr for I/O, making the resulting app operate as a simple command-line tool. That would be like buying a nice new car and removing the entire shell so it's just the floorboards, A-frame, drive train, engine, and maybe a stool to sit on while using a vise-grip on the steering wheel shaft to turn. It's certainly possible. Do you know of any driving schools that teach that approach to driving? Driving schools could start out teaching everybody how to drive a stick-shift as well, but ... when was the last time you saw a new car with a stick-shift in a dealership? People who learn to drive them usually start off with a pickup or sports car from the 60's or 70's.

In the 80's and 90's I was doing embedded systems stuff. I knew a lot of small developers chasing Windows as it evolved, and who eventually went bankrupt. From what I could tell, each time a new version of Windows came out, they had to throw away a lot of the framework code they had developed, head off to Seattle for a couple of weeks to get certified with the latest tools, then come back and start over again. Large corporations were able to absorb those costs, but not small developers. I kept my head down and focused on embedded systems that were not heavily dependent on Windows. Most were DOS based or used a real-time kernel and had their own development systems. When Delphi was announced in 1995, I was there and got a copy they handed out. I was quite intrigued at the presentation and started playing with it when I got home. I found it really easy to work with. It totally hid the dreaded "Windows Message Loop" and handled all of that crap invisibly. You could do everything in the same language and platform (both apps and component "extensions"), unlike Windows stuff at the time. It was quite a game-changer. I incorporated Delphi into a couple of projects and then started getting leads to work with it more directly. In January of 2000 I started a job working with Delphi at the BioDesign Lab at ASU, and was there until mid-2005. After that, Delphi work was far easier to come by than embedded stuff, and paid much better, too. I love Delphi. I don't care for Windows. I don't see a contradiction. If the Delphi IDE ran in MacOS, I'd be happier working with it, because I find Macs are just far more stable. I have it running in a Windows VM hosted on a Mac, which is the next best thing. I'm semi-retired now and have been focusing on building web apps using TMS WEB Core, meaning I don't need to give much thought at all to the Host OS. But the Delphi IDE still requires Windows to run. FWIW, the last two jobs I had took up most of my time dealing with platform issues. The last place I was at, the entire (original) dev team left in 2014 except the main Architect and another guy, both of whom had only been there for a few months. The Architect had left and I was hired to replace him. Then the other guy left. But prior to my starting, there was a standing order not to make any substantial changes to the code. Nothing had changed in the core system since 2013. A few months before I started, upper Mgt required everything running on Win XP and Win 7 be moved over to Windows 10 and Server 2016, and that caused a TON of problems. One thing I was assigned to "port" was using a V1.0 DLL from 2014 that was running on WinXP. It did not run properly on Server 2016. We weren't even conforming to the TOS in the way we were using it! The guy who did the "analysis" was totally wrong about his conclusions. They expected it to take a week or two; I spent over two months on it. I had to rewrite half the code to get this working in Server 2016, in part by replacing that DLL with a different 3rd-part component library. Mgt saw that as "unacceptably long". We were constantly fighting with Windows changes being forced upon us by lawyers and legal threats. All of this was in the face of, "DO NOT CHANGE THE CODE!" Over 80% of the work I did from 2017 thru 2021 was dealing exclusively with changes forced by Windows updates or switching DBs. I crave coming up with new and innovative solutions to novel problems. Dealing with platform conflicts is monotonous, unsatisfying, and boring.

Welcome to the Delphi party! I've been working with it since it was first introduced. (I was there when it was first announced.) I'd suggest buying an ALL-ACCESS pass with TMS and play with their stuff. They've got quite mature and stable tools for most of what you'll need. I've switched to mainly using TMS WEB Core for my work. It's used to create web apps. It's based on an open source tool pas2js that translates Delphi into javascript. They're in the process of releasing support for TypeScript, which is going to open even more doors. Web apps don't need licensing because they require logins. TMS has a whole package for that, Sphinx, and there are plenty of other ways to do it as well. If you find a solution that works in js frameworks, it'll probably work with WEB Core. They recently released their own DB SaaS product, StellarDS. You can build a DB web app as easily with WEB Core and StellarDS as with VCL and MySQL, SQL Server, or many other common DB servers. WEB Core creates apps that run inside of most web browsers. So you can write it once and not have to keep publishing updates as each of your environments changes. I guess it depends mainly on where you want to spend most of your time -- innovating or keeping up with platform changes and all the headache that entails. Also, TMS has extensive libraries for both VCL and FMX. They also have one called FNC that targets whatever you're using -- VCL, FMX, and WEB Core. (I don't know if they're going to split WEB Core into JS and TS or just make it a targeting option; it's still really new.) It still blows my mind every time I write an app using WEB Core in the Delphi IDE, hit the F9 key, and it opens in a web browser. "Write once, run anywhere" was mostly a pipe-dream for Java, but that's pretty much what WEB Core gets you. It's very cool. 🙂

Yes I am very wordy. Sorry. I think the point you're not getting is that I do not like Windows. I only dabbled with DOS while earning a nice living developing embedded systems that used more reliable real-time kernels. I dabbled with Windows when it came out as well. I only started using it more after Delphi was introduced because it was easier to find work writing desktop apps in Delphi than embedded apps. I still like workig with Delphi, and I run it inside of a VM that runs on a Mac. I only wish Embt cared enough to make a Linux target in Delphi specifically for non-GUI apps and included it in the Delphi Pro package so it could be used to build services that can be easily published on common Linux servers used today, since they outnumber Windows servers by a large margin. But my point was that Unix supported very sophisticated shell scripting 20 years before MS bothered to improve the command shell beyond what it was when DOS 2.0 was released. Bill Gates publicly stated many times that he thought the internet was just a passing fad, until it becamse painfully obvious that it wasn't (in terms of lost unit sales and revenues). Perhaps that was because the internet was pretty much born and raised on Unix systems and Gates didn't want to acknowledge that. He has always had a severe case of NIH Syndrome. Anyway, that's all I'll say about it.

I first learned Unix shell programming in 1985, 20 years before PowerShell came out. In January 2006, Apple switched all of their MacBooks and iMacs over to Intel CPUs. I bought one before PowerShell came out and never looked back. To this day, I still export some code files out of my Win VM into the Mac environment so I can run vi or some editor that lets me apply more powerful regex expressions to make complex edits that I have so internalized that it sometimes take a dozen or more tries to get them to work in Windows or even the Dephi IDE's editor. I always found writing shell scripts in *nix to be a lot of fun, while writing DOS BATCH scripts was ALWAYS painful. And because *nix command shells offer 100+ very rich 'commands' available to pipe things into, it's far more productive. I had 20 years to master that stuff before MS finally took it upon themselves to bring Windows into the 20th Century that Unix has had since the 70's -- only they waited until the 21st Century to do it. 😕 For example, just compare file, find, and grep in DOS / Windows with those in any *nix platform. I did a lot of DevOps stuff for several years, and even today it still relies heavily on the use of lots of scripting languages, only it's usually newer stuff, not command-shells as much. I've written a number of *nix-like commands in Dephi over the years. I don't think of them as "console apps". They're just little utilities that are structured pretty much the same as most other *nix 'commands' that were typically written in c or some other scripting language. The command shell environment that was first defined in Unix still lives on today in all of the various Unix derivatives, including all Linux platforms and even the MacOS Terminal, which is simply a window that opens a command shell, like typing Run or Cmd or Command or whatever it is, into the Windows search bar. (Sorry, I have very little need to run things in the Windows Command prompt. I usually just click the little black box representing a terminal window.) Back when there were no fancy GUI environments to use, all you had was a command shell. So programming books all taught that approach. It does not surprize me to see console apps being taught in Delphi programming books, other than they're devoid of any larger context, like when you're learning to create commands that run in the *nix shell environments. Shell programming in *nix is an entire ecosystem, and most of the programming tasks you learned at first involved how to extend it. Historically speaking, DOS had a horribly limited set of built-in and external commands, not to mention pipes that wrote to temp files and weren't threaded so they went from one command to the next to the next in a fully synchronous fashion. At some point, the Win Command shell was made threaded and files were saved in memory streams rather than written to disk in their entirety before being passed to the next command. Today, a lot of programming books teach how to write "console apps" because, while there might be a rich ecosystem of stuff available at the command shell level today, nobody knows about it. It's silly to learn to write 'commands' that extend the command shell's ecosystem when you don't know how to write shell scripts that leverage all of those commands. So people ask, "Why do I want to write a word count (wc) console app?" Because it teaches you the basic structure of how to extend the command shell's ecosystem. Only most folks are probably unaware there even IS an entire ecosystem there. At least, there is in every Linux and *nix environment (like every Mac computer that has ever been built).

That sounds like making underwear for people with a left leg, a right leg, or both. Given that most of the world has two legs, it seems like a lot of needless work to deal with just one or the other.

This is quite an interesting discussion. I worked at Intel for the first 5-1/2 years out of college (early 80's), and the software I wrote was all using their proprietary tools and dev systems. In fact, we used stuff written under contract (in the 70's) by the guy who wrote CP/M: ISIS, which was a command shell similar to CP/M and DOS; and PL/M, a language inspired by PL/1. I spent 2+ years writing tools that today would fall into the realm of DevOps. ISIS had a way to run scripts called "BATCH" files; they were just text files that contained stuff you'd type into the command line in a file ending with a .BAT extensions. PL/M was a compiler that produced .COM files initially, and then we got a linker that allowed us to make .EXE files from .OBJ files the compiler produced. Given that the same guy who wrote ISIS also wrote CP/M, it was no surprise that the DOS command shell looked just like both of them. Unfortunately, over the years, it has barely evolved. I started trying to write PL/M apps that did tons of stuff, but we didn't have sufficient memory to load them. So I ended up building small specialized tools that did one thing really well. I then wrote BATCH files that strung them together using some logic to do branching and stuff. I was responsible for building the code for 4 projects that combined took some 25 hours to complete. I wanted a way to have the batch files figure out if there was an error along the way and stop everything. By the time I left, I had managed to reduce a totally manual process to a fully automated process that ran on a small network of five workstations that took right around 9 hours -- while the size of the code base had nearly tripled. I got caught up in their first layoff, and ended up being hired at Motorola a month later to work on their port of Unix System V Rel. 3 to the 68020. That was my introduction to Unix, C, and the magical world of command shell scripts. The most fascinating part of the various Unix shells was that they had this "pipe" thing, a vertical bar '|', that let you send the output of one command directly into another command rather than temp files. WHOA! You could build long strings of commands in just a few lines that did an AMAZING amount of work. The stuff I was working on there allowed me to wrote most of my prototyping code as shell scripts. For stuff that needed to run fast, I wrote little programs in 'c' and incorporated them into my shell scripts. All told, the scripts ran amazingly fast because most of the heavy lifting was being done by executables written in 'c'. It turns out that in doing my DevOps work at Intel, I had invented some 2 dozen common Unix command tools, a distributed 'make' tool, and had spec'd out several more that I hadn't gotten to yet. I was thoroughly amazed at how much stuff I had created simply out of necessity that had already been around in the Unix world for well over 5 years. The whole scripting ecosystem originally developed in Unix, as well as the parallel approach I took with my work at Intel, evolved simply because you could not build really large executable programs back then. Unix shell scripts were very lightweight, while the 'commands' (executables) were very small and efficient and could be loaded into memory quickly when needed. The two formed a symbiotic relationship that allowed you to write complex apps that ran from the command line very quickly. And they ran very fast as well. To this day, *nix shell scripts look and act just like any other commands you might want to run. You don't even know that they're shell scripts unless you try looking at them. If somebody's point of reference for not wanting to work with shell scripts is only based on DOS and Windows, then I can understand their reluctance to take that approach. When I left Motorola, I bought a PC that ran DOS 3.2 then 5.0 (or 6.0?), and found the DOS command shell was about the same as the ISIS shell written in 1977 that was still being used in Intel's products at the time. It SUCKED! I happened to find something called the "MKS Toolkit" around 1988 that was the first DOS port of most of Unix shell commands, plus the ksh shell. WOW! It had the same power as what I had grown accustomed to while at Moto. That's about when I was introduced to Borland's Turbo C for the first time. Anyway, I think the use of shell scripts to navigate around small specialized executables has become a lost art, mostly because you can build humongous apps now that barely make a dent in the multi-gigabytes of RAM modern computing platforms have. Bill Gates was once famously quoted as telling an audience at a keynote at COMDEX or some other big industry conference that, "Nobody would ever need more than 640k of RAM!". When I think back on all of the different techniques software vendors employed to overcome that arbitrary limitation, it makes me shudder. I don't think it's an accident that most web servers today still run code that's nearly all interpreted. Microsoft tried to change that, and it's one reason why building server-side stuff for WIndows has always been very different than it is for Linux servers. I don't have a problem with "console apps" per se -- they're just what Unix and Linux call "commands". What I have a problem with is that they're mostly designed to run in an environment as desolate as the Sahara Desert when it comes to highly-specialized tools that reduce your need to constantly re-invent the wheel, as well as the absence of a rich and versitile command shell that ties them all together. You'd be amazed at how much you can do in virtually ANY Linux environment just using sh, bash, ksh, csh, or some other shell, when combined with the rich set of 'command' tools that started life in Unix back in the 70's. Not to mention how fast and efficiently they can run. Shell scripting is just as powerful today as it was back in the 80's. It's just a lost art because the hardware limitations that existed back then are no longer relevant. If you think they're slow and inefficient on a multi-core 3GHz CPU, you should have seen how fast they ran really complex applications on 20MHz 386 chips with only 512k of RAM.

I've used both Plesk and cPanel, and I'm not going to debate which is "best". It's true that Plesk is found mainly on Windows hosts while cPanel is mostly on Linux hosts, and in my experience cPanel adds less to the hosting costs than Plesk. Plesk seems to be marketed more to corporations while cPanel is more attractive to SMBs and people with smaller budgets. That said, both are great at allowing you to admin your machine. My biggest gripe about Windows is that it's just too frigging complicated because of all the security crap that has been added over the years since Win NT. The control panel is just another layer on top of whatever the OS provides, and I've always found *nix to be far simpler than Windows. I learned how to admin a Unix box back in the 80s and a lot of that knowledge is still relevant today. I grew up learning DOS and CP/M and then Windows, and for the past 15+ years while I was a working stiff, I've had access to an IT Dept to deal with the Admin side of Windows, so I'm way out-of-touch with it. Frankly, there's not much I learned from XP and NT that seems to apply today, and it just drives me nuts having to deal with it. Twenty years ago, my then wife's Windows machine got a virus, and it took me around 10 hours to isolate it and get rid of it. That's because I couldn't find any anti-virus software that found anything and I didn't feel like reformatting the hard drive and starting over with a clean install. In contrast, one of my Macs seems to have gotten infected in the past week or so, and it only took me about 4 hours to isolate the source and nuke it after Malwarebytes found nothing. I'm far more comfortable doing Admin stuff in *nix than Windows. I've had some Windows servers and none of the hosting places offered Plesk. I bought a little box to use for some dev work and a Plesk license costs more than the box did! So if you have the budget and stomach to deal with Plesk and Windows Admin stuff. knock yourself out. I'm semi-retired now and really want to focus on things I ENJOY doing, not learning enough to start a new career. FWIW, I'd rather put in the time needed to learn to fly a plane than become a Windows Admin! Neither one of them will make me any money, but flying seems like a hellofalot more fun than Windows Admin stuff.

Yep, this is pretty much what I've concluded after about 10 hours of messing around and digging through all of the explanations about how to do what y'all say is impossible. Will any version of D10.4 run on an M-series Mac? I've read where 32-bit code will NOT run on an x64 ARM version of Windows, and I'm not aware of when Delphi was fully converted to x64 architecture. I'm leaning more towards using my Intel-based Mac Mini to just running the VM with Delphi in it, along with just a few other things, for maximum performance. (It has a 6-core i7 with 36GB of RAM, so without a bunch of browser windows open, it really screams.)

NOTE: I'm not sure if this best fits into Network, Cloud and Web area or the Cross-platform area, as it seems to span both. A while back before I started working with WEB Core, I asked some questions here about how to work with threads to synchronize calls to APIs. They created a lot of noise, in part I think because there are several different multi-threading libs and idioms that offer a variety of features and benefits that fit some needs better than others. WEB Core came out shortly after that and I started playing with it. They take Dephi code and run it through pas2js to transpile it into javascript. They were able to modify the input language slightly to make it easier to map code into common js idioms, by providing an [async] attribute and an await(...) method. There's also an async; tag that can be placed in certain places after a method definition. I've been working with this stuff for quite a while now, and I often forget to use one or the other of the above annotations correctly. It doesn't help that the compiler does a poor job of keeping attributes attached to the lines they affect in the class headers, which causes other headaches. I wrote something last year that is a multi-step process that involved a ton of API calls in each step. Although the idea was to make much of it run in parallel, the syntax requirements and sync dependencies made it quite messy to accomplish. Maintaining it got to be a nightmare. However, TMS just announced that they are incorporating a fairly new open-source async library into their stuff that appears to solve a lot of the complexity issues I ran into -- and I bet a lot of folks who don't use TMS products for this have as well, since it addresses a quite generic problem. Here's the post in their blog where they announced it: https://www.tmssoftware.com/site/blog.asp?post=1296 There are links in that article where you can find the original source code (on github) where the docs and code libs are found. This approach does not require any changes to the language, yet offers a clear and fairly simple approach to dealing with the async nature of remote APIs without undue burden on having to manage tons of threads. TMS has retrofitted it into one of their FNC libs (the FNC Cloud Pack) that can be referred to for your reading pleasure, and it looks like they might be expanding it to other libs as well. The point is, this library is written for Dephi and is fully independent on any of TMS' own tools. It might be worth looking at if you work with code that's a lot more convoluted than you like due to the need to synchronize a lot of calls to external APIs and services. I haven't had a chance to do anything with it other than read through the documentation; but after the nightmares I had from the sync-related code I was working on last year, this lib looks quite promising. I can see why TMS likely chose to adopt it -- not just for new code, but they're even making a considerable effort to retrofit it into their exising packages, which isn't something that's ever done without quite a bit of close scrutiny.