David Schwartz

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 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?

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.

If you prefer working from the command line, why not just use something that's oriented that way? I mean, you don't need a language as complex as Pascal to write simple scripts. Try playing with bash or sh or ksh or some other shell scripting language. The thing you're missing in just focusing on the command-line is not the GUI, but the entire Event-Driven ecology. That's what really sets Delphi apart from even simple Pascal. if you don't want to mess with a UI, then consider playing around with back-end services using one of the many REST frameworks that are available for that. Nobody gives two craps about Pascal today. Delphi is still alive and kicking because of the VCL, which is mainly an EVENT-DRIVEN FRAMEWORK. That's how it SUPPORTS such a rich and complex GUI environment. The basic Pascal language and RTL is available to command-line apps, but nothing from the VCL or FMX frameworks are, even though that's where 99% of the VALUE lies.

Well, writing web apps in Delphi is not something I'd want to do. They have to be built as something like ISAPI modules (basically, DLLs) running in a Windows host. Not my idea of fun. You really should look into TMS WEB Core. It's sort of an "add-in" to the Delphi IDE that lets you use a slightly enhanced version of Delphi (without inline var support yet) that gets compied down to javascript. You can hit the F9 key and your app will open up inside of a web browser. It's really awesome to see in action. They also have a version that runs in Visual Studio Code. Visit their website to learn more. I think it's quite revolutionary. As far as hosting goes, hosting is hosting is hosting. All that stuff you might see as "clunky" is just the crap a vendor ads into the environment that you have to pass by while getting to your destination -- like how the grocery stores always put staples at the back of the store and all of the newer and more profitable stuff towards the front so you have to walk by it on the way to get your milk and meat. If you want to get some experience with hosting, grab something like LAMP or MAMP or WAMP (Linux/Mac/Windows) and install it in your computer. It loads up everything you'll need to do web development on your local machine. Win 10 includes a Linux subsystem that has these things included as well. A lot of people use FTP to upload stuff to their server; I just prefer to stick with cPanel hosting and use it's FileManager to upload files to the file system. It doesn't let you copy a file tree, but that's easy to solve by making a zip file of your file tree, uploading it into the folder where you want it, then unzipping / expanding it there. It's way easier than messing with FTP IMHO. If you're working with a Windows server, you'll need to use RDP to get into it. Linux can use SSH which just gives you a shell, although that's only avilable if you have a dedicated server with root access; otherwise, just use whatever your control panel offers (like cPanel's FileManager). When you visit different hosting providers, if you look at enough of them, you'll find they're all selling the same few distributons of Linux, or some Windows version. If you're using Delphi to build a REST service, you'll probably need to use a Windows host -- unless you can generate a Linux target.

I'm curious if anybody knows of any FOSS Delphi interpreters. TMS has had one for quite a while, and I worked with it on a project many years ago. But I think it's overkill for what I'm looking for. Besides, it's not FOSS. What I'm interested in is building a REST service that runs on a standard Linux host (eg., CentOS) and has a way of adding services by uploading a source file written in Delphi rather than having to upload compiled code. Delphi purists will say that's way too inefficient, but It's not like running interpreters on back-end servers is an unusual thing, since most such services are written in php, python, and even VB. Anyway, it doesn't need to "run fast", as long as you can easily spin-up multiple servers running the same code. I don't think it needs to support 100% of the latest Delphi language features, maybe just to D7 or even the version after D2010 with stable generics. As an aside, I cannot comprehend why Delphi has no support for Linux except for distros that conform to specific UI needs, when most people want to use Linux to run services, and most Linux hosting is all headless. There should be a way to build headless apps (ie, no UI parts) for common Linux distros in all Delphi versions.

Thanks for this. Is it useful without a run-time license for DevEx? if you use generic Delphi code that can be tested in Delphi then loaded somewhere to run under DWScript, can you get by without DevEx?

I hate SOAP. I've used it on a couple of Delphi projects, and worked on a couple more where someone else was dealing with it, and the amount of effort needed just to get it to do basic stuff is horribly distorted. But when you're forced to interact with a system where all of their external APIs are built in SOAP, you're stuck with a pig-in-a-poke, IMHO. I know one guy who'd first build it in C# just to make sure the specs he was given were correct, because he said that devs frequently update the interface but don't update the public docs (that often involves two different teams). In one of my cases, Delphi's WSDL compiler generated crap, and I had to use a 3rd-party compiler to make my Delphi code work. Good luck with it!

The title of this thread is "Backward compability". That's referring to the ability to take OLDER versions of projects and build them in NEWER versions of Delphi, and it mainly applies to the language features and VCL. For example, you can still compile programs that declare 'object' types that existed briefly before the 'class' designation showed up. It has been deprecated for 25+ years, but it still works. You can even build old TurboPascal apps and there's a very good chance they'll compile and run without any issues. However, going from a NEWER version to an OLDER version has NEVER been supported. Needless to say, the error you're pointing to is not even in the language nor the VCL, so it's totally outside of Delphi's product domain. Meaning ... you're barking up the wrong tree. Third-party vendors frequently add updates to their libraries. Embt updates Delphi's language and the VCL very infrequently, mostly when a new major version is released. OTOH, companies like TMS Software (among others) frequently release updates based on bugs and requests submitted by their users. I don't know what library this is, but if it's DevEx, then I believe they update their subscribers quarterly. I've worked on projects where we used components from TMS, and in some cases, certain team members loved to complain about the frequency of updates, and they didn't bother doing them sometimes. I always update my libraries regularly, especially if there's something pushed out that fixes a bug or problem I encountered. If I do that and then commit an update, it's highly likely that someone who has not updated their TMS libs will encounter these same errors when attempting to build my code. That's not my fault! Nor does it have anything to do with either Delphi or "backward compatibility". (Frankly, it's a Project Management issue.) The moral of the story is, if you update a library and commit the code for it to your repo, then try opening that latest version on a machine that's got an older version of the library installed, then this is something that's VERY likely to happen. It doesn't matter what version of Delphi it is -- this is saying a property added to a class recently is missing from the version you've got installed on that machine, which is not terribly uncommon. You need to update the library, not Delphi.

If you've ever seen a FOREX dashboard built in Delphi running on a high-speed link, you wouldn't be asking these questions about whether it's possible. Yes, it absolutely is. What problem are you REALLY trying to solve? Also, shopping carts are DESIGNED to be STATIC, so they're an inappropriate example. Stock, bond, and FOREX trading are examples of HIGHLY dynamic apps, and Delphi has been used to build all of them.

When you've got a platform that has 64-bit integers that have values that actually range from, say, 0..27, and you think that having a dozen of them in a record is somehow more efficient than using an object with a single 64-bit pointer, I'm not clear what you think is being saved. Pointers might make use of half of a 64-bit data element, but there aren't a lot of applications that have that kind of dynamic range on the values they manipulate. Floating-point values ... ok, you get a little more precision for calculating the trajectory of things flying around the solar system. But for most routine programming tasks that the typical UI does ... it's way overkill. Consider that JSON is more or less a big record with labels but not types, meaning all of the data fits into 8-bit chunks, while accesses are usually done with very inefficient linear searches. So the first thing you often do is parse them into some kind of typed data structure as a more efficient container, unless you only refer to a few of the fields and then toss the the entire JSON string away. Records are fine when all of the data is managed by a single interface; but when you're passing them around and lots of different methods are touching them, and a change is made in one instance that's not propagated down the line and nobody else knows that the value has changed, they can be horribly time-consuming to debug. Or you can make a change that you do NOT want propagated but it DOES get propagated, simply because their use is mainly pass-by-value semantics but there's a hidden copy-on-write going on. But when a Record's data is managed by a single interface, you're just simulationg a Class. So ... what's the point? You're just having to write more management code that the compiler provides for free if you use a Class instead. It's like saying you won't sell your 1980-vintage car because you like being able to tweak the carb to assure optimal fuel efficiency, while ignoring the fact that electronic fuel injection can double or triple your overall mileage -- at the expense of having to trust that it's actually doing its job. I prefer to use Classes and trust the compiler to do its job.

What I mean is, can you compile for Intel platforms and test them? I seem to recall there's a translation layer that came with the M-series chips, but I don't hear much about it when it comes to using Delphi to build WinTel code.

I do my Delphi development in a VM running Windows on my Mac. I don't know what VMs let you run Windows on non-Intel Macs -- I think VMWare Fusion is the only one ... does anybody know for sure? (I don't have an M-series Mac so I'm wondering.) The most unstable part of my systems are the browsers that slowly eat up memory because javascript doesn't have any sort of memory management and nobody seems to bother freeing anything. From what I can tell, it's the same on all platforms because it's a javascript issue. Otherwise my experience has been that Macs are far more stable than Windows machines. My Win-based VMs implode from time to time, far more frequently than my Macs do. Again, what kills my Macs is because of excessive and uncontrolled memory leakage from javascript in the browsers. I totally minimize my use of browsers inside of the VM, but it still crashes for indeterminate reasons, just like every Windows laptop and desktop I've ever used. That's what I'd call the "Windows tax". I prefer the "Apple tax", thank you. There's also the well-known fact that Windows is targeted by hackers a couple of orders of magnitude more frequently than MacOS is. To deal with this, you need to run a steadily growing layer of screening tools that eat up a big chunk of the performance boost you get from upgrading your machine. This is the "other Windows tax".

Yes, this is rather vague. But if you're using D10.4 and it's a VCL DB app, then I'm guessing you're using some kind of TDatabase component to connect to your local DB? If so, it may be as simple as changing your provider interface and connecting to that. If you're using MySQL or SQL Server locally, you can connect to the same DBs remotely. But you could also be asking a more generic question, like what's involved replacing a local DB with a REST-based service API? I mean, you mentioned RadServer, so maybe that's what you're looking for instead? That's a whole nuther can of worms! But if that's what you want, then you need to start shifting how you think about your DB. In Delphi, using DB-aware controls, you're using a traditional client/server model where the app is simply connecting to a DB server and issuing queries and processing the responses. However, those queries tend to be invisible unless you're using explicit SQL queries. Issuing SQL queries for tables and rows is often a lot more overhead than what you want to do if you have a REST-based API -- in that case you need the queries to be more granular. A lot of client/server apps issue things like, "SELECT * FROM ...." and get back thousands and thousands of records, then filter them down. Using a REST-based API, it's best to issue extremely specific queries. Like if you're using a grid to show some data, you'd issue queries that only request to get the number of rows and columns in the grid. If it's a master/detail list, then when the user clicks a row, you'd issue a request to get the data for that specific row. Client/Server stuff often pulls everythign into memory when you open the tables. That is way to inefficient for remote services. If your app IS more of a traditional client/server app, they're you're going to need to re-do the forms and logic that's used to populate the forms, rather than relying on the underlying DB-aware components. There are some provider components that you can replace your existing ones with that add some level of intelligence to the underlying data management without needing a lot of rework on your part, but that would be more of a stop-gap IMHO. Another approach you can use retains the current providers but you'd want to lean more heavily on SQL and stored procs. If you plan it out correctly, the stored procs can be replaced by API calls to a back-end service with endpoints that call the same stored procs. Whatever approach you take, you MUST get away from the traditional client/server practices that simply open the tables and load the entire dataset into local memory.

That's why I prefer to buy stuff that's out-of-warranty and do my own upgrades. It's WAY CHEAPER that way! Most of what we're talking about is purely mechanical work; very little soldering is needed. Besides, I can't recall the last time I had any piece of electronics that failed and I was able to get it fixed under warranty. Seriously. FWIW, I spent most of today at a car dealer. I got a new car on Friday and while going through the paperwork yesterday (Sunday) I found that a few things that I kept telling them I wanted and hearing them say, "Ok, that's what you've got" -- but that ended up being far different than what was in the agreement they had me sign. It all had to do with warranties. If you want to find an industry that has figured out how to leverage people's fear of things breaking down vs. the cost to get it fixed, the automotive industry has perfected this to the max. My experience with electronics is they either fail in the first few hours of use, or they don't. That applies especially to computers and peripherals. I don't know how many dozens of computers are contained in the newest cars, but no matter what they say, most of them are NOT covered under ANY warranties. But they'll tell you they are -- or they'll say they're NOT just to get you to buy an extended warranty plan that you don't need, and when they fail they'll tell you they're NOT covered. I got this new car because my last car had a problem that originated with the previous owner. In spite of all of all the warranties and assurances that I didn't have to worry about ANY problems that might arise with my electrical system (it's an EV) they were all just a big pack of lies. My fast charge port stopped working, and they wanted $6500 to replace the entire wiring harness in it -- even though the warranty I paid $5k for was supposedly designed to cover things like this -- "from stem to stern" they said. "Anything that goes wrong" they said. Just not "pre-existing conditions". Oops. Now they tell me that after 3+ years! I'm the wrong person to talk to about the perceived value of warranties -- to me, they're utterly worthless. And if you ask most people who've had any kind of insurance policy on things that failed and then their "warranty" denied coverage (esp. health care plans!) they'll say the same thing. I put zero faith in warranties. It's easier to get things "fixed" by filing a dispute with your charge card company than to deal with warranties! Thankfully, most companies are easier to manipulate via social media than the useless warranties they offer.

You're welcome to spend your time however you want. Just like some people love to constantly tinker on their own cars, and won't own anything built after 1990. That's perfectsly fine! I'm just as uninterested in futzing with my car as I am with constantly futzing with my OS and computer hardwere. There was a time when I totally LOVED futzing with the OS and hardware. Today I just want it to run. Apple's OS is basically Unix, and I can get at it via the Terminal app any time I want; I do that very rarely any more. It's not about the cost to me, but how little I have to actually think about it and am forced to deal with it. Some people prefer to clean their own homes, and some prefer to have someone clean it for them. Arguments can be made on both sides. But saying you do your own cleaning just because you think "the cost [to have someone else do it] is outrageous", then it's not about the cleaning any more, is it? Neither one is "right" or "better". I just find that Apple's ecosystem takes far less of my time and attention to maintain than Windows. That's priceless to me. YMMV.

I didn't realize this forum caters to "average consmers".