In-Reply-To: <199504230958.FAA09058@pipe1.nyc.pipeline.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
X-Status: 



On Sun, 23 Apr 1995, Richard Santalesa wrote:

> On Fri, 21 Apr 1995 ddern@world.std.com (Daniel P Dern) said: 
> Here! Here! Daniel, I've had exactly the same experience... with nearly
> every net package and software on my several Windows systems fitting with
> each other... Windows 95, however, should be a solid end to this nightmare
Wanna BET!!
Windows 3.1, WFW, and Windows95 are all simulated multitasking "Threads" 
running under the "control" of a single threaded operating system.  At 
it's core, the kernal (MS-DOS and it's 32bit replacement) do not provide 
the necessary kernal priviledges, memory management, and ability to to 
multiple Disk I/O requests... to prevent installation packages from 
"killing each other".

Under MS-DOS, we didn't have multi-tasking so someone came up with the 
TSR.  Eventually, so many different TSRs had to be loaded in just the 
right order that someone came up with EMS and EMMs.  Windows provided
busy-wait multitasking, but applications "locked up" because one or more 
applications didn't want to WAIT, or would capture all events (The Cancel
Dialogue) leading to the dreaded "Eternal Hourglass".  The Memory 
Management features of DLLs made it easier to coordinate interprocess 
communication (just declare an array of statics within a DLL obj, you get
"shared memory").  Unfortunately, this left malloc'd memory unrecoverable 
if both application client/servers were aborted.  Of course, since there 
was no Kernal Priviledge Memory Protection, an install program could put
a new DLL where the old one was and let installed applications step into 
the ozone.  It got really fun if you stepped into a trap 0 (reboot) 
instruction.

Now we have VXDs, which are great for WindowsNT which has at least SOME 
concept of memory protection, but on Windows95, a reconfiguration, or an
application which steps into an alternate entry point can completely 
disable the entire kernal and MMU chips to the point where the only 
recourse is to Power Down.

Finally, we have the last fundamental design principle, which assumes 
that the user will interact with one application at a time, causing a 
dependency on "threads" due to the immense overhead of multitasking under 
WindowsNT.  You see, NT applications (because they are based on Win95)
must check semephores and shared memory (Remember those funny DLLs)
while running in user space.  This means that every context switch 
requires a complete MMU remap for each context switch.

Had Microsoft used a MACH or UNIX microkernal and library/kernal, the 
kernal would check semephores, signals, and interrupts on the 
application's behalf in kernal space.  The application would never start 
until the kernal confirmed that there would be no need to "wait".  This 
reduces context "switch" time to nanoseconds rather than the microseconds 
required by "Busy/Wait" systems.

Under these kernals, device drivers are loaded and started under the 
control of the kernal process only.  It used to be that you had to 
re-link the kernal with the new drivers.  Linux now has a boot-time 
loadable driver package, which other packages will probably adopt.

> -- or at least part of it. I've had great success using Win95's built-in
> TCP/IP and dialer capabilities to access the net... 

Unfortunately, this is not entirely accurate.  The Win95 TCP/IP is not 
"built-in".  It is actually a combination of a VXD (which can be clobbered
copied, or corrupted after boot), and a Winsock.dll which issues jumps 
into the VXD.  The result that happens when you run a Frontier DLL with a 
Microsoft VXD can be spectacular (looks like a scene from Poultergeist:-).

Secondly, the "Shared Memory" is still managed by the application instead 
of the kernal.  As a result, you still have the fun of misallocated memory
being entered as "executible space".  WindowsNT has corrected some of 
these problems, but not all.

An enterprize server cannot be "fixed" with a "reboot", the reboot can 
impact hundreds of users who are depending on that server's connectivity.

The package Microsoft currently calls NT-Server, at least begins to take 
on the assumptions required for a workstation.  This includes the 
assumption that each application is subordinate to the kernal, and the 
kernal must balance all resources (time, memory, I/O bandwidth...) 
amongst the applications (client OR server).  When they can sort through 
the process queue without hitting the MMU, and activate the process, 
without SWAPPING the HELP files, and clean up the messes left behind by 
sloppy programmers and "Abort" crazed users, and start-up the 
applications without taking over the screen and pasting up the 
"HourGlass" (or the galloping pony on NT), and let me "Read E-mail" while
Word churns the disk drive to get the Help values for every resource ever 
invented, and let's an Operator run/configure several Windows 
applications on several machines (a Must for System Admins), they will
have an operating system ALMOST as good as Linux.

Then all they will have to do is get it to run in 8 meg and drop the 
price to under $100.

Until then, we'll have applications with an attitude.  Just like we have 
had for the last 15 years.

The inside joke:
	Microsoft actually rewards them for that ATTITUDE.
	(Any Developer/Partners want to comment).

> Rich S. 
>
> I haven't tried the CI$ software yet, but based on my experiences 
> trying various packages over the last few months, I'm hardly surprised. 
>  
> For example: 
>  
> SuperTCP couldn't find one of its own files on its CD to install. 
> Chameleon generated duplicate icons when I tried to do an upgrade. 
> Some other package overwrote my THREED.VBX file, rendering NetCruiser 
>   and SLIPknot dead in the water. 
There's that cute overly.  Notice that these are operating system files.
Notice that the operating system did not protect the system integrety.

> Meanwhile, two packages warned me during installation that if I installed
> their 
> modules (I think the winsock.dll's, possibly their tcpman.exe), they 
> might not work with other vendors' software. 
Supposedly, all Winsock applications are identical.  The only way to be 
certain is to run them with Trumpet (the Winsock 2.0 version).

> One of my buddies reported that an early version of Internet in a Box 
> (from Sprye) blew away his mosaic.ini and hotlist file. 
I once tried to install 3 different packages, doing "uninstalls" between 
each one.  It blew away system.ini, windows.ini, tcp.ini, winsock, 
config.sys, and autoexec.bat.  Eventually I had to reformat the hard-drive
and install everything from scratch.  Total cost: 20 days at $1000/day.
Not to mention delayed production schedules.

> Sadly, this sub-industry is a joke in terms of 'user-friendly'
> installation.
It's kinda funny.  The reason the consumer market adopted TCP/IP was 
because Trumpet was so easy to install, cost $5-10 (qty 100), and worked
with a dozen downloadable applications that cost under $5 each (qty 100)
and gave Windows Users access to Open Systems architectures (Unix, Open 
VMS, MVS with TCP/IP, Tandem,...).

The TCP/IP vendors negotiated exlusive upgrades rights, and proceded to
shoot each other in the foot.

Meanwhile, the downloadable versions have been evolving into new and 
better products.  There's even a "virtual reality toolkit" at NCSA.
By the time the ink was dry on the last signature to bless HHTP 3.0,
Mosaic rolled out the first "fully compliant/no extras", implementation.
This was in part because Mosaic was the Reference implementation used to 
evaluate the workability of the specification.

> None seem to think any user might ever have any other TCP/IP program on our
> computer.  Or that we may not appreciate programs that do what they want 
> without telling us.

Haven't you noticed?  No MS-Windows Applications Vendor thinks you could 
possibly want to run some OTHER program on your computer.  Try reading 
Microsoft Word files with WordPerfect, or even a Web Browser (Where'd the 
pictures go?).  Try using NetScape while Word is trying to load.

Of course, you paid $400 each for these puppies, I guess they can have an 
ATTITUDE if they want.  Maybe they just know how easy it is for one 
application to kill the other, accidentally.

> This is hardly limited to Internet Windows software; almost ALL Windows 
> installations exhibit the same arrogant user-hostile attitude.  I am hard 
> put to believe these are the products of a multi-billion dollar industry 
> that's been around for a decade or more in the aggregate. 

This has been going on for at least 30 YEARS.  The DOS/370 kernal had the 
same types of problems back in 1965.  The solution was DOS/VS and later 
MVS, and (when users wanted to dynamically initiate 300 started tasks)
AIX.

Why do you think Kernigan and Ritchie wrote UNIX in the first place?
Everything else available at the time ran applications with attitudes!

> Quick tips: 
>  
> a: create a separate directory or so and keep backup copies, carefully
> renamed, 
> of key files for each Internet app, such as: 
>   the WinSock.dll 
>   the *.ini 
>   any hotlist(s) 
>   their tcpman.exe
Better yet - Back up Everything to TAPE.  As I noted before, the right
sequence will destroy *.ini, *.bat and *.sys, and possibly *.vxd and *.vbx

> and the THREED.VBX file version it uses. 

Better yet, get "PlugNPlay" Linux, run it off of your CD and a Dos file 
for a week and imagine what it would be like running 20 times faster.
(This version runs off of compressed files on the CD)

If you even think you like it, install a Linux partition and the "Lilo"
package.  You can boot Linux or MS-Windows and run DOS from either place.
And LINUX even includes web SERVER code (httpd).

> This is why I want a separate test machine, when the budget for it 
> permits.  Sigh. 

Still trying to scrape up the extra $2000 to upgrade your Ram/Disk to
WindowsNT compatibility.  Don't worry, when Windows95 comes out, you will.

Meanwhile, worst case, you loose $60 and end up with a partition for NTFS.

> We'll be talking about these problems briefly in the Internet session I'm 
> doing next Wednesday at ComDex/Spring in Atlanta  ("Exciting Front Ends 
> to the Internet" [ not my title] ).

Another nifty feature of Linux (And SCO unix), is that it has install AND 
uninstall procedures for almost every application.  It's kind of nice for 
installing upgrade to specific applications.

> Richard Santalesa 


From rballard@cnj.digex.net Wed May  3 21:21:25 1995