A.M. Hoornweg

VMWare workstation will let you do this. Just add two virtual serial ports to the VM, in the field "connection" specify "named pipe". Both COM ports must use the same name for the named pipe (just call it "serialportpipe") and one port must be configured to be "server", the other must be "client". That way, the two COM ports are crosswired. Now you can start 2 applications, connect them up to the two COM ports and let them talk to each other.

I don't know if Zlib writes a checksum or not, maybe you should append it yourself at the end of the compressed stream. Then first verify that checksum before trying to decompress it.

I do it slightly differently: - The main process launches a child process for the work. - The child process creates a mutex. The service application knows if the child process is still running by periodically checking the mutex. - The child process has a separate thread called tWatchdogThread. - The main thread must call "tWatchdogThread.Notify" regularly to prove it's still alive. - If that sign of life stays out for more than 10 seconds, the watchdog assumes the main thread has crashed and ends the process using TerminateProcess(). This mechanism has proved to be extremely reliable, I use it often.

Hello all, when Delphi didn't know about unicode yet people would often stuff binary data into strings because strings were soooo practical and easy to manipulate. Yes that is and was bad practice and highly frowned upon, but as we all know it was done anyway and people got away with it because Delphi didn't care about code pages at the time so it just worked. It was even done in professional libraries. Code like that is very hard to port to newer Delphi versions which are unicode-enabled and codepage-aware and when you attempt a conversion, subtle errors may happen where you least expect it. If you still have precious old code libraries that do such things and which would be too costly or too complex to rewrite, you may consider trying this workaround as a quick & dirty fix: Type Binarystring= type Ansistring (437); The nice thing about code page 437 is that all 256 possible ansichar values map to valid unicode code points so you can safely assign these strings to Unicodestrings and back again without data loss and Delphi's built-in string functions won't break the binary data contained in these strings. So you just may me able to salvage some legacy code by declaring this new type and then replacing all "string" declarations in the code with "binarystring" and all (p)Char with (p)Ansichar. And yes, it's still bad practice... (The idea is originally from Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20200831-00/?p=104142 )

For my own source code I switched to tBytes too, long ago. But I have several legacy third party libraries of companies that no longer exist and that are still very nice when used with Delphi 2007. So when I came across Raymond Chen's blog I had the idea to salvage these libraries without mutilating the existing source code too much. And I stated loudly and clearly that this is just a quick & dirty fix to get it done. As Remy Lebeau stated, assigning RawByteString <-> String may still do a codepage conversion. Ansistring(437) and Ansistring (28591) are safe.

The VCL was strictly Ansi. I needed visual unicode compatibility in the early noughties and was forced to switch to a third-party VCL (first TNT, then LMD Elpack).

Fair point. Moreover, the only tool in Delphi that could perform operations like copy/append/delete/insert/search on variable length data out of the box was "string". If all you have is a hammer, every problem looks like a nail. I remember that Windows NT (from the mid-1990s) was already unicode-enabled but Delphi didn't support that until version 2009. So all that time, a char and a byte were basically synonymous in Delphi.

I do, all the time. But this is about salvaging older (possibly third party) ansi code without a rewrite.

The documentation says that "Rawbytestring should only be used as a const or value type parameter or a return type from a function. It should never be passed by reference (passed by var), and should never be instantiated as a variable." I read that as "you may not declare variables of type "RawByteString" and do stuff with them". But if I define a Type Ansistring(437) and put binary data into it, the data is associated with a valid code page. A conversion to unicodestring will convert characters [#128..#255] to some different unicode code points, which is uninteresting, because a back-conversion to ansi codepage 437 will produce the original binary data again. So it is safe to use all normal unicode string functions as long as we remember to assign the final results back to an Ansistring(437).

Voted!

Hello all, could it be that function UCS4StringToWideString misses the final character during the conversion? VAR s:UCS4String; W:String; begin s:=[220,98,101,114,109,228,223,105,103]; w:=UCS4StringToWideString(s); showmessage(w); end;

Most programmers ignore that UTF-16 is a variable-length encoding and treat it like UCS-2, falsely assuming that one widechar corresponds to one codepoint. While most of us probably don't handle exotic languages, this is the 21st century and sooner or later you'll stumble upon strings that contain Emoticons which just won't fit in one widechar ( https://en.wikipedia.org/wiki/Emoticons_(Unicode_block) . Delphi could use some better support for that, like iterators etc. Something like this: Function ReverseString (S:String):String; VAR c:UCS4Char; Begin Result:=''; FOR c in s do result:=c + result; End; And if you think this is far fetched, just look how elegantly Freepascal solves this, https://wiki.freepascal.org/for-in_loop#Traversing_UTF-8_strings .

I've just discovered that ExtractFileDrive misses a corner case on Windows and posted a QC about it. https://quality.embarcadero.com/browse/RSP-31109 I was experimenting with very long file and path names (see https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation) and stumbled upon a file name syntax which I hadn't seen before. It turned out that Delphi didn't know about it either. The syntax is \\?\UNC\server\share which is just another way of writing \\server\share. Delphi's ExtractFileDrive returns "\\?\UNC" on such a path which is meaningless.

OK, I'll post a QC then. Edit: https://quality.embarcadero.com/browse/RSP-31114

The word "drive" is a bit unlucky. What ExtractFileDrive() really does is to return the root of a volume, which can be either a drive letter or a file share. ExtractFileDrive ('\\server\share\folder\filename.ext") returns "\\server\share", which is perfectly OK. I can use the result as the root path for a folder structure without problems. ExtractFileDrive ('\\?\C:\folder\filename.ext") returns "\\?\C:" which is also perfectly OK. This result, too, can be used as the root path for a folder structure without problems. The only corner case that isn't handled correctly is "\\?\UNC\" which is needed for long network paths. I think it wouldn't hurt anyone to support that syntax as well.

I respectfully disagree. The prefix "\\?\" is a well-known method to tell Windows that a program is able to parse file names longer than MAX_PATH. It seems that the prefix \\?\UNC\ extends this ability to network paths. Otherwise I wouldn't bother with them. But in this specific case I needed to test if two paths referred to the same volume so I used ExtractFileDrive, which failed on this syntax.

Hello all, I'm experimenting with high-dpi in Delphi Rio 10.3.3 and I'd like to know what the best way is to make a tMainmenu having items with images. The problem being that a 16x16 imagelist is unusably small on a high-dpi notebook screen. The application still needs to support older Windows versions, so I can't use any stuff that's only available on Windows 10. Any ideas?

This doesn't work for overloaded functions. For example, function "strlen" (sysutils.pas) is ansi-only in Delphi 2007. Then, in Delphi 2009 an overload was created for unicode so there were two versions. In XE4 the ansi version was duplicated in unit Ansistrings so from then on there were three. And then in Delphi 10.4 Sydney the original ansi version in sysutils.pas got "deprecated". But I like your *.inc files, they look solid and they are a good reference as well. However I see that 10.4 Sydney hasn't been implemented yet?

I maintain some libraries that are used in our company and that have to be compatible with a range of compilers (2007 .. current). Some of our programs are used on embedded devices with older operating systems hence the need for D2007. We want our products to compile without hints or warnings. Totally apart from the usual string problems (unicode/ansi and codepages), there's the issue of Embarcadero deciding to move RTL functions from one unit to another, of functions being declared "deprecated" and of functions suddenly being declared "inline". So in order to suppress such warnings, I need to know when Embarcadero decided to pull off such changes.

This is the most complete list I could find: https://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre

I constantly have to look up in which Delphi version a certain feature was introduced. And not just me, literally *every* component manufacturer maintains his own *.INC file with $defines to keep track of these things. Those *.INC files have to be maintained with every new delphi version and they're a royal P.I.T.A. Wouldn't it be great if Embarcadero (or anyone else, really) published a git repository with a freely usable *.INC file, with $defines for all feature changes in every Delphi version? That way everybody could speak a common "language" for detecting features instead of re-inventing the wheel.

As a workaround, you could disable the structure highlighting stuff in Delphi 10.4 and instead install CNPACK, which also offers that feature. This image shows what it looks like (in Delphi XE).

It is one of the reasons why I'm not a friend of "skinning". But my changed Windows settings tackle the root cause which is unnecessary re-drawing of UI elements for the sake of smoothness and animations. I don't need any of that. Responsiveness is much more important.

@Mike Torrettinni do you have your virtual machine on a SSD? You should, it makes a dramatic difference. One more thing about VMWare and GPU acceleration. My notebook happens to have more than one GPU. It has an Intel adapter but also a faster additional NVIDIA GPU. A nice but little known feature of VMWare is that it lets you select which GPU to use, but tweaking such advanced settings involves manually editing the virtual machine's *.vmx file. These changes make the virtual machine less "portable" between host machines since different host machines may have different GPU's. mks.dx11.vendorID = "0x10de" (This selects the NVidia GPU. "0x8086" selects Intel, "0x1002" selects AMD) mks.enableDX11Renderer = "TRUE" (This enables DirectX11/OpenGL acceleration. It is the default setting). Some DirectX drivers have been "blacklisted" by VMWare for some reason; in that case no DirectX/OpenGL acceleration is available at all inside VM's. This might be an explanation for slow behavior. But luckily you can override even that setting in the *.vmx file: mks.gl.allowBlacklistedDrivers = TRUE One more thing about VMWare Workstation in general. Normally if one uses VMWare one would leave Hyper-V disabled on Windows and let VMWare handle all the virtualization. But the latest VMWare version 15.5.X can also run "on top of" Hyper-V. I don't know if there's a speed penalty involved with that. There might be.

In my case, every project is generally in its own repository. Some projects, however, consist of many sub-projects (for example, a main project and a bunch of plugins/dlls and maybe a configuration program); in such a case, I keep these in one repository because they count as one big project. Almost all my projects use a bunch of libraries, some of which are commercial ones. And of course I keep each of these libraries is in a repository of its own. Source code versioning systems like Subversion and Git allow you to reference "external" repositories for libraries (in Git they are called Submodules). So each of my project repositories has a subfolder "externals" where it automatically downloads the libraries which it needs.