Brandon Staggs

Well, no, not the only option. You could configure Delphi to use a different location. Personally, I don't want source code in "Documents."

I am fortunate to have learned Win32 API before anyone was doing decent abstractions of it. (I tried OWL after that and it was terrible.) There is nothing weird about a windows message loop. You get a message and decide what to do with it. And as long as you can understand the difference between sending a message and posting a message, it's easy. But, you have to read documentation, which appears to be a very sore point for some people. The VCL is just a very good layer on top of this that allows for direct object oriented design. I don't buy your claim that 90% of Delphi programmers don't know about windows message loops. To be certain, a good Delphi developer will have to learn it at some point, unless they are not involved with UI development.

You keep demonstrating for us that you do not even understand the API. Your original question would have been answered by just looking at the documentation for ShowModal, or by examining the source code to see how the modal loop is implemented. You wouldn't bother to do that, and you feel qualified to make pronouncements on the overall design quality. Maybe let it go.

Interesting. I know this was a concern in the early days of SSD drives, but I've never replaced an SSD drive due to it "running out of writes." Obviously your RAM is going to be your fastest storage, but just doing a full build and letting your OS cache do its work ought to be enough. Have you actually tested the speed of both methods? I have long since quit trying to do a better job than my OS cache does on its own, especially in these days of NVME solid state drives...

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.