if it is a console program and it was started any other way (from the Windows Explorer, from the Delphi IDE with or without debugger, from another non-console program), then, before the console window can close, it will display:
Ever since I started using Delphi more than 2 decades ago, I wondered about the design of the TStream classes, especially as “stream16.zip” by Duncan Murdoch from the DOS Turbo Pascal era (which I copied in the below gist) showed how to perform composition using streams.
Even though by now there is TStreamReader/TStreamWriter allowing some level of composition, it always bugged me that large parts of the resource handling and component (de)serialisation is in it (centred around ReadComponentRes/WriteComponentRes in stead of fully being in TFiler/TReader/TWriter or even further decomposed), that you cannot interrogate capabilities (like supporting seeking, length, directionality and such) and that a lot of overloads (for instance Read/ReadBuffer/ReadBufferData/Write/WriteBuffer/WriteBufferData) are still based on signed or 32-bit types (though it has improved back in the early days they were even signed 16-bit types).
Even TZCompressionStream/TZDecompressionStream (though relatively new) aren’t doing composition really well (by not abstracting the compression/decompression from the write-only/read-only behaviour).
Now that all key players from the early TStream design day and age have left the core Delphi R&D team, maybe one of them can step in and explain why.
The trick comes down to enabling the PreferExternalManifest registry setting and then create a manual manifest for the application that forces the application to use “bitmap scaling” by basically telling it does not support “XP style DPI scaling”.
You name manifest file named after the exe and stored it in the same directory as the exe.
After that, you also have to rename the exe to a temporary name and then back in order to refresh the cache.
A quote from the trick:
In Windows Vista, you had two possible ways of scaling applications: with the first one (the default) applications were instructed to scale their objects using the scaling factor imposed by the operating system. The results, depending on the quality of the application and the Windows version, could vary a lot. Some scaled correctly, some other look very similar to what we are seeing in SSMS, with some weird-looking GUIs. In Vista, this option was called “XP style DPI scaling”.
The second option, which you could activate by unchecking the “XP style” checkbox, involved drawing the graphical components of the GUI to an off-screen buffer and then drawing them back to the display, scaling the whole thing up to the screen resolution. This option is called “bitmap scaling” and the result is a perfectly laid out GUI.
In order to enable this option in Windows 10, you need to merge this key to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Then, the application has to be decorated with a manifest file that instructs Windows to disable DPI scaling and enable bitmap scaling, by declaring the application as DPI unaware. The manifest file has to be saved in the same folder as the executable (ssms.exe) and its name must be ssms.exe.manifest. In this case, for SSMS 2014, the file path is “C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe.manifest”.
Paste this text inside the manifest file and save it in UTF8 encoding:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This “Vista style” bitmap scaling is very similar to what Apple is doing on his Retina displays, except that Apple uses a different font rendering algorithm that looks better when scaled up. If you use this technique in Windows, ClearType rendering is performed on the off-screen buffer before upscaling, so the final result might look a bit blurry.The amount of blurriness you will see depends on the scale factor you set in the control panel or in the settings app in Windows 10. Needless to say that exact pixel scaling looks better, so prefer 200% over 225% or 250% scale factors, because there is no such thing as “half pixel”.
Of course there are also [WayBack] DelphiFeeds (which seems unmaintained, but a truckload of people have it in their RSS reader) and [WayBack] BeginEnd.net (slowly but steadily growing).
I wish there was an RSS reader that could filter out duplicate posts so I can just follow all three without reading duplicates.
Not sure what the cause and effect are, but various people are having issues running Delphi versions on Windows 10 Creators update. Debugging takes an exceptional long time to load the debuggee.
According to Marco Cantu, it is not limited to Delphi:
“It looks like a change in libraries code relocation, and it affects all debuggers — not just ours.”
A roll-back does make them work again but … there is only a very limited time frame to roll back from Windows 10 Creators update (think days, not weeks).
So for now: if you use Delphi do not install the Windows 10 Creators update unless you:
Look into the initialization block of FMX.Dialogs. The call to ActivateClassGroup(TFmxObject); turns off all the TRegGroups that don’t contain at least one type that inherits from TFmxObject which also happens to be the group that you register your form class to. GetClass then ignores such groups.
I don’t have the slightest idea what the intention behind all that code is but it certainly is one of the reasons why you cannot mix FMX and VCL officially.
In response to:
I have an VCL application. I need to register some form classes at run time. This is done in the form’s unit implementation section :
Initialization
If GetClass(‘TfmConnectiondialog’) = Nil Then
Classes.RegisterClass(TfmConnectiondialog);
Suddenly my class wasn’t registered anymore. GetClass(‘TfmConnectiondialog’) was always nil and Classes.RegisterClass had no effects.
After some long search, I’ve found that I’ve inadvertently added an FMX.Forms in one of my unit. This was the culprit. Replacing FMX.Forms with VCL.Forms solved my problem.
Behaviour is really strange, why Classes.RegisterClass didn’t throw any exception ? Is this a “Bug” or is this “as expected” ?
As cgrc.exe could build the .rc file [source in Russian; WayBack], I reproduced it from the console with an Empty.rc file that has no content. That way I could rule out file content: now it had to be command-line arguments which is a different cause than any of the search results I found before.
My project was based on one of the DUnitX test projects. It ran in Delphi XE8, but the Delphi version doesn’t matter as BRCC32 hasn’t been updated since 1999.
Further below are the failure/success examples; this went wrong:
DUnitX uses the DUNITX-DEBUG define to enable debugging of DUnitX itself in DUnitX.inc which also supports the DUNITXDEBUG define in the same area.
Delphi will translate a .RC file in a project into a BRCC32.exe call adding the project conditional defines and search paths
BRCC32.exe doesn’t like hyphens in conditional defines throwing a non-descriptive error Fatal error Illegal macro definition in command line or defines page.
So either removing DUNITX-DEBUG or changing it into DUNITXDEBUG solves the problem. Hence my pull-request.
The Wiert Corner - irregular stream of stuff 