Brandon Staggs

Maybe. The problem I have is that LSP chokes on code that a build doesn't struggle with. Even with no compiler errors or warnings, LSP crashes, and simple functionality like Ctrl+Click for symbol definition just doesn't work. I can do a clean build with no warnings, then I try to find the symbol declaration for a class, and the IDE goes brain dead. Then sometimes, if I type Ctrl+G instead, it might work, but usually still nothing. Maybe it's the same, but if so, I can only imagine they are ignoring the project settings for what's actually loaded into the IDE. My expectation, unreasonable as it may be, is that if my code compiles when I hit F9, the IDE should not act like a dear in headlights when I try to use it.

But, the language is dead because he doesn't have to call Close. If he removes the call to Close and suddenly everything works the way it was designed to, then the language may come back to life. Sounds dangerous.

I definitely don't "get" that. I think it's very unlikely. You're one of those people who assumes every gap in their knowledge is due to someone else's error. It's a waste of time to try to help people like that learn something.

I think you may be helped by learning how Win32 development works. This is basic stuff, and I don't mean that in a demeaning way. But it is always a bad approach when you come at an existing framework of 30 years and assume that you know better how it should have been designed, when you clearly haven't even read the basic documentation that comes with it. I linked for you the page of the documentation on ShowModal that explains exactly how this works, in case the source code was not clear enough. Your complaints about how ModalResult works ignore the typical use case where a modal result is assigned to buttons on the form. There is no need to call "close" on a modal form in Delphi, and if you think you should call close on it, you likely have a design flaw or a flaw in your understanding of how it is supposed to work. Also, you should think about the ramifications of your method of calling Close and then still being able to do things with the form's instance after that. Why are you so resistant to learning the framework? This is more like someone telling everyone at a work site that they don't know the right way to do their job, when that person hasn't spent any time learning construction and the workers have been doing it for years.

It's not nonsensical at all and it is based on basic Windows event driven design that goes back eons. It's the whole point of using ShowModal to get a modal result, so that result is going to be set for you if you call Close. Just browse the VCL source code to see how it is meant to work, or read the documentation.

I'm speaking in general terms about people who are obsessed with compressing EXEs, as if it is a legitimate solution to create un-pageable files just to avoid proper deployment methods. As to that "unused stuff," Delphi's compiler does exclude a lot of unused code if you don't build your EXEs with shared libraries. Could it be better? Probably, but, when RTTI gets involved, things aren't so straightforward.

Then fix the deployment process instead. Compressing the EXE instead of using a compressed data package for deployment is at best lazy. Even a basic apache web server can be configured to compress your binaries for downloading of the client and you wouldn't have to do anything special to support it.

Never do this. It's pointless, defeats stuff the OS does to make accessing data in the file efficient, triggers more false-positives, and provides no real benefits, unless you are dealing with a severe lack of storage on the deployment target, which should be fixed in other ways. You can zip the file for transmission bandwidth savings.

Where is the confusion? Embarcadero does not support running the Delphi IDE on Windows 7. Will it maybe work? That's up to you to test and decide. They have wisely decided not to spend any effort and time and money testing it on Windows 7, so you are on your own if you want to try it. It's perfectly clear. Also clear is that running the IDE on Windows 7 is not the same as compiling applications with the IDE that target Windows 7, which is what the original post is about. It has nothing to do with IDE support whatsoever. I can even compile MacOS native applications in the IDE while the IDE cannot run on a Mac (without a VM, obviously). The official documentation states clearly that Windows 7 SP1 is a supported target platform for Athens.

If I had to do this, I would write a tiny little console app that replaces wine_get_version with some other deterministic text in a binary file, and add it as a build event. Then I would have to test the theory that the problem is that specific function name, rather than the code around it triggering some heuristics. Writing a console app to do it would at build be less maintenance and headache than rebuilding the RTL to remove it.

This reminds me of "registry cleaners" that do things like automatically remove entries that it determines are paths to files that no longer exist, as if it knows how those would be used if it even did understand how to properly check those things. I actually had this problem with some customers -- they used a snake-oil "registry cleaner" that was removing items my software needed from the registry, causing unexpected behavior. I told the customers that they were using software that was corrupting their system registry under the guise of "cleaning it" and if they needed to use my software, they'd have to stop running bogus "registry cleaners" that indiscriminately removed entries it did not understand. I moved on. I have also dealt with virus scanners and false positives. One of the worst was/is "webroot" that would do more than report false-positives -- it disabled basic Windows functionality for any application it didn't understand, including the Windows clipboard. Hours of diagnosing problems that I should have been able to bill to webroot. In the end, I told the customers, don't use that horribly designed software unless you are willing to whitelist my software. I do understand your problem is competitors whose software doesn't trigger these false-positives. But in the end all you can do is try to make this CrowdStrike's problem by making their customers aware of the issue and complain. After CrowdStrike bricked thousands of PCs across the globe I don't know why anyone would be willing to trust it any more, but I gather most of them are governments or companies fettered by government regulations, and where government bureaucracy exists, sanity and reason flees. Maybe you can write a batch file that obfuscates the string in question post-build. It's not a Delphi bug and should not be treated as a bug in the RTL.

Some of my stuff is in the QA portal (menu fixes I think) and I still have to use it despite the reports being marked "fixed." But most of my workarounds are done on-the-fly with my own inherited form and frame classes and would be too much bother for me to pull out to show anybody. I guess if I were to share a "feel" for how it's going, I'd say it's getting better. I think Embarcadero should force their developers to use their own IDE in a mixed-DPI environment in various configurations and not stop fixing scaling issues until they can do everything seamlessly. Who knows, maybe they already have, and they just aren't exposing the problems I run into.

The irony for me is that I have been so frustrated with the inadequacies of VCL multi-monitor-DPI support than I have long since solved all of the issues myself, and every time Embarcadero tries to improve their support, they break my fixes. So, maybe a bit selfishly, I hope they stop messing with it! Just kidding, this is definitely an area they still need to improve.

With a boot time of up to 7 minutes, and all those other caveats listed, I guess the purpose of this is to make it "easier" to get some data off the VM? Definitely wouldn't want to use that daily in production!

This is the way.

It does work. I can't suggest what is wrong with your configuration, but you can definitely expect it to work -- we have it in production for a few years now with no issues.

False. I'm not disagreeing that the IDE should be 64-bit by now, but there are still major applications that need to build 32-bit targets. But all that means is that we still need 32-bit compilers, it has nothing to do with the bitness of the IDE.

Just like he "publicly stated" that 640k would always be enough memory, right? Actually, there is no evidence of either statement. The 640k thing is directly disputed by Gates and nobody has any direct source for the statement. Internal memos at MS disagree with the latter "quote" ( https://www.cnbc.com/2020/05/26/how-bill-gates-described-the-internet-tidal-wave-in-1995.html ) I have no love for Gates, but people should stop perpetrating those myths, as it is unjust to attribute statements to people with no actual evidence they ever said something. As to the other stuff, MS-DOS and Windows did not need to focus on high-powered shell programmability. It seems obvious to me that their target audience was not Unix gurus. Be that as it may, that is all ancient history and you can use full *nix shells on Windows now if you want to. What I don't really understand is why anyone who dislikes Windows so much would willingly become a Delphi developer. Delphi started as a Windows development tool and that is still its strength.

That is simply incorrect. My ARM64 (Snapdragon) Windows laptop runs 32-bit x86 code just fine. Delphi is still a 32-bit IDE. They have 64-bit compilers now if you want to pay for an Enterprise license but the rest of us are slumming it in 32-bits and that's not a problem for ARM-based Windows.

Your VM does not have the correct operating system installed on it for that to work. It's the responsibility of the installed Windows OS on the VM to translate x86/x64 code to ARM instructions. Your version of Windows won't do that.

I use Help & Manual. For deployed help file I use their e-reader format which is basically an executable wrapper around the Trident web control that exposes the help html. I also deploy PDFs and web-based help with it. I think it checks all the boxes on your list. Check it out. I think Microsoft really dropped the ball on integrated help. It used to be so easy and straightforward just using CHM.

Not just you. Regardless of the variable state at the end of the for loop, a while or repeat loop would be far more clear IMO.

A clipboard history is a convenient way to see lots of passwords in plaintext. Who wouldn't love that.

No, but because Windows machines cost so much less for substantially the same thing. The fact that I build my own machines is not really the point; I don't believe most Windows machines are dead in 3-5 years, that's ridiculous. Nearly everyone I work with is using Windows machines at least that old. If you prefer MacOS that's certainly fine, nobody can criticize you for that. My personal experience as someone actively doing development for Macs is that it is easily the worst system to target for development and gets worse with every major update. Although it may be a lot of Unix under the hood, Apple is locking it down more and more with every update. Apple behaves as if it owns not only its hardware but their users. The Apple Tax is not just overpaying for hardware, but losing personal computer sovereignty with every update. It's bad enough on Windows, it's many times worse on Mac.

One of the supposed benefits to an EV cert is that it comes with instant SmartScreen rep. My own experience was than the first time I signed with my EV cert nobody saw any SmartScreen warnings, which was never the case when I first used cheaper certs in the past. Do different browsers use their own screening systems? Windows + Edge should be consistent, but maybe other browsers don't care what SmartScreen thinks?