I can't wait for the Rust port of QBasic Gorillas
This is a denial-of-service attack on my productivity :)
I fondly remember the times of editing the explosion radius to "tactical nuclear banana".
Edit is now open source
31–40 of 191 posts
Re: Edit is now open source
#32Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
Now that they have a text editor that can be used in a terminal: Calling it: 2025 will be the year of Windows on the server. /s
Aside from Windows being... "windows" (IE; graphical) and the whole "we will do our own paradigm for nearly everything including file paths (UUNC included) and encoding..." Windows is actually pretty stellar if you're writing high performance software.
You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.
Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.
This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.
Re: Edit is now open source
#33Nitpick - this is a text user oriented (TUI) or a screen editor, not a CLI editor. A CLI editor is ed(1), or ex(1), or EDLIN for MS-DOS lineage.
Re: Edit is now open source
#34Earlier quoted context omitted.
They canceled the 64-bit port of NTVDM (virtual DOS machine), which is what handles all those INT 21h syscalls from DOS applications. Without that, there's honestly not much to port, and it's easier to just make a new NT-native CLI app.
Did they cancel it because dosbox exists? If so, that's smart.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general.
AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps.
AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V client (ala WSL2) instead of using 32-bit protected mode as a way to virtualize 16-bit code. However, these extensions didn't exist until way later and they didn't get support for booting 16-bit guests until later than that.
You could software emulate x86 to do NTVDM stuff. In fact, there's a FOSS program that does this, called WineVDM[0]. The MIPS/Alpha/PPC ports of NT used software emulation in NTVDM, so it is feasible.
[0] https://github.com/otya128/winevdm
Interestingly, they also recommend using DOSBox for DOS apps.
Re: Edit is now open source
#35Will the old one from DOS be replaced entirely with this?
64 bit Windows, the only sort now with W11, doesn’t have MS-DOS support, so doesn’t have the old edit to start with.
Re: Edit is now open source
#36I wonder what prevented them from porting the ms-dos EDIT.COM to 64bit Windows back then. There's still EDLIN.COM in the 32bit version.
DOS-era codebases are just terrible in a modern context, they would have to rewrite it from scratch anyway. The TUI IDE included within FreePascal is basically bitrotting due to this very reason.
Re: Edit is now open source
#37Re: Edit is now open source
#38Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without. They could just have packaged nano, but oh well.
Now that they have a text editor that can be used in a terminal: Calling it: 2025 will be the year of Windows on the server. /s
It's not my idea of a good time, but Windows pioneered some stuff that's really handy for servers.
Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...
Re: Edit is now open source
#39Earlier quoted context omitted.
It seems like your first paragraph answers the question in the second. If it is harder to use and learn then that reduces the value of free software released using it as that software is then harder to modify, fix, contribute to, etc. The tradeoff for Rust being hard should be more security and fewer bugs. The additional cost here, and the one that the OP is probably annoyed with, is that it moves away from the langu…
Is Rust harder than C++?
Yes.
Re: Edit is now open source
#40Earlier quoted context omitted.
Did they cancel it because dosbox exists? If so, that's smart.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general. AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps. AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V clie…
NTVDM has been unofficially built for x64[0] and it works (or rather, worked until MSFT started ripping-out USER32 APIs that are necessary for running Win16 apps).