DOS ain't dead

I am finishing the new version of text editor Blocek. I would appreciate it if you would test this release.
There are only english and czech version finished. The russian version I will add later and I hope that my contributors prepare the french, deutsch and turkish translations soon.

Download link is here:
http://www.laaca.borec.cz/soubory/blocek175_rc.zip


CHANGES
1.75
* tries to be more compatible with virtual environments
- copying texts from GUI dialogs to edit windows works better now
+ if you try to copy text to clipboard without any text selected, the word on cursor position will be used
- after every 65536 bytes loader added invalid character to loaded text
* slightly improved color selection dialog
+ functions for line expanding
+ optional spaces emphasing
+ Find dialog offers the phrase occurrences counting
+ right mouse click offers new word related functions
+ right mouse click (or Ctrl-L) offers new line related functions
+ correctly replaces Unicode characters above 0xFFFF to character 0xFFFD
+ keyboard shortcuts in the main menu
* buttons in some situations accept keyboard shortcuts without pressed ALT
* unicode definition tables are now separated to own TBL subdirectory

---
DOS-u-akbar!

Well, we found quite severe stability problems under FreeDOS. So, please, do not spread this test version.

---
DOS-u-akbar!

> Well, we found quite severe stability problems under FreeDOS. So, please,
> do not spread this test version.

Interesting that only freedos has problem, I quickly tested under MS-DOS and WXP and didn't find a problem.

---
DOS gives me freedom to unlimited HW access.

> Interesting that only freedos has problem, I quickly tested under MS-DOS
> and WXP and didn't find a problem.

And even more interresting that under MS-DOS,W98 and WXP it works at all
I found two obvious bugs in the code causing writtig into already dealocated memory block.
I want to change few details and release it soon.

---
DOS-u-akbar!

> I found two obvious bugs in the code causing writtig into already
> dealocated memory block.

Hehe, many yrs ago I was also hunting such kind of bug in my DJGPP program that wrote to freed memory. And it also behaves differently under different OSes, on some running fine on others crashed (not freedos but MS-DOS and Windows)...

---
DOS gives me freedom to unlimited HW access.

> > I found two obvious bugs in the code causing writtig into already
> > dealocated memory block.
>
> Hehe, many yrs ago I was also hunting such kind of bug in my DJGPP program
> that wrote to freed memory. And it also behaves differently under different
> OSes, on some running fine on others crashed (not freedos but MS-DOS and
> Windows)...

Is that a 'use-after-free' like I keep seeing in the bug fixes of Linux programs ?

+--------------------------+
Tue Oct 24 22:26:20 UTC 2023

ap/vim-9.0.2063-x86_64-1.txz: Upgraded.
Fixed use-after-free security issue.
Thanks to marav for the heads-up.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2023-5535
(* Security fix *)
__________

---
--
http://glennmcc.org/

> Is that a 'use-after-free' like I keep seeing in the bug fixes of Linux
> programs ?
>

Yes, one bug was 'use-after-free' and the second one was reading from 0x0000 address. (I forgot one implementation detail in the last part of very ancient code in tree structure functions)

---
DOS-u-akbar!

It's good to set the pointer value to NULL just after calling free, or maybe even better use a macro that will do this. Dereferencing NULL usually case an exception that cannot be missed but using deallocated memory can cause much more headache due to hidden/random behavior...

---
DOS gives me freedom to unlimited HW access.