Re: [Freedos-user] Vim is slow
I tried putting INSTALL=c:\apps\lbacac~1\bin\LBACACHE.COM in my config.sys file and I get an error: STAK nest!? otherss = [a bunch of numbers and letters] [Repeats several times]Bad or missing Command Interpreter: command.com /P /E:256 Enter the full shell Command line: [blinking cursor] Which I don't know how to do so I just turned off the computer. On reboot Windows ran an automatic chkdsk on my thumbdrive and fixed two files. I'm a bit confused by the Ramdrive thing. I mean, I get the basic concept. I take it I would be running Zim inside the ramdisk. But would I be able to access files on C: (my thumbdrive) and automatically save those same files to C: when I choose to do so, without having to manually write weird directory commands? If not, sounds like too much hassle. I will try the other cache programs...not sure if the Ramdrive thing is worth it...I want to be able to use Vim like I would any other editor. Will a Ramdrive let me do that? Don't want to use PuppyLinux...don't want to use a full-blown GUI... I tried deleting that other file from the Vim.exe directory...makes no difference... The built-in file browser in Vim that I'm referring to is netrw. It's a plugin, but it ships with Vim 7, is their default browser for opening files, deleting them, traversing directories, etc. If you want to get to netrw in Vim, in Normal mode you type :e . without the quotes, for example. The funny thing is other programs in FDOS on my thumbdrive have no problem traversing directories quickly. Like if I want to open a file from within EDIT, or Microsoft Word 5.5, or any number of other programs. Heck, if I run Necromancer's DOS Navigator, it has no problem being a quick file browser... Yeah, the reason I settled on Vim is because I wanted something quick and easy like EDIT but that could reflow text (e.g. wordwrap without carriage return symbols) like Notepad or Microsoft Word 5.5. On Sun, Nov 3, 2013 at 4:50 PM, Rugxulo rugx...@gmail.com wrote: Hi again, On Sun, Nov 3, 2013 at 9:21 AM, Miguel Garza garz...@gmail.com wrote: I'm playing with vim in FDOS. It's nice, but a bit slow in some respects, particulary when using its internal file-browser. What internal file-browser? LIST? PG? MORE? EDIT? I have no idea, you have to be more specific, there are too many pieces. I am running FDOS from a thumbdrive on a modern (well, only a few years old) computer. I added DEVICE=...himemx.exe to my config.sys file to fix a separate issue, which worked for that issue, but not for vim's slowness. Any ideas? I don't actively use VIM. It's a great tool, though, and most people (e.g. new://comp.editors) seemed to heavily prefer it over anything else. Unfortunately, 7.2 dropped support for 16-bit DOS and 7.4 dropped DOS (DJGPP) entirely. (Though no huge surprise, they weren't ever really interested. They still shipped CWSDPMI r4 years and years after r5 and r7 were out, heh.) I don't know if VIM itself is slow for what you're trying to do or if it really is just your setup being less than optimal. In fact, maybe try deleting (r4) CWSDPMI.EXE if that's in the same subdir as VIM.EXE, as it will actually use that by default if found. r7 can be much faster (e.g. 2x) on modern machines (4 MB pages). I don't normally use vi for editing. Okay, I do use it semi-frequently, but mostly I prefer TDE, just an old habit. I do use VILE a lot on Linux (since the TDE build has keyboard issues there). The DJGPP version is very very nice too, though it's not quite as advanced as VIM in some ways (e.g. syntax highlighting). I only use that rarely in DOS (e.g. VirtualBox, more keyboard bugs, heheh) though it's great. It's not slow at all, and it's (also) way more than just a minimal vi clone. In fact, it's roughly based upon MicroEmacs, so it supports a lot of stuff that most extended vi clones support (multiple buffers, windows, highlighting, etc). There aren't a lot of other good DOS vi clones. Well, Elvis is only a 16-bit version, same with the XVI build I found a while back, same with SteVIe. Unlikely that I would even pretend you should switch to those (unless your setup needed it, of course). Okay, well GNU Emacs has Viper (and 23.3 binaries exist for DJGPP), but that's probably overkill (180 MB??) for what you want. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Android is
Re: [Freedos-user] Vim is slow
Hi, On Mon, Nov 4, 2013 at 7:38 AM, Miguel Garza garz...@gmail.com wrote: I tried putting INSTALL=c:\apps\lbacac~1\bin\LBACACHE.COM in my config.sys file and I get an error: STAK nest!? otherss = [a bunch of numbers and letters] [Repeats several times]Bad or missing Command Interpreter: command.com /P /E:256 Enter the full shell Command line: [blinking cursor] Which I don't know how to do so I just turned off the computer. On reboot Windows ran an automatic chkdsk on my thumbdrive and fixed two files. I never use INSTALL (in CONFIG.SYS). In fact, I'm not sure I even fully understand it. AFAIK, it's only for TSRs for saving a few precious bytes of environment (low) RAM, so I don't bother and just install manually in AUTOEXEC. I have no idea if you can still unload such TSRs later (by design or due to bugs). http://help.fdos.org/en/hhstndrd/cnfigsys/install.htm DEVICE is usually (IIRC) only for .SYS files. So here, you would use DEVICE=C:\FDOS\BIN\XMGR.SYS /N128 (since UIDE almost always requires it), DEVICE=C:\FDOS\BIN\UIDE.SYS /E /N2, and then (if you don't care what drive the RAM disk is, although Eric's FINDDISK.COM can help find it later) DEVICE=C:\FDOS\BIN\RDISK.COM /S20 (or whatever). Okay, so I don't remember proper parameters, lemme (partially) quote my CONFIG.SYS: DEVICE=C:\UTILS\XMGR.SYS /N128 DEVICEHIGH=C:\UTILS\UIDE.SYS /S127 /D:FDCD000 /H SHELL=C:\FDOS\COMMAND.COM C:\FDOS /E:1024 /P REM (this is from AUTOEXEC.BAT, I guess I specifically wanted G:\ here, heh) set RAMDRIVE=g lh rdisk /s150 /:%RAMDRIVE% md %RAMDRIVE%:\temp for %%a in (TEMP TMP TMPDIR) do set %%a=%RAMDRIVE%:\temp I'm a bit confused by the Ramdrive thing. I mean, I get the basic concept. I take it I would be running Zim inside the ramdisk. But would I be able to access files on C: (my thumbdrive) and automatically save those same files to C: when I choose to do so, without having to manually write weird directory commands? If not, sounds like too much hassle. The RAM drive is just a normal (e.g. FAT16) drive that happens to be on (fast) RAM instead of (slow) hard drives or floppies. 99% of DOS utilities don't know (and don't need to know) the difference. Note that this almost always uses XMS (or similar), too, so again, you need XMGR (or HIMEMX or whatever) loaded. You don't have to install VIM nor run it from RAM disk at all. Indeed it won't automatically save anything permanently there as RAM is wiped upon reboot. The point is that anything you do run atop there is much much faster. So it's just a fast, but temporary, work directory. You do whatever you need to do, save the results, then copy (or move) that to more permanent storage (e.g. hard disk) later. I will try the other cache programs...not sure if the Ramdrive thing is worth it...I want to be able to use Vim like I would any other editor. Will a Ramdrive let me do that? Yes, VIM should work fine as normal. It's just another drive to VIM, nothing special. Don't want to use PuppyLinux...don't want to use a full-blown GUI... I suspected as much, just mentioning for completeness. It's probably more user friendly and does things that FreeDOS doesn't (or can't). And vice versa, of course. :-) BTW, IIRC there is a nox option to not load X11 if you don't want or need it for that particular session. I tried deleting that other file from the Vim.exe directory...makes no difference... Okay. So you're sure you're using CWSDPMI r7? The built-in file browser in Vim that I'm referring to is netrw. It's a plugin, but it ships with Vim 7, is their default browser for opening files, deleting them, traversing directories, etc. If you want to get to netrw in Vim, in Normal mode you type :e . without the quotes, for example. Okay, I just haven't used VIM (nor even VILE) enough to know every command and extension, plugin, etc. I know GNU Emacs has dired for things like this, but normally I don't need it. The funny thing is other programs in FDOS on my thumbdrive have no problem traversing directories quickly. Like if I want to open a file from within EDIT, or Microsoft Word 5.5, or any number of other programs. Heck, if I run Necromancer's DOS Navigator, it has no problem being a quick file browser... Dunno, but it shouldn't be slow without good reason, so it must be some configuration issue. Yeah, the reason I settled on Vim is because I wanted something quick and easy like EDIT but that could reflow text (e.g. wordwrap without carriage return symbols) like Notepad or Microsoft Word 5.5. It should be fast, in theory, but apparently your setup is doing something weird. Well, it's definitely not DOS' fault. Believe it or not, even without modern features, it's still pretty quick. Maybe it's VIM's fault, but I doubt it. It's probably something really trivial (like what Eric hinted at). -- November Webinars for C, C++, Fortran Developers Accelerate application
Re: [Freedos-user] Vim is slow
I tried deleting that other file from the Vim.exe directory...makes no difference... Okay. So you're sure you're using CWSDPMI r7? I don't know? How do I tell? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Vim is slow
Miguel Garza schreef op 3-11-2013 16:21: I'm playing with vim in FDOS. It's nice, but a bit slow in some respects, particulary when using its internal file-browser. I am running FDOS from a thumbdrive on a modern (well, only a few years old) computer. I added DEVICE=...himemx.exe to my config.sys file to fix a separate issue, which worked for that issue, but not for vim's slowness. Any ideas? USB Flash Drives can be pretty slow for reads/writes that are non-sequential in nature, just like harddisks. What you could do is try to run a cache-driver like LBACACHE, or to install a ramdisk driver and copy files over to the created ramdisk. SHSURDRV is such a ramdisk driver, so is RDRV (part of UIDE/UDVD driver collection) Bernd -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Vim is slow
Hi, On Sun, Nov 3, 2013 at 9:54 AM, Bernd Blaauw bbla...@home.nl wrote: Miguel Garza schreef op 3-11-2013 16:21: I'm playing with vim in FDOS. It's nice, but a bit slow in some respects, particulary when using its internal file-browser. I am running FDOS from a thumbdrive on a modern (well, only a few years old) computer. I added DEVICE=...himemx.exe to my config.sys file to fix a separate issue, which worked for that issue, but not for vim's slowness. Any ideas? USB Flash Drives can be pretty slow for reads/writes that are non-sequential in nature, just like harddisks. What you could do is try to run a cache-driver like LBACACHE, or to install a ramdisk driver and copy files over to the created ramdisk. SHSURDRV is such a ramdisk driver, so is RDRV (part of UIDE/UDVD driver collection) Indeed, the flash drive is probably the main culprit, it's very slow for writes. The best solution I've found is to use both cache and RAM disk. At bootup, copy the most frequently used utils to the RAM drive and put that in your PATH. That's what I do when I boot up my RUFUS-installed FreeDOS USB drive (though I native boot on my desktop much more frequently, to be honest, it's just easier). Just for the record, the speed goes from fastest to slowest with various media: RAM drive, hard drive, CD drive, USB drive, floppy drive. Okay, that's a rough guess, I haven't fully benchmarked them all, but for sure RAM is faster than anything, so even with a cache loaded (see below), it's still not as fast as cache + RAM disk. http://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg13098.html Long story short: download Jack's DRIVERS.ZIP (or similar) and use XMGR.SYS (XMS), UIDE.SYS (cache) and RDISK.COM (RAM drive) and copy flash drive's C:\UTILS to RAM drive's G:\UTILS and put that in the PATH. Of course, if you want to save anything for later use, you'll still have to manually do that (to flash drive) before shutdown. Honestly, it may be more user friendly (for you) to just install PuppyLinux to USB and run DOSEMU. At least it saves your changes automatically. Though Fedora liveUSB may work too (persistent changes), but I haven't really tried since old F14 (and DOSEMU isn't in their repos, gotta get it manually). Well, RUFUS may be too minimal by default. Maybe FreeDOS needs a better (public) example (or ten) of different setups (autoexec.bat, config.sys). But I think RUFUS does optionally allow you to install the full FD 1.1 distro. (UNetBootIn does too but doesn't save changes.) Well, either way, it's a lot of manual tweaking since everybody is different. I know this isn't a perfect answer by any means, but hopefully it gives you some idea. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Vim is slow
Hi again, On Sun, Nov 3, 2013 at 9:21 AM, Miguel Garza garz...@gmail.com wrote: I'm playing with vim in FDOS. It's nice, but a bit slow in some respects, particulary when using its internal file-browser. What internal file-browser? LIST? PG? MORE? EDIT? I have no idea, you have to be more specific, there are too many pieces. I am running FDOS from a thumbdrive on a modern (well, only a few years old) computer. I added DEVICE=...himemx.exe to my config.sys file to fix a separate issue, which worked for that issue, but not for vim's slowness. Any ideas? I don't actively use VIM. It's a great tool, though, and most people (e.g. new://comp.editors) seemed to heavily prefer it over anything else. Unfortunately, 7.2 dropped support for 16-bit DOS and 7.4 dropped DOS (DJGPP) entirely. (Though no huge surprise, they weren't ever really interested. They still shipped CWSDPMI r4 years and years after r5 and r7 were out, heh.) I don't know if VIM itself is slow for what you're trying to do or if it really is just your setup being less than optimal. In fact, maybe try deleting (r4) CWSDPMI.EXE if that's in the same subdir as VIM.EXE, as it will actually use that by default if found. r7 can be much faster (e.g. 2x) on modern machines (4 MB pages). I don't normally use vi for editing. Okay, I do use it semi-frequently, but mostly I prefer TDE, just an old habit. I do use VILE a lot on Linux (since the TDE build has keyboard issues there). The DJGPP version is very very nice too, though it's not quite as advanced as VIM in some ways (e.g. syntax highlighting). I only use that rarely in DOS (e.g. VirtualBox, more keyboard bugs, heheh) though it's great. It's not slow at all, and it's (also) way more than just a minimal vi clone. In fact, it's roughly based upon MicroEmacs, so it supports a lot of stuff that most extended vi clones support (multiple buffers, windows, highlighting, etc). There aren't a lot of other good DOS vi clones. Well, Elvis is only a 16-bit version, same with the XVI build I found a while back, same with SteVIe. Unlikely that I would even pretend you should switch to those (unless your setup needed it, of course). Okay, well GNU Emacs has Viper (and 23.3 binaries exist for DJGPP), but that's probably overkill (180 MB??) for what you want. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
