MRC Change List on 3/3/2025:

See merge request !517

Just write to whatever dir, maybe that'll work.

I expect this to crash on Windows...

is_crypt_initialized() does not depend on the once value.

DDLightbarMenu: AdditionalQuitKeys now are honored in traditional (non-lightbar) mode, and there's a new menu property, nonANSIPromptText, which allows customization of the prompt text when in traditional/non-ANSI mode.

See merge request !518

Eric Oulashin authored 1 month ago and Rob Swindell committed 1 month ago

DDLightbarMenu: AdditionalQuitKeys now are honored in traditional (non-lightbar) mode, and there's a new menu property, nonANSIPromptText, which allows customization of the prompt text when in traditional/non-ANSI mode.

Appears to break builds sometimes.

It seems at least some Atari ST VT-52 implementations do.

Copied from https://nix.synchro.net/jsobjs.html since jsdocs.js is crashing
for me (on Windows) in js_cryptkeyset_constructor() -> cryptlib

The ircd keeps services from auto-recycling upon request while there's an
outbound connection (e.g. to vert).

Bug introduced in commit 88e8688b

Windows Vista (and Windows Server 2008) are now the minimum versions supported.

Make Windows 6.0 (Vista) the minimum version for install.

Apparently, the IDE loads the .res file and then updates the .bpr file. So we
can't just update values in the .bpr and expect them to propagate to a rebuilt
.res file. I'm sure I've learned this lesson before and forgotten it. Perhaps
multiple times now.

Deuce's suggestion

It's in JS now.

The code is 0x1C, not 0x1E, and it's row then column.

This simply writes changed values to ctrl/textedit.ini, you can
copy these into the appropriate text.ini or text.dat.

I haven't dug in to see if text.dat has different encoding than ini
or anything, and I think that if you want to use this to build a
full text.dat, you would want to do it a bit at a time, so a follow-
on utility to convert text.ini to text.dat is likely the easiest way
to do this stuff.

Not sure why I need to... this may be some terminal-abstraction
thing.

That was quick!

As Deuce pointed out, the text[] pointers are malloc()'d so they're not
necessarily sequential/in-order addresses. Definitely not after
any text replacements have been made.

This is to work around an issue when fiddling with text data, and
will likely be able to be removed at some point.

i is incremented after reading the last entry, making this value
incorrect.