|
PureBytes Links
Trading Reference Links
|
WARNING: Software rant. Nothing to do with trading.
Incorrect-o-mundo, editorial@xxxxxxxxxxxxxx The real problem is that Win98
is based on Win95 which was based on Windows 3.1 which was based on Windows
2.0 which was originally written to run on 8086 processors. Intel 8086
processors could not address more than 64K of memory at a time. When the
80286 processor came out, Microsoft bent over backwards to ensure that the
meager few applications that ran on Windows 2.0 and 8086's were 100%
forward-compatible so that people wouldn't curse Microsoft and just switch
to Apple or OS/2. This meant that Microsoft had to drag those "real mode"
applications that only knew about 64K of memory at a time along with it.
But it was an "installed base" of software and users and that's the most
coveted thing for a software company. When the 386 and Windows 3.1 came
out, Microsoft did the same thing, maintained backward compatibility. When
Windows 95 came out, I remember reading a story from a trade rag where the
Microsoft developers working on the graphics subsystem for Win95 went to a
local Egghead in Redmond (back when Egghead was new and had real stores)
armed with a Microsoft corporate VISA card and bought $50,000 worth of DOS
and Windows 3.1 games and went back and played games and debugged and coded
until every one of those games worked flawlessly on Win95. Then they
released Win95. And you know what? The good news is that their hard work
paid off: Win95 was 100% backward-compatible. The bad news is that Win95
was 100% backward-compatible. It still had the 64K resource segment problem
because the programmers who wrote Windows 3.1 applications knew too much
about the 64K resource segment so they wrote software that read and wrote
directly to the 64K resource segment. They had to because they needed speed
on those old processors. And because some programers wrote apps that
read/wrote directly to this segment and because Microsoft wanted to
advertise that Win95 was 100% compatible with everyone's existing software,
the Win95 developers could not do the right thing with their operating
system (the thing that the NT developers COULD and did do): they couldn't
write an operating system that didn't have a limited resource segment and
they couldn't write an operating system that would move memory in the tiny
resource segment around to de-fragment the resource segment, atleast with
respect to 16-bit applications which TS4 is.
The number of programmers has exploded in the last decade. More and cheaper
computers. More need from corporations for software. So yeah, you're going
to find more programmers who aren't wrapped up in the details, but they
don't need to be anymore. The hardware is fast and the memory is plentiful
and the applications are expanding to fill whats available.
DOS 5 had about 30 function calls. I think Win3.1 had about 400 function
calls. OS/2 had about 2000 and over 6000 if you installed the mainframe
communications components and database components that IBM charged you an
arm and a leg for. I don't have a clue how many NT has and I've been
developing with it since beta1 around 1993. With COM, Microsoft has gotten
away from simple, discrete function calls and now combines functions calls
into groups called interfaces. Microsoft doesn't even have to release a new
version of the operating system any more to add new interfaces. You just
download a .MSI file (MicroSoft Installer), double-click it and presto,
you've got new interfaces. That's the software side. On the hardware side,
we now have TransMeta. Their first CPU has installable instruction sets.
Want to run Intel x86? Install the x86 instruction set. Moto 88K? Java
VM? Just install it. The programmers aren't moving away from the hardware
and operating system. The hardware and operating systems are moving away
from the programmers. And they are moving away faster and faster.
Software has always had bugs. It's just that back in the 70's if there was
a bug, maybe it only affected you if you worked in accounting and the
mainframe blew a fuse. In the 80's maybe it only affected you if your
automatic payroll deposit was late. In the 90's it started getting
personal, like when you spent an hour balancing you checking with Quicken
and it crashed before you could save it. In the 00's, it will drop your
highspeed comm line while you're in the middle of a trade...once a week.
Yes, we are seeing more buggy software (and programmers) out there. But
we're also seeing more software (and programmers). More software = more
choice which is usually good in the long run. Things are getting better.
Used to be, a datafeed was a book of charts printed out monthly and
delivered to you with enough space in the right margin so you could update
them during the month yourself. Used to be, Merrill-Lynch charged you $200
to "make a trade" and if you didn't like it you could go to Smith-Barney and
they'd only charge you $150.
The key is to make the right choice. Microsoft had to make a choice for
95/98 and they chose to make it compatible. As a business decision, it was
the right choice. As a software design decision, it perpetuated an old
architectural limitation. Omega Research chose to piss off it's best
developers and chose to try to be something it is not. We know the results
of the first decision, and we are pretty sure about the forthcoming results
of the second.
Fortunately, Microsoft will not be supporting the Win95 line anymore; WinME
is the last release. So no one will be able to make that choice anymore.
Sort of parallels trading software. We aren't sure if TradeStation is going
to be supported going forward, but now we have a choice of TradeLab or
RavenQuote. Maybe the next iteration of MetaStock will have improved
backtesting.
Use wisely your power of choice.
Kent
-----Original Message-----
From: editorial@xxxxxxxxxxxxx <editorial@xxxxxxxxxxxxx>
To: M. Simms <prosys@xxxxxxxxxxxxxxxx>
Cc: Omega List <omega-list@xxxxxxxxxx>
Date: Friday, December 01, 2000 12:24 PM
Subject: RE: Some PS2000i bugs need help...
-- M. Simms wrote:
> These are the side-effects caused by poor memory
> management in the core software (Win98 and TS32.exe)
>
> Best solution is to:
> 1) wait and hope for SP6 (When, oh when ?)
> 2) upgrade to Win2000 professional.
>
Your diagnosis is correct (the problem is poor memory management), but your
remedy is wrong... The real problem is in the education of the programmers.
What's happened over the past 10-15 years is that a lot of programmers have
been trained to "program" without any reference to the hardware platform(s)
on which their code is supposed to run. When the programmer does not really
understand what is happening in the memory at the hardware level he is
unable to control the memory using software...
You think you're seeing some buggy software now? Wait until people try to
write code which is not only divorced from the hardware, but divorced from
the operating system as well...
Good trading,
OM
|