Re: [Freedos-user] (no subject)
Hi, On Sun, Mar 15, 2015 at 8:34 PM, Thomas Mueller mueller6...@twc.com wrote: Using elvis 2.2, I was able to view and edit files in DR-DOS above 1.5 MB, but scrolling through a file of 3 MB was prohibitively slow; no such problem in Linux. I had bad memories of Elvis. Not that it was bad in features, but 2.2 was much more heavyweight than 1.8, and it always ran out of memory. A quick check shows that Elvis 2.2 can indeed edit more than 64 kb files, but the (HTML-based) :help almost always seems to choke and die. IIRC, the author just never had enough time nor interest to port it to 32-bit (DJGPP), so DOS was stuck with a somewhat limited 16-bit version. It does say that it uses a temporary file, but I couldn't find any trace of it (:sh), only something related to settings, no temporary user file data. Maybe that was because DOS is not really made for large RAM. Raw or XMSv3 can handle it fine (with or without DPMI on top). Obviously DJGPP stuff has no problem (usually) with pretty huge amounts. There's an old file manager on Simtel (mirrors) under /fileutil/ call DOS Controller (dc-sk.zip). It's closed source, but it's very small. It has a built-in editor which allowed almost total free conventional memory. A quick check under DOSBox (with NASM 0.98.39's nasmdoc.txt, which is ~500 kb) shows 565153 used, 14239 free. It's hard to get much better than that. Back in the day, I used (16-bit) TDE 4.0. It roughly gave you 400 kb. When Jason updated it (5.x), he converted the binary config to plain text, plus added syntax highlighting. So now the real-mode version (TDER) only gets roughly 200 kb. So I don't use that, I only use the (new) 32-bit DJGPP version (TDEP), which can handle almost anything I throw at it (within reason). Still, I prefer to switch to Linux, FreeBSD or NetBSD to edit anything serious, using vi. You mean nvi, which is an 100% compatible reimplementation but with (IIRC) unlimited undo, 8-bit clean, and maybe? filename completion in the ex command buffer. This is unlike something like VILE, which is more or less mostly compatible (but based upon MicroEmacs!). Actually, wasn't nvi loosely based upon Elvis originally? Anyways, nvi has some excellent docs, that's all I remember. Though keep in mind that vi is considered very cryptic, so most end users don't like it. Doesn't FreeBSD also come with ee as a simpler alternative? And of course Emacs lovers don't like modality but prefer modifier keys. Heck, Emacs can mimic vi, if you want. Apparently DOS, including FreeDOS, works better on an older computer than on a modern computer. No, but modern cpus aren't designed for DOS in mind (search mailing list archives for speedstep or EIST). Most computers don't even have APM anymore, so (worse, more complex) ACPI is all there is. Not to mention (lack of) multi-core and 64-bit and (popular) network drivers and (overly complex) USB. It's not the fault of the OS but instead lack of developers developers developers. I just went to drdos.com just to check the price for DR-DOS 7.03, was $79; last time I looked previously, it was $39. Dunno why, nothing's changed (AFAIK). It still good but showing its age. I'm not sure it's worth getting, honestly, unless you really need multitasking (and don't mind 64 MB task limit). Use DOSEMU! Download link for DR-DOS 7.03 from drdos.net is no good; links no longer valid is a problem with much old DOS software. Blame the popular shareware and FTP sites for disappearing. I guess most people don't have much vested interest in software preservation. Especially not these days with entirely different goals and a quicker (more destructive) upgrade pace. BTW, DR-DOS 7.03 was never freeware, AFAIK, only (temporarily?) trialware. Even OpenDOS 7.01 was non-commercial only. Use FreeDOS! I still have and occasionally use Borland Quattro Pro 5 for DOS; dBASE IV 1.5 less frequently. Well, that's half the point, to keep software compatibility. Most people (reasonably?) don't want to throw everything away. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] (no subject)
Hi, On Sun, Mar 15, 2015 at 9:19 PM, dmccunney dennis.mccun...@gmail.com wrote: On Sun, Mar 15, 2015 at 9:34 PM, Thomas Mueller mueller6...@twc.com wrote: Maybe that was because DOS is not really made for large RAM. Editors I'm aware of that ran under DOS and edited really large files used spill files, keeping what would fit in memory in RAM, and the rest on disk, swapping to disk as required. On DOS machines, that was *slow*. Most pmode editors (esp. 32-bit) don't need to swap at all if you have the available RAM. So it's not slow at all. And just saying it's always slow is wrong too. You can buy faster HDs now than ever. Not to mention obvious workarounds like UDMA, software cache, RAM disk. DOS wasn't made for large RAM. The 8088 CPU machines on which it ran had an address space of 1MB, and 640K of that was usable by DOS. If you had more RAM than that installed, you needed it seen as EMS or XMS, and accessed by convoluted programming. No, many compilers make it totally transparent to the end user. So you don't even have to write any non-portable code (usually). And this goes even beyond obvious 32-bit DPMI DJGPP-based ones (GCC, GPC, FPC, FBC). Still, I prefer to switch to Linux, FreeBSD or NetBSD to edit anything serious, using vi. Apparently DOS, including FreeDOS, works better on an older computer than on a modern computer. Yes. It was designed for older machines. It simply can't use most of what newer ones offer. No. Some things can still be supported (e.g. SIMD). But out of those, only a few get done because of lack of developers and testers. The other things are either mutually exclusive (one or other, not both, can be supported) or totally incompatible with a single-core-only OS (e.g. EIST). The really heavyweight stuff would need an entire team of professionals, though, and we just don't have the means to attract them. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Edit maximum file size
It would seem that is the logical solution. I thank you all for the advice. I have compared a few editors and have decided to start with Setedit. I am updating a bible translation (The Concordant Literal Translation) which I originally compiled for my BibleWorks program using UltraEdit in Linux. The Old Testament text recently received a long overdue update and I wish to update my text to correspond to the new one using a DOS text editor first (for kicks - if that's OK - just to see if I can. I split the OT text out and it loads fine and updates changes quickly. Of course I will be backing up my efforts in Linux with UltraEdit. On Sun, Mar 15, 2015 at 7:35 PM, Christopher Evans aaxiomfin...@gmail.com wrote: Perhaps change it to support ems/xms blocks so you can load the rest of the text beyond the first 64k? -- -Chris Evans Computer Consultant, Systems Administrator, Programmer, PC technician, and Hackreperneur Digitalatoll Solutions Group (Tawhaki Software) Cell. : 916-612-6904 | http://www.tawhakisoft.com/ Office: 916-382-9395| http://www.digitalatoll.com/ Skype: chris.evans450 | http://digitalatoll.net/ Domain for sale : http://norcalhost.com/ On Mar 13, 2015 5:16 AM, dosgeek57 donr...@gmail.com wrote: This is my number one request for FreeDOS 1.2/2/0. Can we PLEASE increase the FreeDOS edit capacity to at least match the capacity MS-DOS edit? I get so aggravated trying to open included .txt files with various DOS programs only to find that the file exceeds the capacity of FreeDOS edit. -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-Edit-maximum-file-size-tp22006.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] (no subject)
On Mon, Mar 16, 2015 at 7:51 PM, Rugxulo rugx...@gmail.com wrote: On Sun, Mar 15, 2015 at 9:19 PM, dmccunney dennis.mccun...@gmail.com wrote: On Sun, Mar 15, 2015 at 9:34 PM, Thomas Mueller mueller6...@twc.com wrote: Maybe that was because DOS is not really made for large RAM. Editors I'm aware of that ran under DOS and edited really large files used spill files, keeping what would fit in memory in RAM, and the rest on disk, swapping to disk as required. On DOS machines, that was *slow*. Most pmode editors (esp. 32-bit) don't need to swap at all if you have the available RAM. So it's not slow at all. Now, yes, if you have protected mode. Back then, you didn't. And just saying it's always slow is wrong too. You can buy faster HDs now than ever. Not to mention obvious workarounds like UDMA, software cache, RAM disk. Once again, I am referring to the Old Stone Age, when you *didn't* have that stuff, and if you had a hard drive, it might just cost as much as the rest of the PC combined. (At the bank I worked for in the 80's, one of the officers in my department got a PC with a gasp *5MB* hard drive. As I recall, it cost about $5K, and half of the cost was the HD.) DOS wasn't made for large RAM. The 8088 CPU machines on which it ran had an address space of 1MB, and 640K of that was usable by DOS. If you had more RAM than that installed, you needed it seen as EMS or XMS, and accessed by convoluted programming. No, many compilers make it totally transparent to the end user. So you don't even have to write any non-portable code (usually). And this goes even beyond obvious 32-bit DPMI DJGPP-based ones (GCC, GPC, FPC, FBC). They do now. They did not then. Still, I prefer to switch to Linux, FreeBSD or NetBSD to edit anything serious, using vi. Apparently DOS, including FreeDOS, works better on an older computer than on a modern computer. Yes. It was designed for older machines. It simply can't use most of what newer ones offer. No. Some things can still be supported (e.g. SIMD). But out of those, only a few get done because of lack of developers and testers. The other things are either mutually exclusive (one or other, not both, can be supported) or totally incompatible with a single-core-only OS (e.g. EIST). The really heavyweight stuff would need an entire team of professionals, though, and we just don't have the means to attract them. Since you *have* Linux, BSD, and even Windows, which support all that out of the box, why should anyone *bother*? __ Dennis https://plus.google.com/u/0/105128793974319004519 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
