SvarDOS community forum

I've spent past month's evenings on a new project called SVED. SVED is a tiny (7K) DOS editor. Multilingual UI, small size, able to edit files >64K, can open up to 10 files simultaneously and make copy/paste operations between them. It is available in the repository of packages. pkgnet pull sved It has also its own subproject website: http://svardos.org/sved/ The plan is to make it the default SvarDOS editor soon, replacing FreeDOS edit. FreeDOS edit is cool, but it's huge, not translatable, sluggish on a 8086 and difficult to use on monochrome screens. FreeDOS edit will obviously stay available in the repository, but it no longer be the default system editor. Mateusz

I'm going to try this !

Just committed the Turkish translation for SVED to SVN.

> Just committed the Turkish translation for SVED to SVN.

Hi Berki, thank you very much for your kind contribution. The Turkish file you submitted contains 404 bytes of payload data, while currently all other translations (French, Polish, Russian) are limited to 358 bytes. Could you please make some cuts so the TR file fits into 358 bytes as well? Otherwise sved would grow in size and require an extra 512 bytes sector, which is scarce on floppies. I know it is not an obvious process, I had to spend quite some time myself on French and Russian translations to make them so compact - this included rewording the original strings to shorter text while keeping the same technical meaning and abbreviating some long words. I am confident that the Turkish language can also be made compact with some extra effort. :-) Mateusz

Hey Mateusz, you're welcome, my pleasure. I committed a shortened version of the Turkish translation. Is it OK now?

Almost there, but not quite yet: https://images89.fotosik.pl/680/01c1860d9a2d00d6.png Only 23 characters left to kill. :-) Mateusz

New commit. Crossing fingers... :-)

Awesome, you made it down to 356 bytes. Thank you! I have update the *.LNG file on svn so it includes your translation, and tomorrow I will release a new sved package. Mateusz

Hi Mateusz, SVED is really useful, especially on small floppy images. Many thanks! However, I encounter a (minor) problem with DOS 2.x. When opening an (existing) text file, status bar says "untitled", and I am forced to enter the file name when saving. No big deal, just a little annoying. Tested with PC DOS 2.10 and MS-DOS 2.11, so I guess it's an issue with DOS 2.x. Any ideas why? Frank

Hello Frank, Thanks for the kind words. I'm glad to hear that Sved is useful beyond SvarDOS. I've looked at the code and I found the reason of the behavior you observed. It is here:

> /* es:di = result buffer */

> mov es, result_seg

> mov di, result_off

> mov byte ptr es:[di], 0 /* zero out the result string in case of error */

> /* ds:si = ASCIZ filename or path */

> mov si, name_off

> mov ax, name_seg

> mov ds, ax

> mov ah, 0x60 /* DOS 3+ - canonicalize filename or path */

> int 0x21

The above is basically translating the user-provided filename into a canonical, non-ambiguous filename. That's what makes sved display "A:\XYZ\ABC\FILE.TXT" in the status bar when you load something like "sved ..\abc\.\file.txt". This relies on the INT 21h, AH=60h call that is only available since DOS 3+. I would be tempted to say that's Sved is supposed to be used on a DOS 3+ kernel, but on the other hand if that's the only thing that is broken when used with a 2.x kernel then it would be kinda cool to have this covered. I've never tested Sved on a DOS 2.x kernel myself. Is the "filename becomes untitled" bug really the only dysfunctional thing that you encountered? Honestly I'm surprised that it works at all since I've truly done zero tests on such ancient DOS kernels. Here's a quick hack, let me know if it works for you. The binary is 40 bytes bigger now, but still (slightly) under 7K. http://mateusz.viste.fr/tmp/sved-frank.zip Mateusz

Hi Mateusz, I see, thanks (oops, could have checked the sources by myself, as I use RBIL quite often - but I always have to look it up again and again, and need my time to understand it, I'm not really good in asm). Yes, SVED works flawlessly in DOS 2.x. Tested so far: I have openend 2 files at a time and copied a line between them. Also all menu functions work. Keys CTRL+RIGHT, CTRL+LEFT, CTRL+C, CTRL+X and CTRL+V do what they should do. Tested with real hardware and virt. machines (VirtualBox, PCem). SVED even opened a 170 kb text file - ok, my DOS 2.x versions still have about 520 kb free memory after loading the network drivers needed to connect their boot floppies to the "outer world" by Netware, I have mars_nwe running on a linux box to give them all DOS programs they can cope with ;-). Only: Seems that despite of a "LANG=DE", multilingual support doesn't work in DOS 2.x - not a big thing. Maybe another DOS 3+ - Int? Of course usually FreeDOS is my main *DOS, no issues there as you know yourself. Most of the time - with DOS 2.x - I use the SAVE function from the menu, immediately followed by QUIT. For lazy people like me a menu option "SAVE and QUIT" (i.e. at a time) might be handy ;-) But I understand that size matters. Frank

Hi Mateusz, just tested the "quick hack", yes it works! Frank

> Seems that despite of a "LANG=DE", multilingual support doesn't work in DOS 2.x - not a big thing. Maybe another DOS 3+ - Int?

Not really an INT 21h limitation, but close. Sved loads translation strings from its SVED.LNG file. This file is looked for in the path where SVED.EXE is, hence Sved needs to know what his "load path" exactly is (because it could have been launched from %PATH% or through a directory prefix like "\EDITORS\SVED\SVED.EXE FILE.TXT"). The process' load path is being conveniently advertised by DOS through a hidden field in the environment block, but this hidden field is only present in DOS 3+. For this to work in DOS 2.x Sved would need to scan all folders in the %PATH% looking for a SVED.LNG match. That would be slow and trigger unnecessary I/O operations. The alternative would be for SVED to look in the "current" directory, but this would present the risk of loading a SVED.LNG file that is not at all related to Sved, but just happens to be named the same (thus potentially breaking Sved). I think it's most reasonable to accept loss of multilang support on DOS earlier than 3.x, esp. since 1.x and 2.x versions did not have any codepage support anyway, so any multilang attempt would be severely limited/mutilated.

> For lazy people like me a menu option "SAVE and QUIT" (i.e. at a time) might be handy

Not a bad idea, but I do not have much space left before reaching the (self-imposed) 7K limit on Sved's binary size (in fact, contrary to what I have stated yesterday I already went beyond 7K with the DOS 2.x fix - I will have to look for some savings before release). Plus, such feature presents an ambiguity: would this "SAVE and QUIT" save ALL currently open files, or only the active (displayed) one? If ALL files, then it could be dangerous as the user might not be aware of pending changes in other files and overwrite some important stuff. If only the current file is saved, then changes in other files might be lost. Any chosen approach won't be very intuitive. A probably saner approach would be to allow the user saving changes at quit time: when user selects QUIT and there is any pending change, then instead of saying "beware you will loose data", Sved could ask "would you like to save this?". And that could be iteratively repeated for every open file. The only challenge here is how to make it fit in as few bytes of code as possible. Let me think about it. Mateusz

> I think it's most reasonable to accept loss of multilang support on DOS earlier than 3.x

I totally agree, as on a 360kb boot floppy (e.g. with PC DOS 2.10) I leave out the LNG file anyway (for space reasons). Only mentioned it because you asked for any "dysfunctional things"... and that was all I could find ;-)

> would this "SAVE and QUIT" save ALL currently open files

ok, I must admit that I didn't think about that issue, usually I only open one file. But after your recent change for "DOS 2.x compatibility" I will switch to SVED (I used ted v3 on small boot floppies, but ted has 12k binary size). Keep with your (self-imposed + impressive) 7K limit! Thanks, Frank P.S.: (and off topic): Also thanks for your well-commented code! I recently managed to compile a very "special version" of etherdfs only for DOS 3.20 - 3.30. As CDS and SDA are different compared to DOS 5.x, some changes were needed, but this version does run under (MS-)DOS 3.20 - 3.30! If interested, I could send you code and binary, although I guess your focus is not on "old" DOS versions? I suppose the target group of an "etherdfs for DOS 3.x" is quite small.

I have found yet another place that would probably break under DOS 2.x: the "SAVE AS" option. I think I have fixed it now. I have also implemented the saving-at-exit-time behavior that I mentioned earlier. No need to use the "SAVE" option now, one can QUIT right away, and Sved will warn about anything that needs saving (and allow to save right away with a single key press). I've update the test binary if you'd like to check it out: http://mateusz.viste.fr/tmp/sved-frank.zip I am left with only one problem now: Sved became "bloated", as it is 59 bytes past the 7K limit. I will look for ways to loose some bytes without sacrificing any functionality. Once the binary is back under 7K I will make a formal release. About EtherDFS: When I was writing it I was hesitating at supporting DOS 3.3. Ultimately I decided to drop it off, as supporting it led to either a bigger footprint or the need to distribute different binaries + quite some nasty #ifdefs in code. Nonetheless, I'm glad to hear that you took the challenge. :-) Could you publish your fork on some open source forge? I'd be happy to link it from the etherdfs website in case anyone else would have the need of such EtherDFS-for-DOS-3.3. Mateusz

I managed to bring SVED.COM back under 7K. I have also found and fixed a cosmetic bug related to CTRL+X / CTRL+V handling. I have no more sved plans for the time being, so this is considered a "release candidate" version. ZIP archive updated and re-uploaded right now: http://mateusz.viste.fr/tmp/sved-frank.zip I will test it out for a couple of days, and then it will be formally released and pushed to the SvarDOS pkg repository. Should you spot anything fishy with this version, let me know. Mateusz

Thanks, going to test the new version of SVED.COM, too, under severe DOS 2.x conditions :-) About EtherDFS: Ok, I've put it on github (https://github.com/CryptusDE/EtherDFS-3). Although I don't like that github doesn't preserve the original timestamps... Please check if you are fine with it and that I didn't miss giving proper credits to your code. You'll be the only visitor anyway, I guess, - who uses DOS 3.30 anymore? ;-) Frank

> going to test the new version of SVED.COM, too, under severe DOS 2.x conditions

good luck! :)

> About EtherDFS: Ok, I've put it on github (https://github.com/CryptusDE/EtherDFS-3).

Very cool, thanks. I've added a note about your version on the EtherDFS homepage at https://etherdfs.sourceforge.net/ Mateusz

SVED 2023.5 is out! It is available either from its dedicated website at http://svardos.org/sved/ or through the SvarDOS package repository (pkgnet checkup). Change log: - modified files can be saved at exit time with the space key - fix: CTRL+X and CTRL+V were not flagging the file as "modified" - improved compatibility with DOS 2.x - removed the Watcom RTL; HUGE thanks to Bernd Boeckmann for WMINCRT - SVED's disk footprint decreased from 7K to 6K Mateusz

This is a really nice piece of software :-) Perfectly balanced in size and functionallity for a basic system editor, in my opinion! Thanks for writing this. Bernd

I noticed SVED always inserts 8 spaces each time I press the TAB key. No matter at which column the cursor is. This is not, what I would expect from a text editor. Bug or feature?

> Bug or feature?

I would say - neither a bug nor a feature, but rather a "missing feature" :-P http://svn.svardos.org/blame.php?repname=SvarDOS&path=%2Fsved%2Ftrunk%2Fsved.c&rev=1580#l1372 I think this is something I added as a quick "something" when implementing tab support and then forgot to get back to it to make it smarter. I have created a bugz issue about this and will tackle it somewhere next week. https://github.com/SvarDOS/bugz/issues/64 Mateusz

> I have created a bugz issue about this and will tackle it somewhere next week.

> https://github.com/SvarDOS/bugz/issues/64

Thanks! :-)