Der schöne Günther

That's what I do as well: I just change the systems keyboard layout so the TTouchkeyboard will follow. When not longer needed, you can also unload the English keyboard layout again so it will not show up ion the users language list ([Win] + [Space]). I am doing a kiosk application however. I also wouldn't be comfortable with doing that in a regular application...

In that case, I would probably resort to writing them to a string "by hand" and flushing the string to disk every few megabytes (or using a TBufferedFileStream).

No, it doesn't. It's just a DLL with no further dependencies. Internally, it might leverage something from the JCL, but it's just a binary 🤷‍♂️

That does the job of acquiring the stacktrace, yes. This often goes hand in hand with the question "How do I act whenever an exception happens so I can, for example, log them". To intercept both operating system and Delphi exceptions, it should be enough to point System.ExceptObjProc and System.RaiseExceptObjProc to an own handler.

That's is what we usually do. Initially, we had the good old JCL. It was the only thing we used it for. Later, we figured out we don't really need it at all, it was sufficient to hook into a System.ExceptObjProc (and one or two other procedure variables) to point to our own exception handler. There, you can easily acquire the stack trace with with FastMM_Fulldebugmode.dll. It exports three handy methods to acquire the "frame based" and "raw" stack trace and, of course, to just get a string for the textual representation. Internally, the binary also uses the JCL, but can be recompiled to use Eureka or madExcept. At least, it saves us from installing the JCL at all, and the DLL is just a few kilobytes. Pretty happy with that, since we also have full control of how the stack trace is formatted and what happens with it, once an exception gets raised...

Consider the following scenario: A full-screen Win32 application (Delphi, mostly) which must run 24 / 7. The computers are located inside a factory. They generally have internet access, but might have pesky company firewalls. Since the computers need to run 24/7, they never get Windows updates. We still have to support the earliest versions of Windows 7, for a few years to come Requirement: When the user actively requests it, gather some data, zip it, and "send it to our technical support department" This is what I call "phone home": I want the running application to send data (a single ZIP file) to our companies support department. There are a few thousand installations worldwide. They are not authenticated against anything, they're running local Windows accounts. So far, this has been done by using Delphi's Indy library to send an email to an old Exchange server of ours, by SMTP. I had taken the email approach because it will end up directly in the inbox of our support department. The downside of this method is that More and more companies are blocking outgoing SMTP traffic. They probably suspect spam. Some security solutions will even fake our servers reply and indicate success although the email never got sent. Our company wants to shut down our old in-house email server I am now looking for an alternative approach. Here is what I can think of: (1) Set up an FTP server, upload files there Advantages: The FTP server is under our control and will be running as long as we want to Our application can properly report upload progress Disadvantages: No experience with how likely this will be blocked by company firewalls Our service department will still have to be notified that something arrived at all. Either by email, or other means. (2) Post stuff to our SharePoint / Microsoft Teams Advantages: Posting text messages from the "outside world" (meaning: no authentication) to a channel in the support team works like a charm Disadvantages: When Microsoft breaks this API, it won't be working anymore I have found absolutely no way of uploading files to our SharePoint server anonymously. APIs like "Microsoft Graph" seem to be centered around authenticated ActiveDirectory/Azure users, and do not allow public access (3) Setup an own web server and POST data to this Advantages: It can probably be automated so that after successfully POSTing a file, an email or some other kind of notification gets sent to our department Disadvantages: No developer in our company knows anything about how to properly do web stuff (PHP?). (4) Setup a new, simple email server and continue as always Advantages: Existing software will continue to work Disadvantages: Lots of companies will block outgoing SMTP traffic and it just won't work (5) Drop "phone home" entirely Query the operator to download the ZIP file to a USB drive, go elsewhere, and send it to us Advantages: None Disadvantages: Too much hassle so many operators simply won't bother In order to access the USB port, operator will have to unlock and open an electrical cabinet which is, in some countries, limited to special personnel. What are your thoughts? Did I miss an obvious option? Thanks for taking the time to read.

Thank you all very much for the replies so far 👍 I hope I can convince the management to host a native server here inside the company and make it accessible with a constantly open port. Just like the Exchange server they want to shut down. With a server in house, we could have full control about what is going on and could basically run any application there. I didn't really think about that. I had my mind on that external server that hosts our web page. I think it can only do PHP.

I didn't even know, altough it's properly documented: System.SysUtils.Format - RAD Studio API Documentation (embarcadero.com) I still find ('The result is %8.2f', [myFloat]) more readable than ('The result is *.*f', [8, 2, myFloat])

I think this used to be different. But judging from Lars' screenshot, it really looks like this is the current implementation:

That is because the IDE uses an embedded Internet explorer control to display web content from Embarcadero.com. Whenever there's something from with scripts or certificates on their end, error messages will be displayed on your computer.

We just set System.ExceptObjProc (and one or two others, I think) to point to our own exception handler and acquire a textual representation of the callstack with FastMM_Fulldebugmode.dll. Never saw the need for additional tools like Eurekalog or MadExcept. As far as I recall, precompiled FastMM dll internally uses JCL for looking up the .map file, but can be recompiled to use Eureka or MadExcept as well.

Awww, yuss! 🥳

Here you go: Has anyone tried running Delphi on Windows ARM? - Delphi IDE and APIs - Delphi-PRAXiS [en] (delphipraxis.net) Can't blame you for not finding it, the forums search returns nothing on entering terms like "M1" or "ARM"

You are right that it can be used for commercial products: But the page you used correctly says: So yes, I may still charge money for the software I sell ("commercial"), but I will have to make all of my source code (not just yours) available to everybody. See here (in French): Licence publique générale GNU — Wikipédia (wikipedia.org)

It's the "license" page straight from his Github repo, I posted the link above. An even more colourful overview is provided by tldrlegal.com: GNU General Public License v3 (GPL-3) Explained in Plain English - TLDRLegal

Looks really nice. But are you sure about the GPL license?

This is also one of the things that bugs me most. There must be a way to speed this up. You just change one line of code and then have to stare at your screen for 15 seconds because everything must be linked again.

Yes, I had seen that, and it looks incredibly capable and powerful. If I had a use case, I would certainly try it out. I was just trying to say that, unless you already had completely platform and UI-independent Pascal code (and a use case for it), I don't really see what you would use it for. A bit like a solution, still looking for a problem.

Can you confirm it cannot only build projects but also debug them?

A lot of Delphi code (at least the one I deal with) is often plagued by VCL or Windows platform dependencies. Not going to run in a browser anyway.

Why not stick with a native dll and use that from .net? Platform Invoke (P/Invoke) | Microsoft Docs

I assume "I get an OS error" means "CreateProcess(..) returns false and GetLastError() will then return ERROR_ELEVATION_REQUIRED". Is that correct? If so, it appears that CreateProcess(..) cannot be used to automatically handle the UAC prompt and everything beyond that for you. Use ShellExecute(..) instead. (Source: Using the ElevateCreateProcess Fix | Microsoft Docs)

I might be missing something, but if you need to do that, why are you omitting the override; behind your declaration?

I believe you will still have to get familiar with Windows Desktops: Desktops - Win32 apps | Microsoft Docs

The login screen is an entirely different "desktop" (not to be confused with "Virtual desktops" which were introduced with Windows 10), much like an elevation prompt ("user account control"). An application that runs without administrative privileges cannot access that "secure desktop" the login screen is running on. You can, for example, also see this with other solutions like TeamViewer or AnyDesk: When they don't have administrative privileges and the user locks his account, they can't do anything.