A.M. Hoornweg

Sure. But OP has to re-write tBits anyway because of its size limitations. I'd advise him to make the allocation/deallocation methods virtual to keep all options open.

David, OP can just use whatever allocation method pleases him. The end result is a pointer to a memory block whatever method he uses. It doesn't make one version worse than the other.

In the simplest case a MMF is just a block of bytes, why would that be inappropriate? Just because it's allocated by a different API? We happen to use them extensively for data acquisition, they have that nice little feature that allows us to share the same buffer between processes. One process collecting data, another evaluating it. There are tons of use cases for that.

Good to know!

I have never tried to allocate such enormous amounts of memory using Delphi's heap manager (Fastmm4), I really don't know how it behaves if you try to allocate one huge chunk that is bigger than what the machine has physically. The documentation says "For win32 and Win64, the default FastMM Memory Manager is optimized for applications that allocate large numbers of small- to medium-sized blocks, as is typical for object-oriented applications and applications that process string data. " MapViewOfFile() bypasses the Delphi heap completely and leaves it up to Windows to map a contiguous block of virtual memory.

Isn't this what modern internet browser do, having separate child processes for tabs contained in a common host process ?

For size reasons. Memory mapped files let you - use contiguous arrays bigger than available RAM, mapping file-backed data into virtual 64-bit address space - use simple pointer arithmetics to access individual bytes, it is dead easy to implement SetBit() GetBit() etc - let the operating system's cache algorithm handle the intricacies of swapping pages in and out (LRU/MRU etc) - benefit from the speed and low latency of modern SSD's - have the data on disk, ready to be re-used Speed-wise this is only an option if the operating system can minimize swapping so accessing the elements shouldn't be totally random. If the probability of accessing an element is some kind of bell curve then it might just work. [edit] typo.

That's too bad - otherwise a memory mapped file might do the job.

Hello all, I have the impression that Sysutils.ReleaseExceptionObject is not working as advertized. I see that it's just a dummy procedure. Please find a testcase below. Calling TestCase(True) causes a memory leak whereas TestCase(false) works correctly. The memory leak is gone when I free the exception object manually. procedure AnalyzeException(ReRaise: Boolean); var e: Exception; begin e := Exception(AcquireExceptionObject); // ...Do something with the object ... if ReRaise then raise (e) at ExceptAddr else ReleaseExceptionObject ; //This should work but is a dummy procedure... //FreeAndNil(e); --> this works though end; Procedure TestCase (SwallowException:Boolean); var OneThousand, Zero: integer; d: double; begin Zero := 0; OneThousand := 1000; try d := OneThousand / Zero; except AnalyzeException(SwallowException); end; end;

Remy, this was just a tiny test case to reproduce the memory leak caused by the non-functionality of ReleaseExceptionObject. I was just trying to get a better understanding of the inner workings and lifetime management of exceptions. One such exercise was to detect if an exception was active (hence not passing it as a parameter), then to analyze it (and log the information somewhere) and to conditionally re-raise it based on the information gathered. Ideally I'd like to hook into the system before "except" even fires.

Frankly, I have never used FixedInt/FixedUint and probably never will. The prefix "Fixed" does not convey any information, they might as well have called it TweakedInt. [edit] I see in unit system.pas that integer types Int8, Int16, Int32, int64, uint8, uint16, uint32, uint64 all exist. If we want a fixed 32 bit integer, we can specify that concisely.

Do I have a surprise for you... Longint is platform dependent. Integer is now reliably 32-bit on all 32 and 64 bit platforms but not on ancient 16 bit platforms.

Changing all incorrect pointer/integer casts is infinitely easier because the compiler tells us that the typecast is invalid at compile time. [edit] Having said that, I don't usually use the "tag" property of tcomponent etc anymore. It is much more convenient to use a tDictionary<tObject,tSomethingelse> to figure out if an object is associated with something else.

Persisting data through records, files and streams etc would instantly become incompatible with existing software if the size of a common data type like "integer" changes.

How do other IDE's handle design time support for third-party GUI elements?

One way to achieve isolation would be to load each package into a separate helper process. And yes, it would be a monumental breaking change.

Of course. But I've seen many designtime packages of poor quality. And certain packages that I have installed inn Delphi 11.3 cause the IDE to throw an exception when I close it.

What I would love to see is fully detachable tabs, like in modern browsers.

A 64-bit process can only load 64-bit designtime packages, so it would be a huge breaking change. Having said that, the very fact that designtime packages are loaded into the IDE process itself is also its Achilles heel. Errors in a package can bring down the IDE. It would be nice if that were no longer the case.

Hello all, On 23 june 2023, new security requirements for storing code signing certificates will come into force. I quote the most relevant change: "Effective 1 June 2023, the code signing certificate key pair must be generated and stored in a hardware crypto module that meets or exceeds the requirements of FIPS 140-2 level 2 or Common Criteria EAL 4+. This means the key pair will be generated in a device, where the private key cannot be exported. This will help to minimize the private key compromise." https://securityboulevard.com/2022/05/ca-browser-forum-updates-requirements-for-code-signing-certificate-private-keys/ As far as I can judge, this is highly disruptive. Our company has multiple developers that work remotely much of the time and we need to be able to rollout software updates in a timely fashion. It would very much interfere with our deployment processes if we are no longer allowed to store the keys on our development machines. Your opinions on this?

Is there a "build event" set in any of these projects? That would execute a background program upon a full build.

Is this a one-time problem for OP, and is this the only encoding he will encounter?

Just open the extracted *.txt files in Notepad++ and try out the different encoding options that this program offers until the files display correctly. Then save them as "unicode with bom". tStringlist.loadfromfile will load the files correctly even if they countain foreign characters.

Aren't you running out of environment space for path variables etc ?

I have an idea that might work. There's a service called "the internet archive" where people can archive snapshots of internet sites to prevent them from disappearing . I see that somebody has archived the Delphi 10 Seattle docwiki in 2018: https://web.archive.org/web/20180825012640/https://docwiki.embarcadero.com/RADStudio/Seattle/en/Main_Page In the left side-bar of that page, you'll see links to older Delphi versions going back to version 2010. These links will initially trigger a http error 301, then after a few seconds they redirect to an archived version which is functional! By following these older links, I can reach the following pages: Delphi 2010: https://web.archive.org/web/20190507085636/http://docwiki.embarcadero.com/RADStudio/2010/en/Main_Page XE: https://web.archive.org/web/20210513170545/http://docwiki.embarcadero.com/RADStudio/XE/en/Main_Page XE2: https://web.archive.org/web/20190709193313/http://docwiki.embarcadero.com/RADStudio/XE2/en/Main_Page XE5: https://web.archive.org/web/20180920190325/http://docwiki.embarcadero.com/RADStudio/XE5/en/Main_Page XE6: https://web.archive.org/web/20190709093357/http://docwiki.embarcadero.com/RADStudio/XE6/en/Main_Page XE6: https://web.archive.org/web/20190709093357/http://docwiki.embarcadero.com/RADStudio/XE6/en/Main_Page XE7: https://web.archive.org/web/20190508184802/http://docwiki.embarcadero.com/RADStudio/XE7/en/Main_Page