>>>> Win95/Win98 would be happy with a
PC/AT 286, with appropriate RAM
>> On Thu, 22 Dec 2022, Grant Taylor via cctalk wrote:
>>> I don't think "happy" is how I would describe that.
>>> Would it run? Maybe.
>>> Would I want to run it like that? Nope. Not at all.
>> I stand corrected.
>> "Run", no.
>> "limp along", yes
>> It could do a few useful things; but was far from suitable for general
>> purpose.
On Thu, Dec 22, 2022 at 6:46 PM Glen Slick via cctalk
<cctalk(a)classiccmp.org>
wrote:
> Shirley none of you are serious about a 32-bit (at least partially)
> operating system being able to execute on a 286 processor.
>
> You couldn't even run Windows 3.1 in Enhanced mode on a 286 processor.
>
On Thu, 22 Dec 2022, Sellam Abraham via cctalk wrote:
Seems a bit impossible to me as well but Fred has made
computers do things
that would make ordinary men involuntarily lose their bladder so I look
forward to the story/explanation.
Well, some of that was just being ignorant that certain things weren't
"possible" until after they were done.
but, really, nothing fancy.
If you have A computer, and need it to do many different things
adequately, you have much greater requirements, than if you have MANY
computers, many of which are dedicated to specific tasks.
"Telephone log", "order entry", "order processing",
"bookkeeping and
accounting" don't require much; "documentation" and "desktop
publishing"
need a bit more, but different needs. And NONE of those should EVER be on
the same machines used for software development and testing.
Software development calls for more speed, for decent compile, assmble,
and link times.
Software testing must be done on a variety of machines, specifically
including ones at the level of the customer.
XenoCopy 1.000 was tested on 5150. And that was ALL that it ran
on. Changes had to be made when "compatible" machines came out.
Many companies make the mistake of providing state of the art machines to
their testers, who therefore don't experience the kinds of problems that
the customers get on crappy machines.
For example, when an operating system company uses high end RELIABLE
machines for testing, they don't experience the problems, and end up with
very poor error handling.
For example, Microsoft was unaware that a disk error, even a minor one,
could/would corrupt the content being written to disk by write cacheing in
SMARTDRV. When that was reported to them by Win3.1 beta testers, their
response was LITERALLY, "That's a hardware issue; NOT OUR PROBLEM." They
had to do a major free "update" towards DOS 6.2x because of that (SMARTDRV
was the only issue that actually forced that free update; the "problems
with disk compression" were virrtually ALL SMARTDRV.)
--
Grumpy Ol' Fred cisin(a)xenosoft.com