A.M. Hoornweg

I just tried if succ() and pred() work correctly with eplicit ordinal values if there are gaps between the numbers. They don't. Too bad, it would have been totally cool.

I very often have the case that I need to parse records in files and data streams where some integer field identifies the type of content that follows. Some of them were generated by software of my own, some by others. So for that, it is eminently useful: Instead of declaring tons of constants with prefixes to clarify the context they apply to, one just declares an enum which locks the constants into a common namespace. For example, look at what Borland did a long time ago in units System.pas and Variants.pas. It's full of prefixed constants like VarEmpty, VarNull, VarInteger .... where a single enum type tVariantType= (Empty=0, Null=1, ...) would have been much prettier. This example comes to mind because I need to decode and encode variants quite often.

Thank you! So if I understand correctly, it's just an enum with explicitly defined integer values instead of the default 0...X sequence that the compiler would otherwise generate. Too bad, my first impression was that the constants had an implicit associated data type (integer) and that I could use it for stuff like Type tnumerals=( one='uno', two='due') but that clearly isn't the case. Too bad. But still, I think the syntax is very handy for some of my purposes.

I believe the old Turbo Pascal "Real" type is now called Real48 and exists only for compatibility purposes (i.e. if you need to read or write files with data in that format). It is much slower than either Double or Single because it's not a native FPU format.

BTW, the "classical" method to detect or prohibit more than one instance of an application is to use a mutex.

Hello all, one of my (heavily multithreaded) Windows services crashed today with an access violation and Windows was decent enough to write the "fault offset" in the event log. I have a detailed linker MAP file of the application. Does anyone know a tool that will parse the MAP file to help me find the approximate error location in the source?

Another advantage of VMs is that you're able to do remote debugging and test your software on a different version of Windows than the one you're developing under. I can easily compile a Delphi application on my Windows 10 development VM, deploy it to a network share on my Windows 7 VM and debug it on that operating system. Piece of cake. The same goes for Linux. It's even possible to run MacOS under VMWare, though Apple doesn't allow it unless the underlying host is an Apple machine. The latest VMWare version can co-exist with Hyper-V on the same host machine by the way.

Some advantages of using virtualization: Backing up a vm is as easy as copying a file. If you break something in a vm, it doesn't affect the host machine. If you decide to replace your host machine with a new one, you're up and running again within an hour. I've configured my VM to use separate virtual disk files for C: and D: and I keep my projects on D:. Whenever I update Delphi, I archive the virtual C: drive first. This makes it dead easy to fire up an older Delphi version whenever I need it.

I'm using VMWare Workstation Professional since many years and totally love it. I have 2 external screens attached to my notebook (plus the internal one, which makes three) and I can very flexibly set VMWare to use any combination of screens and resolutions. This makes it very easy to test DPI-Aware applications. Another big advantage for my specific line of work is that VMWare lets me configure virtual COM Ports (which communicate with each other through named pipes) so I can test serial communication protocols even though my notebook has no "real" RS232 ports. VMWare also supports virtual networks so I can define "private" networks between virtual machines that are isolated from others. There are tons of ready-made VM's to download from the internet with appliances like routers etc. When configured right, a VM in VMware is not noticeably slower than the host machine.

Hello all, I'm trying to debug a multithreaded application that contains, among other things, the Intraweb framework. I have the Parnassus Parallel debugger installed in my Delphi 10.4.2. Sydney IDE. My problem: whenever I try to set a breakpoint in a multithreaded piece of code of my own, the Delphi debugger immediately complains that it can't find the location of some Intraweb source file. Of course it doesn't, because Intraweb doesn't come with source, so why is it asking? The big problem is that this message is impossible to get rid of. It just keeps coming again and again and I never even get the change to assign the correct thread affinity to my breakpoint. So... How the heck do I tell the Delphi debugger to not keep asking where the Intraweb sources are located?

Unfortunately not, when I do that, the next dialog appears immediately for the next Intraweb unit (there are several hundred). Debugging is just not do-able as long as this dialog keeps popping up.

This is very interesting, I'll certainly look into this. I'm also currently evaluating Eurekalog.

Thanks to everybody who responded in this thread. I think I'll acquire Eurekalog or MadExcept for this project. Is any of these two particularly suited for multithreading NT services?

My service is heavily multi-threaded (see attachment) , has hundreds of threads running which pull data from a multitude of oil rigs. The communication threads use Remobjects Remoting which is also multithreaded. The service itself has a builtin http management console that is based on Intraweb, which is also a multithreaded framework. There is sooo much multithreading going on, can a tool like Eurekalog produce a stack frame if one of these threads produces an AV?

I think it does. The two searches are not disjoint, so calling StringReplace (shortest word first) would replace "Hut" by "House" and the name "Hutt" would not exist anymore in the second search pass due to this insertion. An approach that starts by scanning the original string for all search terms would reveal two "hits" at the first letter H and then things get interesting, because it would have to decide which replacement is "better". So it needs some rules to make that decision. One rule could be to replace the longest search term.

What I mean is, if you call Embarcadero's stringReplace routine multiple times, then each subsequent replace sees the insertions made by the previous call. But if you write a MultiStringReplace routine that first analyzes the string and determines everything that is to be replaced, that is not the case. It sees only the original string and not the intermediate insertions. The end result may be different.

I am a bit puzzled here. How do you want to guarantee a consistent outcome? The first "search & replace" will change the string. It will remove characters and insert new ones. Which may get captured by the next search. Suppose you have a string like "Jabba the Hutt lived in a Hut" and you want to replace "Hutt" by "Alien" and "Hut" by "House". How do you decide which replacement to do first?

Do you mean units? Units only came in Turbo Pascal 4 AFAIK.

Hello all, in my quest to port a very large project -containing dozens of COM DLL's- from Delphi XE to Sydney, the main obstacle for me was the exploding executable size. Each and every DLL in my project group had grown between 1-4 megabytes and that really added up painfully. Most of that growth, of course, is due to the new extended RTTI (which I do not use). The project was already huge before, and a doubling or tripling in size would cause deployment problems (the software is used on oil wells on remote locations and bandwidth is often costly and slow). Trying to strip off some MB's wherever I could, I started studying the MAP files to make sure no unnecessary stuff was linked in. I noticed that all of my non-visual COM DLL's nevertheless pull in huge chunks of the visual VCL, including units VCL.Forms, VCL.Themes, VCL.Imagelist etc. I am absolutely sure that I don't use these routines anywhere and still they make up over 60% of the executable's code! The underlying cause is that all of the xxxx_TLB.PAS files, which the IDE auto-generates, use a unit called OleServer which has an initialization section. No code in the unit itself is called, but the initialization section manages to pull in most of the VCL for whatever reason. As a test, I made a dummy unit "oleserver.pas" and referenced it as the first file in my COM DLL applications. The project compiled fine, and this change alone instantly reduced executable size with a whopping 1 MB. And the best thing, the project still worked as expected. So it seems to me that this whole OleServer unit is an unnecessary thing in my projects. Another thing. When I link my projects against a "stripped" version of the RTL/VCL (recompiled without extended RTTI), the size difference becomes astronomic. My DLL's have now typically lost 80% of their size, going from 2MB+ to only 400kb. With these executable size reductions I am finally able to port this project to Delphi Sydney. I am in the process of writing a tool to automate the "rtti stripping" of the RTL/VCL which I plan to release as open source. For example, projects like "inno setup" might benefit from it.

I'll do that (create the QP), thank you. (edit) https://quality.embarcadero.com/browse/RSP-33241

To each his own. For single-exe projects it is a non-issue and I wouldn't bother either if my project consisted of only a handful of modules.

I haven't ported the project group from XE to Sydney yet, for now the directive is needed for XE where it applies to all units that the compiler rebuilds. I just wish Embarcadero had optimized RTTI for size from the very beginning and given us the choice wether to use it at all. Having RTTI in your code offers possible attack vectors for reverse engineering etc.

I use a RTTI-stripped version of the XE libraries since ages, because when I migrated from Delphi 2009 to XE my executable sizes also grew a lot. That RTTI stripping is much easier to achieve with XE because the {$RTTI....} directive was still a global option then, so you don't need to patch any source files. Stripping RTTI is now an integral part in my Finalbuilder build scripts. Edit: I have attached an image with the executable sizes. All executables were compiled in "release mode" without any debugging info. All executables were compiled with {$WEAKLINKRTTI ON} and {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in the DPR. (1) Compiled with XE10.4.2 Sydney. (2) As (1), replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. (3) As (2), using a RTTI-Stripped RTL/VCL. (4) Compiled with Delphi XE, replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. (5) As (4), using a RTTI-Stripped RTL/VCL.

The purpose of a spinlock is to obtain the lock as quickly as possible. On a single core system, doLock should yield on contention because the thread that owns the lock is waiting to be resumed. On multi-core systems it can keep spinning. In the initialization of the unit, call GetProcessAffinityMask() and count the bits in the integer to obtain the number of cores available to the program.

One problem I see is that on a single-core CPU, doLock will burn up all remaining CPU time of the time slice on contention.