Fr0sT.Brutal

Just as usual, but in Project options > Resource compiler set Code page=65001 and Multi-byte=True. I also set Resource compiler to Windows SDK Resource Compiler because my dialog designer generates RC that Borland's compiler doesn't understand. But AFAICT brcc32 works well too for files included as RCDATA.

TNullable<T> = record public Value: T; IsNull: Boolean; class operator Implicit(const Val: T): TNullable<T>; class operator Explicit(const Val: T): TNullable<T>; end; ?

I just try to use UTF8 everywhere and get rid of all ANSIs completely

Consider them behave like interfaces. A variable keeps reference counter which is increased on assignment and decreased when exiting from scope. There are only a few cases when you need to finalize string/array manually. One of them is to free a valuable amount of memory occupied by a variable ASAP without waiting for subroutine end.

Without BOM every file-handling utility is usable even that which knows nothing about UTF8. I had some shaman dances with XE2 and resource compiler trying to make them handle UTF8 properly and they all disliked BOM. Now 10.1 seems able to handle BOM UTF8 which is good but old habits remain for a while.

IMHO all ANSI uses should be discarded even if they are convenient in some cases. Too much compatibility issues in the world that speaks with letters other than A-Z

IMHO BOM causes more troubles than profit. I just remove it from every file I have

Looks very promising! Will give this tool a try, probably it could replace WinHex for some non-specific use cases. In addition I'd like to have a text viewer (ideally editor) that supports very large files and UTF8. Currently I don't know an app with such abilities

I used to work on PC win Win2k having only 200Mb RAM, it was enough for D7, surfing with Opera, ICQ and some other apps. You are likely comparing release mode with debug mode with full debug info compiled in. F.ex., full test suite of Zeos DB framework with all supported DB drivers being compiled with 10.1 occupies just 6.5M with 5.5M map file and 27M rsm file.

@David Schwartz what do you need nullables for? I only face them when dealing with DB but there are nullable Variants already

Indeed. Very big relief for memory-consuming apps

My point is trivial. If there's no available RAM for expanding a 1G array (that is, 2G) and swap file is limited/disabled as well, this action will fail. Moreover, falling to swap could be unacceptable due to perf degradation. Moremoreover (huh), Windows is very strict in guarding a leftover of free memory and keeps throwing warnings even when 1G left; on 0.5G free space it just kills the main consumer. So doesn't matter whether the system is x64 or x128, available memory is limited.

Please google "swap file size limit" Just a pretty large size for example. This could be 500M or 2G, doesn't matter.

Even virtual memory could be insufficient if an app requests to expand a 1G array

You can setup any number of internal panel configs aka "desktops" and switch between them. Moreover, unpin the panels and they will auto hide.

I once thought on a structure consisting of multiple blocks (arrays) but uniting them with common index. But I never really needed it 😄 Implementation would be quite trivial though.

TList grows its internal array by some factor (1.5 IIRC). So if you use just Add, there are big chances that list will have free space at the end of test

For local storage that won't have any chance to become client/server - SQLite. Otherwise FB embedded with elementary transition to FB C/S

PasDoc? Or IDE built-in HelpInsight that produces nice HTML-powered hints

I took a quick look at IDN format and wonder what drugs its creators did take.

Here are some other links: https://en.wikipedia.org/wiki/IDN_Test_TLDs https://www.w3.org/International/tests/test-incubator/oldtests/test-idn-display-0

https://мособлеирц.рф/ RU Cyrillic domain

Like anything in protection field: one has to estimate how much efforts he is ready to put into protection and how much efforts an attacker will have to make to crack the protection and will it ever worth it. Of course, estimation must include app environment as well. We know nothing about the conditions topicstarter has so it's useless to just guess. Probably xor-ing credentials with a key contained inside the app binary will suffice his needs.

I use this // *************************************************************************** // Static class that helps perform some actions over dynamic arrays // *************************************************************************** TArrHelper<T> = class public class procedure Delete(var Arr: TArray<T>; Index: Integer); class procedure Insert(var Arr: TArray<T>; Index: Integer; const Item: T); class procedure Grow(var Arr: TArray<T>); inline; class procedure Trunc(var Arr: TArray<T>); inline; class procedure Add(var Arr: TArray<T>; const Item: T); overload; inline; class procedure Add(var Arr: TArray<T>; const ArrToAdd: TArray<T>); overload; class function Add(var Arr: TArray<T>): Ptr<T>.P; overload; class function First(const Arr: TArray<T>): T; inline; class function FirstPtr(const Arr: TArray<T>): Ptr<T>.P; inline; class function Last(const Arr: TArray<T>): T; inline; class function LastPtr(const Arr: TArray<T>): Ptr<T>.P; inline; end; TArrHelper<string>.Add(StrArr, 'foo')

IMHO there were no serious breaking changes since Unicode and x64. Moreover, correctly written code won't suffer from these changes at all.