On Wed, Sep 5, 2012 at 6:47 AM, Rugxulo <rugx...@gmail.com> wrote: > On Wed, Sep 5, 2012 at 2:36 AM, dmccunney <dennis.mccun...@gmail.com> wrote: >> On Wed, Sep 5, 2012 at 3:03 AM, Michael C. Robinson >> <plu...@robinson-west.com> wrote: >> >>> The latest version of Windows always seems to need more computing >>> horsepower than the last one... >> >> Not just Windows. I run FreeDOS ... > > Heh, I did have one guy tell me the other day online that FreeDOS was > a memory hog. I think he means for his old 186-ish emulator (compared > to really ancient MS-DOS 3.3 or whatever).
I still have my XT Clone sitting on a shelf. It has a replacement mobo with a 10mhz NEC-V20 CPU, 640K of main memory, two 5.25" 360K floppies, and two Seagate ST-225 20MB MFM drives. The V20 is 80186 compatible, and has more efficient microcode than a real Intel chip, so you get 5-15% better CPU performance at the same clock speed. It was considered a cheap speedup back in the day. I used a Hercules video card with an amber Amdek monitor, and gave it an AST 6-Pak card with a meg of EMS memory. 256K of the EMS went to a disk cache, 512K went to a RAMdisk, and the other 256K was for whatever might use EMS. I had a freeware utility from Chris (CED) Dunford that could map unused video memory above 640K to DOS. The Hercules card left over 64K, whyich I mapped and got a DOS system that thought it had 704K of main memory. I put frequently used utilitiies like Vern Buerg's LIST on the RAMdisk, loaded from AUTOEXEC.BAT, which also made the RAMdisk the first entry in my DOS PATH. I also the TEMP and TMP tp point to it, so things like archivers that created temp files would do do there. It sped things up a treat. I also used the old MKS Toolkit to give me DOS ports of Unix utilities. The selling point was a working DOS version of the Korn shell, which had everything save asynchronous background processes. Installed in fullest Unix compatibility mode, the Toolkit replaced COMMAND.COM as the boot shell with it's own INIT.EXE. IINT loaded on boot after CONFIG.SYS and AUTOEXEC.BAT were processed, and printed Login: message on the screen. Provide an ID and optional password, and INIT called /bin/login, which checked against an /etc/password file. If it found the ID, it changes to what was specified as that ID's home directory, and ran whatever was specified as that ID's shell. I had IDs that ran the MKS Korn shell, vanilla COMMAND.COM, 4DOS, and the DesqView environment. Log out of the shell, and control returned to INIT which asked for another Login:. I could change environments without rebooting. Under the Korn shell, I used aliases and functions to make the DOS PRINT command behave like the UNIX lp print spooler. You had to dig a bit to discover you *weren't* on a Unix machine. > It's funny that we're running FreeDOS which (without extenders) maxes > out at 1 MB but most new-fangled OSes nowadays need 1 GB minimum!! I had a Unix machine before I got a DOS PC. The Unix machine (which I still have) is an AT&T 3B1, big brother to their Convergent Technologies designed UNIX-PC. It uses a 10mhz MC68010 CPU, and boots and runs a Convergent port of AT&T System V R2 in *1* MB of memory. Give it more (mine has 3.5MB) and it flies. It has a bit-mapped mono monitor and GUI, but you can also attach terminals via serial ports to get a command line Unix interface, or a version of the GUI intended for character mode screens. An old client of mine had one with 2MB of RAM supporting four users on terminals plus one on the console and an attached parallel printer, running a database customized for distribution management. Performance was quite acceptable, thank you. When I got a 386 PC at 33mhz and 8MB of RAM, and compared performance of Win 3.1 on it to my 3B1, I looked in the direction of Redmond and said "What are you *doing?*" I still do. >> on an old notebook with an 867mhz >> Transmeta CPU, an IDE 4 HD, and 256MB of RAM (of which 16MB is grabbed >> off the top by the CPU for code morphing.) > > I still say that's a rare gem you have. It probably belongs in a > museum. Definitely quirky, that's for sure. ;-) It's been fun to play with. I didn't expect much, given the specs, so I haven't really been disappointed. >> It came to me with WinXP >> SP2 installed, and was frozen snail slow.. I swapped the original >> 30GB HD for a 40GB from my SO's dead laptop, repartitioned, and looked >> for Linux distros to install. I wound up with Puppy Linux (intended >> for lower end HW) > > I run Puppy, but it hasn't been nearly as lean as back in the 2.16 > days (or such). "Lean" for Linux means 128 MB minimum, even with swap, > unless you run a no-longer-supported kernel and tools, e.g. old > Slackware 11.0 / kernel 2.4.x. (Like I said, OpenSuSE and Red Hat seem > to want almost?? 1 GB just to install.) Current distros do, but they make the reasonable assumption that you *have* it. I first tried Ubuntu with the Xubuntu flavor, supposedly for lower end machines, but it crawled. Posters on the Ubuntu forums suggested that Ubuntu had a steadily increasing idea of what "low end" was, and that too much Gnome had crept into the Xubuntu distro. They suggested what I did - install from the Minimal CD to get a working CLI installation, then use apt-get to pick and choose what I wanted. The Ubuntu slice runs Ubuntu 11.04 with LXDE as the window manager. It and Puppy are both installed on ext4 file systems, to take advantage of extents. The big bottleneck isn't the limited RAM - it's slow disk I/O imposed by IDE 4. That's a BIOS limitation, so I can't just swap in a faster drive. The sort of apps that come with Puppy are chosen for small size and are sprightly enough. Other things differ. I don't even *try* to run current Firefox builds - it takes 45 seconds just to load, and is perceptibly sluggish once up. To the extent I browse from Linux on the box (not much), I use a static build of Seamonkey 1.18 on the puppy side and Midori or Opera on the Ubuntu side. None are quick, but they load in half the time FF takes and aren't as horribly sluggish when up. >> an earlier version of Ubuntu, and Win2K Pro SP4. >> Once I had it properly installed and tuned, Win2K took *less* memory >> (I got it down to about 80Mb), booted faster, and was quicker in >> operation than either Linux distro. > > Win2k is allegedly leaner than XP. I know CWS (of CWSDPMI) loved it to > death. I don't know the details. But I did, for a few months, run an > XP machine with only 128 MB of RAM. XP was quite lean (compared to > later Windows), e.g. the kernel only seemed to eat about half of that. > So I could run DJGPP or Opera but not much else (e.g. no Firefox > without major swapping, which was unusable). Win2K *is* leaner, even running the SP4 version. Mostly, I stripped out almost all tray apps loading on startup, save for the ATI video driver and an open source driver that lets it see and access the Ext4 file systems, and I disabled all unused Windows Services. (I don't run A/V or a firewall.) Turning off the Update service was a big win. The machine has all the critical updates there will be for Win2K, so no resson to have it active. Disabling it dropped a SVCHOST.EXE process that ran to handle it, and saved 10MB RAM. The majority of stuff I ran under XP runs under 2K, too, and the stuff that doesn't I can live without. >>> I suspect this is on purpose to boost computer sales. >> >> Nope. > > Well, if you think they don't purposely delay releases or put features > and fixes only in newer products, you're naive. They all definitely > have powerful marketing teams, and surely those demand they keep > something to advertise as "new!". I agree, but that doesn't change my viewpoint. Remember, people buy computers as tools to do work. The work is done by programs, and the get the programs that will do what they want to do. What OS they get is essentially driven by what the programs require. Vendors are always adding features, both to OSes and applications. Whether they are *desirable* features will depend on your viewpoint. One person's "Gotta have!" feature is another's "bloat". But generally, I assume machines have a lifespan of 3-5 years before being replaced by a newer, faster, more powerful model. Cheap "low" end now would have been expensive high end 5 years ago. >> *All* new OS releases need more hardware than prior ones, >> because they are expected to do more, and host larger and more complex >> applications. > > They all seem to, but do they really have to? I doubt it. Though it's > unfair to say since it depends on a billion things, I suppose. Do they really have to? Yes. A variant of Parkinson's Law applies: Applications expand to occupy all hardware available to run them. The fundamental factor now is that hardware is *cheap*. It's *not* unreasonable to assume the user has the hardware to support what they plan to install, and will get it if they don't have it. And because hardware is cheap, there's no incentive to optimize for size when building the app. If it needs more memory, the user will install it. That sort of optimization is time consuming and expensive. You don't want the costs it would add, nor do you want the increase in time-to-market needed for the development cycle. The people who still *do* resource constrained coding are in the embedded space, working on things like appliances and set-top boxes. No one else needs to. > I read online (Phoronix?) that Win8 supposedly did NOT regress with > regards to speed or RAM, which is surprisingly good (and probably took > real effort). It supposedly boots up much faster and allegedly can > combine 4 kb RAM pages (or whatever) for better memory use (dunno the > details beyond that). Win8 uses the NT kernel designed by Dave Cutler (who was the architect who designed VMS for DEC back when.) Dave was jump-up-and-down-and-shout insistent that it be *portable*, and he was right. There's a version of Win8 for ARM based tablets, which (comparatively speaking), have lower resources than desktops or laptops. (There used to be versions for the DEC Alpha and for MIPS CPUs.) Faster booting would be a design goal, as it was for XP, which boots a lot faster than 2K. I saw a bit on improved memory efficiency, but most of what I've seen has been slagging the Metro interface. > EDIT: Almost forgot the new MSVC 2k10 is supposedly much better, and I > blindly assume the core OS itself was recompiled with it. No idea if > that makes a difference, and maybe I'm wrong in guessing that, but > that should bring some speedups, in theory, esp. since SSE2 is > allegedly targeted by default now. Compiling specifically for the hardware can make a difference. It's why some folks with speed requirements use Intel's compilers for what they develop, figuring an Intel compiler will do a better job of optimizing for an Intel CPU than a third party product. >>> Someday maybe, ReactOS will fix that problem. >> >> I recommend not holding your breath while waiting. > > ReactOS is a difficult task and much more ambitious than it probably > should be. I guess it's a "success" that anything works. Anyways, they > did (a while back) actually decrease the RAM requirements a lot, > possibly down to 32 MB, dunno, didn't try it (ask Bernd, heh). I admire the effort they've made, but I have some notion of how big a job it is. The way you really shrink memory required is to code in assembler, but there are reasons why no one with any sense does so for anything save optimizing critical routines for speed, and does everything else in an HLL like C/C++. > BTW, I've not heavily tested it, but their MSVCRT.DLL clone does > "partially" work under HX, so that's good for us, at least. ;-) The question is what will be required to make it *fully* work. ______ Dennis https://plus.google.com/u/0/105128793974319004519 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
