Main page I Packages I Help I Forum
a place to talk about SvarDOS and other DOS-related things
> 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
Only 23 characters left to kill. :-)
Mateusz> /* 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 0x21The 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
> 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 handyNot 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.xI 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 filesok, 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.
> going to test the new version of SVED.COM, too, under severe DOS 2.x conditionsgood 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
> 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/64Thanks! :-)