somewan
Content Type
Profiles
Forums
Events
Posts posted by somewan
-
-
M$ software is in a state of decline... definitely.
Sounds more like a state of inflation to me... much like the concept
of "inflation" of currencies (the decline of currency value per unit).
In the good old days 10 floppies would suffice, now 10 CDs...
One needs to look outside of "code". While it's very likely there is huge swathes of not-so-veryily-optimized code in Vista - much like everything else being produced today it is overladen with graphical candy.Text also takes a lot of space compared to code - especially
the modern bad habit of using 16 bits to store 7 bits. 16-bit
code is almost amazingly compact. Try invoking DEBUG.COM
on WIN.COM, and use the U command (repeatedly) and note
the increase of memory addresses to the left.
Thats because Vista is supposed to be an OS, i.e. it's not supposed to consume the resources, but rather only provide services for the apps that *are* supposed to be using the majority of the system resources. A game being 2-5Gb is understandable, as it contains a lot of graphics and textures, and games are supposed to have those. An OS is not a game... it doesn't require any fancy graphics and textures.I've heard Vista requires a 3D card, which seems rather absurd.
Sounds more like Quake XII (or whatever) than MS-windows (NT 7?).
Besides, the "cool graphics" don't buy much in terms of usability...
As a beginner, I found the DOSSHELL more or less immediately
obvious how to navigate, with either the mouse or keyboard,
and the same was true for Win3.x. In fact, I would say the pull-
down menus and program groups you'd see on the desktop when
starting Win3.x are more obvious than the start button, or even
worse, the trash bin,"online services", "network" and other weird
"system"-icons appearing in Win95.
Additionally, the meaning of icons are often far from obvious, and
I find myself waiting for the "tooltip" on a daily basis, so unless
I'm especially bad at the task, beginners can be expected to have
even greater difficulties.
0 -
i realy never ever heared of so mutch BS in my life....
i know there are lots of guys and girls who dont have the money for a better computer ....
but thinking that 98 has a better HAL than for example windows 2k xp or vista is like saying that a toad will outrun an antilope or a sail plain wil better manourvre than an F15 tomcat....
For an OS never intended to be ported to other architectures (Alpha, MIPS, etc.),
W98 has a reasonable HAL (hardware abstraction layer) - most hardware
dependencies are isolated to particular VxDs that could be amended or replaced
with relative ease. The same is true for MS-DOS - the traditional design had all
hw-deps in IO.SYS - OEMs were given the source code for customisation to their
hardware (whereas MSDOS.SYS was provided in object form only)... but both
DOS and W3.x/9x were always closely tied to the x86 CPU architecture, largely
written in assembly language (making them more efficient and compact).
The NT designers, however, tried hard to make the OS portable even to
alien architectures (RISCs in particular) - with C++ as the implementation
language, and the famous"HAL" for shielding the rest of the system from
hardware dependencies, and as a matter of fact they went as far as
building a 286-emulator into the system for running DOS/Win16 software
on the other (non-PC) architectures. Such effort was expended in the
hope of seriously competing with Unix in workstation and server markets.
Fortunately Linux and the free BSDs arrived just on time to thwart those
sinister plans, hopefully for ever.
Or perhaps you weren't thinking of "abstraction" but of "virtualisation",
which is actually a specialty of the Win3.x/9x series - no other OS(*),
whether NT/XP/2K or Unix-like, comes close to matching the level of
virtualisation implemented in W9x VxDs. From the trival tasks of routing
keystrokes and mouse movement to the proper VM (one of of which is
the 16-bit shell - known as the desktop), to the rather more impressive
archievements of simulating the display device, sound card and DMA
channels well enough to allow applications written with almost exclusive
access to the machine in mind, to run properly.
(* VMware, Qemu and similar virtual machine applications do exceed the
virtualisation in Win9x, but they are applications dedicated to that task,
rather than general purpose operating systems)
NT/2K/XP falls short, after all the years they've had to get the job done,
and with full access to tried and tested reference implementations (namely
the Win9x source code)! Perhaps we're supposed to view these
deficiencies, whether due to lack of ambition or lack of skill, as reasons
for "upgrading" to one of those systems, just as we're supposed to
regard an ever richer "legacy" as a bad thing.
Not that Win9x or any other OS from Redmond or other sources is
perfect. For example, the limitations of the 16-bit core Win3.x/9x
components are real, bugs are hiding in all layers of the system,
the hardware support is rapidly getting outdated (as others have
mentioned), an additional or reivsed file system is needed, many
parameters that should be configurable are actually fixed, and so on...
but that's still a lot easier to fix than Microsoft's supposed successor
OSes would be - imagine weeding through 7 GB to find the scattered
pieces that might be worth preserving!
ever tried multi-treaded aplications (true multi-treading like cad).I tried Autocad once... whether it was multi-threaded I don't know.
I also wrote my own multi-threading kernel, resulting in an ~820 byte
DOS .COM-file that I successfully verified the proper operation of in a
Win98 DOS box. Vista would certainly crumble under such heavy load.
Furthermore, if you load a kernel debugger, such as Soft-Ice or
WDEB386 (comes with the DDK), you can view system state
information about active threads and VM (each VM contains at
least one thread, in addition to other resources).
0 -
Now just one technical question: how long it takes for a Vista platform to find a piece of information among 7GB of datas?
Watch the "Search" video here. It's pretty freakin quick IMO. Even when you haven't just created the files, the search is very fast.
In my case, it takes much longer to find newer files, as they aren't in the index (just a list of
files on a number of computers and file systems) yet.
0 -
Another alternative is to check for drives via hardware I/O through the ports starting at 1F0 (primary IDE controller) and 170 (secondary IDE controller)
That method seems to yield the best results (including an
ASCII model name) - even on older computers where the
BIOS is incapable of detecting or supporting the drive.
I copied and pasted a chunk below from an IDE document
I didn't know I had.
If you have SCSI like me, the simple method is to load an
ASPI driver from CONFIG.SYS. Both Adaptec and LSI drivers
will scan the bus and list all devices by default. The hard
but more interesting way is to program the SCSI host
adapter card directly - get the data sheet/manual first.
(Also, if you ever wondered why a proper SCSI driver
consumes less CPU, the manual should be enlightening.)
LSI53C1010 - PCI to Dual-Channel Ultra160 SCSI Controller
IDE doc quote follows...
5. Register Address Decoding
The host addresses the drive with programmed I/O. Host address lines A0, A1,
A2, chip select CS1FX- and CS3FX-, IOR- and IOW- address the disk registers.
Host address lines A3...A9 generate the two chip selects: CS1FX- and CS3FX-.
Chip select CS1FX- accesses the eight hard disk Command Block Registers.
Chip select CS3FX- is valid during 8 bit transfers to/from the Control Block
registers alternate status and Device Control, and drive address.
The drive selects the primary or alternate command block addresses using
address bit A7.
(Note: What the above sentence means is that there is a provision for a
primary host adapter at I/O address 1FX/3FX and a secondary host adapter at
I/O adress 17X/37X. Each host adapter can have up to two hard drives
MASTER/SLAVED off it).
See below for a graphical explanation:
HEX BINARY DESCRIPTION
1FX 0001 1111 XXXX Primary Command Registers
3FX 0011 1111 XXXX Primary Control Registers
17X 0001 0111 XXXX Alternate Command Registers
37X 0011 0111 XXXX Alternate Control Registers
^
|
+--- Address bit A7
X means "don't care" i.e. X can be 0h, 1h, 2h, ..., Dh, Eh, Fh or 0b, 1b).
Data bus lines D8...D15 are valid only when IOCS16- is active and the drive
is transferring data. The transfer of ECC information occurs only on data
bus lines D0...D7 and data bus lines D8...D15 are invalid during such
transfer.
7. I/O Port Functions
+----+------+------+---+---+---+----------------+---------------+
|Addr|-CS1FX|-CS3FX|SA2|SA1|SA0| Read (-IOR) | Write (-IOW) |
+----+------+------+---+---+---+----------------+---------------+-----------+
| | 0 | 0 | X | X | X | ILLEGAL | ILLEGAL | <--+ |
| | 1 | 1 | X | X | X | High Impedance | Not Used | Control |
|3FX | 1 | 0 | 0 | X | X | High Impedance | Not Used | Block |
|3FX | 1 | 0 | 1 | 0 | X | High Impedance | Not Used | Registers |
|3F6 | 1 | 0 | 1 | 1 | 0 | Altern Status | Device Control| | |
|3F7 | 1 | 0 | 1 | 1 | 1 | Drive Address | Not Used | <--+ |
+----+------+------+---+---+---+----------------+---------------+-----------+
|1F0 | 0 | 1 | 0 | 0 | 0 | Data Port | Data Port | <--+ |
|1F1 | 0 | 1 | 0 | 0 | 1 | Error Register | Precomp | | |
|1F2 | 0 | 1 | 0 | 1 | 0 | Sector Count | Sector Count | Command |
|1F3 | 0 | 1 | 0 | 1 | 1 | Sector Number | Sector Number | Block |
|1F4 | 0 | 1 | 1 | 0 | 0 | Cylinder Low | Cylinder Low | Registers |
|1F5 | 0 | 1 | 1 | 0 | 1 | Cylinder High | Cylinder High | | |
|1F6 | 0 | 1 | 1 | 1 | 0 | Drive / Head | Drive / Head | | |
|1F7 | 0 | 1 | 1 | 1 | 1 | Status | Command | <--+ |
+----+------+------+---+---+---+----------------+---------------+-----------+
At power-up or after reset, the Command Block Registers are initialized to
the following values:
REGISTER VALUE
1F1 Error : 01
1F2 Sector Count : 01
1F3 Sector Number : 01
1F4 Cylinder Low : 00
1F5 Cylinder High : 00
1F6 Drive / Head : 00
------------------------------------------------------------------------
8. Register Descriptions
1F0: Read/Write: DATA PORT REGISTER
All data transferred between the device data buffer and the host passes
through this register. Also, the port to which the sector table is
transferred during execution of the Format command. Transfers of ECC
bytes during the execution of Read/Write Long commands are 8 bit
transfers.
1F1: Read: ERROR REGISTER
Contains status information about the last command executed by the
drive. The contents of this register are valid only when the error bit
(ERR) in the Status Register is set, except at drive power-up or at the
completion of the drive's internal diagnostics, when the register
contains a status code. When the error bit (ERR) is set, Error Register
bits are interpreted as such:
+-----+--------+-------------------------------------------------------------+
| BIT | Mnemon | Description |
+-----+--------+-------------------------------------------------------------+
| 7 | BBK | Bad block mark detected in the requested sector's ID field |
| 6 | UNC | Uncorrectable data error encountered |
| 5 | | Not used |
| 4 | IDNF | Requested sector's ID field not found |
| 3 | | Not used |
| 2 | ABRT | Command aborted due to drive status error or invalid command|
| 1 | TK0NF | Track 0 not found during execution of Recalibrate command |
| 0 | AMNF | Data address mark not found after correct ID field found |
+-----+--------+-------------------------------------------------------------+
1F1: Write: WRITE PRECOMPENSATION
The drive ignores the write precompensation value passed by the host.
1F2: Read/Write: SECTOR COUNT REGISTER
Defines the number of sectors of data to be transferred across the host
bus, for the subsequent command. If the value in this register is zero,
the sector count is 256 sectors. If the command executes successfully,
the value in this register at command completion is zero. As each
sector is transferred, the Sector Count register is decremented by one
to reflect the number of sectors remaining to be transferred. If the
command execution is not successful, this register contains the number
of sectors that must be transferred to complete the original request.
1F3: Read/Write: SECTOR NUMBER REGISTER
Contains the ID number of the first sector to be accessed by the
subsequent command. The sector can be from one to the maximum number of
sectors per track. See the command description for additional
information about the contents of the Sector Number Register following
command completion whether successful or unsuccessful.
1F4: Read/Write: CYLINDER LOW REGISTER
Contains the eight low order bits of the starting cylinder address for
any disk access. On multiple sector transfers that cross cylinder
boundaries, this register is updated at the end of the command to
reflect the current cylinder number. The least significant bits of the
cylinder address are loaded into the cylinder low register.
1F5: Read/Write: CYLINDER HIGH REGISTER
Contains the eight high order bits of the starting cylinder address for
any disk access. On multiple sector transfers that cross cylinder
boundaries, this register is updated at hte end of the command to
reflect the current cylinder number. The most significant bits of the
cylinder address are loaded into the cylinder high register.
1F6: Read/Write: DRIVE/HEAD REGISTER
Contains the drive ID number and its head number for any disk access.
The contents of the Drive/Head Register are defined on execution of the
Initialize Drive Parameters command. The bits are defined as follows:
+-----+----------+---------------------------------------------------------+
| BIT | Mnemonic | Description |
+-----+----------+---------------------------------------------------------+
| 7 | Reserved | Always one. |
| 6 | Reserved | Always zero. |
| 5 | Reserved | Always one. |
| 4 | DRV | 0 to select primary drive, 1 to select secondary drive. |
| 3 | HS3 | MSB of head number. |
| 2 | HS2 | |
| 1 | HS1 | |
| 0 | HS0 | LSB of head number. |
+-----+----------+---------------------------------------------------------+
Upon command completion this register is updated to refplect the head
number currently selected.
1F7: Read: STATUS REGISTER
Contains information about the status of the drive and controller. The
contents of this register are updated at the completion of each
command. When the busy bit is set, no other bits in the Command Block
Registers are valid. When the busy bit is not set, the information in
the Status Register and Command Block Registers is valid.
+-----+----------+----------------------------------------------------------+
| BIT | Mnemonic | Description |
+-----+----------+----------------------------------------------------------+
| 7 | BUSY | Busy bit. Set by the controller logic of the drive when |
| | | ever the drive has access to and the host is locked out |
| | | of the Command Block Registers. Set under the following |
| | | conditions: |
| | | o Within 400 nsec after the negation of RESET or after |
| | | SRST is set in the Device Control Register. After a |
| | | reset it is recomended that BUSY be set no more than |
| | | 30 seconds. |
| | | o Within 400 nsec of a host write to the Command |
| | | Register with a Recalibrate, Read Long, Read Buffer, |
| | | Read, Read Verify, Initialize Drive Parameters, Seek |
| | | Identify Drive, or Execute Drive Diagnostic command. |
| | | o Within 5 microseconds following the transfer of 512 |
| | | bytes of data during the execution of a Write, Write |
| | | Buffer or Format Track command; or 512 bytes of data |
| | | and the appropriate number of ECC bytes during the |
| | | execution of a Write Long command. |
| | | When BUSY is set no Command Block Register can be |
| | | written too and a read of any Command Block Register |
| | | returns the contents of the Status Register. |
| | | |
| 6 | DRDY | Drive Ready bit. Indicates that the drive is ready to |
| | | accept commands. When and error occurs, this bit stays |
| | | unchanged until the host reads the Status Register then |
| | | again indicates that hte drive is ready. On power up, |
| | | this bit should be cleared and should remain cleared |
| | | until the drive is up to speed and ready to accept a |
| | | command. |
| | | |
| 5 | DWF | Drive Write Fault bit. When an error occurs, this bit |
| | | remains unchanged until the host reads the Status |
| | | Register, then again indicates the current write fault |
| | | status. |
| | | |
| 4 | DSC | Drive Seek Complete bit. This bit is set when a seek |
| | | operation is complete and the heads are settled over a |
| | | track. When an error occurs, this bit remains unchanged |
| | | until the host reads the Status Register, then again it |
| | | indicates the current seek complete status. |
| | | |
| 3 | DRQ | Data Request bit. When set it indicates that the drive |
| | | is ready to transfer a word or byte of data between the |
| | | host and the data port. |
| | | |
| 2 | CORR | Corrected Data bit. When a correctable data error has |
| | | been encountered and the data has been corrected, this |
| | | bit is set. This condition does not terminate a multi |
| | | sector read operation. |
| | | |
| 1 | INDEX | Index bit. Set when the index mark is detected once per |
| | | disk revolution. |
| | | |
| 0 | ERROR | Error bit. When set indicates that the previous command |
| | | ended in an error. The other bits in the Error Register |
| | | and Status Register contain additional information about |
| | | the cause of the error. |
+-----+----------+----------------------------------------------------------+
1F7: Write: COMMAND REGISTER
When the host request a command it is transferred to the hard drive
through an eight bit code written to the command register. As soon as
the drive receives a command in its command register, it begins
execution of the command. The following table lists the commands in
alphabetical order and the parameters for each executable command:
+--------+---------------------------------+-----------------+
| Command| Command Description | Parameters Used |
| Code | | PC SC SN CY DH |
+--------+---------------------------------+-----------------+
| 98h @ | Check Power Mode | V D |
| E5h @ | Check Power Mode (same as 98h) | V D |
| 90h | Execute Drive Diagnostic | D+ |
| 50h | Format Track | V V |
| ECh @ | Identify Drive | D |
| 97h @ | Idle | V D |
| E3h @ | Idle (same as 97h) | V D |
| 95h @ | Idle Immediate | D |
| E1h @ | Idle Immadiate (same as 95h) | D |
| 91h | Initialize Drive Parameters | V V |
| E4h @ | Read Buffer | D |
| C8h @ | Read DMA With Retry | >> Unknown << |
| C9h @ | Read DMA | >> Unknown << |
| C4h @ | Read Multiple | V V V V |
| 20h | Read Sectors With Retry | V V V V |
| 21h | Read Sectors | V V V V |
| 22h | Read Long With Retry | V V V V |
| 23h | Read Long | V V V V |
| 40h | Read Verify Sectors With Retry | V V V V |
| 41h | Read Verify Sectors | V V V V |
| 1Xh | Recalibrate | D |
| 7Xh | Seek | V V |
| EFh @ | Set Features | V D |
| C6h @ | Set Multiple Mode | V D |
| 99h @ | Set Sleep Mode | D |
| E6h @ | Set Sleep Mode (same as 99h) | D |
| 96h @ | Standby | V D |
| E2h @ | Standby (same as 96h) | V D |
| 94h @ | Standby Immediate | D |
| E0h @ | Standby Immediate (same as 94h) | D |
| 8Xh | Vendor Unique | >> Unknown << |
| 9Ah | Vendor Unique | >> Unknown << |
| C0h | Vendor Unique | >> Unknown << |
| C1h | Vendor Unique | >> Unknown << |
| C2h | Vendor Unique | >> Unknown << |
| C3h | Vendor Unique | >> Unknown << |
| F5h | Vendor Unique | >> Unknown << |
| F6h | Vendor Unique | >> Unknown << |
| F7h | Vendor Unique | >> Unknown << |
| F8h | Vendor Unique | >> Unknown << |
| F9h | Vendor Unique | >> Unknown << |
| FAh | Vendor Unique | >> Unknown << |
| FBh | Vendor Unique | >> Unknown << |
| FCh | Vendor Unique | >> Unknown << |
| FDh | Vendor Unique | >> Unknown << |
| FEh | Vendor Unique | >> Unknown << |
| FFh | Vendor Unique | >> Unknown << |
| E8h @ | Write Buffer | D |
| CAh @ | Write DMA With Retry | >> Unknown << |
| CBh @ | Write DMA | >> Unknown << |
| C5h @ | Write Multiple | V V V V |
| E9h @ | Write Same | >> Unknown << |
| 30h | Write Sectors With Retry | V V V V |
| 31h | Write Sectors | V V V V |
| 32h | Write Long With Retry | V V V V |
| 33h | Write Long | V V V V |
| 3Ch @ | Write Verify | V V V V |
+--------+---------------------------------+-----------------+
KEY FOR SYMBOLS IN ABOVE TABLE:
PC Register 1F1: Write Precompensation
SC Register 1F2: Sector Count
SN Register 1F3: Sector Number
CY Register 1F4+1F5: Cylinder low + high
DH Register 1F6: Drive / Head
@ These commands are optional and may not be supported by some drives.
D Only DRIVE parameter is valid, HEAD parameter is ignored.
D+ Both drives execute this command regardless of the DRIVE parameter.
V Indicates that the register contains a valid paramterer.
Commands with >> Unknown << Parameters are not described in this
document.
If a parameter is blank, then the command does not require the contents
of that register.
3F6: Read: Alternate Status Register
Contains the same information as the Status Register in the Command
Block. Reading the Alternate Status Register does not imply an
interrupt acknowledge from the host or clear a pending interrupt. See
the description of the Status Register above for a definition of bits
in this register.
3F6: Write: Device Control Register
The bits in the Device Control Register are lister in the table below:
+-----+----------+----------------------------------------------------------+
| BIT | Mnemonic | Description |
+-----+----------+----------------------------------------------------------+
| 7 | Reserved | |
| 6 | Reserved | |
| 5 | Reserved | |
| 4 | Reserved | |
| 3 | 1 | Always set. |
| 2 | SRST | Host Software Reset bit. When this bit is set the drive |
| | | is held reset. If two drives are daisy chained on the |
| | | interface, this bit resets both drives simultaneously. |
| | | |
| 1 | nIEN | Drive Interrupt Enable bit. The enable bit for the drive |
| | | interrupt to the host. When nIEN is 0 or the drive is |
| | | selected the host interrupt signal INTRQ is enabled |
| | | through a tri state buffer to the host. When nIEN is 1 |
| | | or the drive is not selected the host interrupt signal |
| | | INTRQ is in a hig himpedance state regardless of the |
| | | presence or absence of a pending interrupt. |
| | | |
| 0 | 0 | Always clear. |
+-----+----------+----------------------------------------------------------+
3F7: Read: Drive Address Register
This port returns the drive select and head select addresses for the
drive currently selected. The Drive Address bits are listed in the
table below:
+-----+----------+------------------------------------------------------+
| BIT | Mnemonic | Description |
+-----+----------+------------------------------------------------------+
| 7 | HiZ | This bit is in high impedance when read. |
| 6 | nWTG | Write Gate bit. When a write to the hard drive is in |
| | | progress, nWTG is 0 |
| 5 | nHS3 | Negated MSB of head number |
| 4 | nHS2 | |
| 3 | nHS1 | |
| 2 | nHS0 | Negated LSB of head number. |
| 1 | nDS1 | Drive 1 Select bit. When 0, Drive 1 is selected. |
| 0 | nDS0 | Drive 0 Select bit. When 0, Drive 0 is selected. |
+-----+----------+------------------------------------------------------+
------------------------------------------------------------------------
9. Command Descriptions
The drive decodes and executes commands loaded into the Command Register. In
applications involving two hard drives, both drives receive all commands but
only the selected drive executes commands. The recommended procedure for
executing a command on the selected drive is:
1. Wait for drive to clear BUSY.
2. Load required parameters in the Command Block Registers.
3. Activate the Interrupt Enable (nIEN) bit.
4. Wait for drive to set DRDY.
5. Write the command code to the Command Register.
Execution of the command begins as soon as the drive loads the Command Block
Register. The remainder of this section describes the function of each
command.
90h: Execute Drive Diagnostic
Performs internal diagnostic tests implemented by the drive. Drive 0
sets BUSY within 400 nsec of the receipt of the command.
If Drive 1 is present:
o Both drives execute diagnostics.
o Drive 0 waits up to 5 seconds for Drive 1 to assert PDIAG-
o If Drive 1 does not assert PDIAG-, indicatinf a failure, Drive 0
appends 80h with its own diagnostic status.
o If the host detects a Drive 1 diagnostic failure when reading
Drive 0 status it sets the DRV bit then reads the Drive 1 status.
If Drive 1 is not present:
o Drive 0 reports only its own diagnostic results.
o Drive 0 clears BUSY and generates an interrupt.
If Drive 1 fails diagnostics, Drive 0 appends 80h with its own
diagnostic status and loads that code in the Error Register. If Drive 1
passes its diagnostics or no Drive 1 is present, Drive 0 appends 00h
with its own diagnostic status and loads that in the Error Register.
The Diagnostic Code written to the Error Register is a unique 8 bit
code as listed below.
+------+----------------------------------+
| Code | Description |
+------+----------------------------------+
| 01 | No error detected. |
| 02 | Formatter device error. |
| 03 | Sector buffer error. |
| 04 | ECC circuitry error. |
| 05 | Controller microprocessor error. |
| 8X | Drive 1 failed. |
+------+----------------------------------+
50h: Format Track
The track address is specified in the Sector Count Register. When the
drive accepts this command, it sets the DRQ bit then waits for the host
to fill the sector buffer. When the buffer is full, the drive clears
DRQ, sets BUSY and begins command execution.
ECh: Identify Drive
This command enables the host to receive paramater information from the
drive. When the host issues this command, the drive sets BUSY, stores
the required parameter information in the sector buffer, sets DRQ and
generates an interrupt. The host then reads the information from the
sector buffer. The table below defines the words stored in the buffer.
All reserved fields should be zeros.
+-------+-----------------------------------------------------------------+
| Word | Description |
+-------+-----------------------------------------------------------------+
| 00h | Bit mapped general configuration information. True when bit set |
| | Bit 15: Reserved for non magnetic drives. &nbs
0 -
Does this happen only in IE, or other programs cannot upload too?
Try some of the tests here using different browsers.
I will try this test page. But I can already tell that download is great and upload is nearly zero.
Transmitted (not received) packets are generally much larger and
much more frequent while uploading. I suspect that may be
triggering the symptoms, so it might be a good idea to check the
networking parameters very carefully. That's where a registry
backup might come in handy.
Also, the statistics generated by "netstat -s" might provide
some clue.
Another exciting experiment is to check for the same problem in
a different operating system, or a different W98 install. If that
works well, it's a very likely to be a config issue. Otherwise, the
problem is external to your PC.
Have you tried to restore a backup of the registry ?No. What registry should be backed up regarding the internet?
Surely you know that Win95+ is in the habit of storing all sorts
of stuff in the registry... not just your credit card number and
your mother's maiden name, but also details about hardware
configuration and TCP/IP parameters!
Have you noticed any file change with your VB script ?I would have loved to. But I started writing this script after and indirectly, because I had this problem.
Ideally, one would always have a recent and trusted backup make
comparisons against, or failing that, a collection of MD5 or SHA hashes,,
but as we all know, such items are never there for you when you need
them. So here's a quick&dirty trick I often use instead, and which
usually helps:
C:\>find -ctime -5
... list of files "created" (or at least "changed")
..... within the past 5 days
C:\>find -time -2
... list of files "modified"..."find" is the DJGPP (32-bit DOS) port of the GNU clone of
the essential Unix "find" utility. Get it from any DJGPP mirror
site or from my VAX:
ftp://ftp.narpes.com/pub/util/dos/unix/gnu
Does the other machine use the same physical modem or is it just the same brand and model ?Yes they both use the same physical device: an USB D-Link200. It worked very well before with the same device.
A-ha! That explains it! You're using one of those cheap rubbish USB devices,
mass-produced for the "consumer" market! Try upgrading to a real router from
Cisco, Foundry, or Juniper Networks, and upgrade your Internet connection to
fibre - at least 100 Mbps. Tell us whether the problems persist.
Mostly kidding about that... however, you should verify that it's not the
modem's fault. Try it on a different machine, for instance.
The hardware deficiencies of USB are most probably not responsible for
your upload difficulties... but I can't resist the opportunity for a side note:
a few days ago learned about one more USB "feature": you can connect two
computers with a regular serial cable, a parallel cable, an Ethernet cable, a
Firewire cable or even with a SCSI-cable, but you had better not attempt such a
connection with an USB cable unless you're willing to risk damaging your hardware.
The reason is that "there can be only one" - one host/master/controller/whatever
node - on an USB bus. For connecting two hosts (e.g. two computers), you
need a middle man (or "bridge") to make them get along. (Take a look at this
site for information on not only USB, but many other interfaces too:
http://www.epanorama.net/links/pc_interface.html )
In the case of Windows 98 and USB, theree is a lot to be said, but I'll try
to resist the temptation an just mention NTKERN.VXD. Although it's a genuine
native Win/386/3.x/9x VxD kernel module, the functionality it implements is
alien and poorly debugged - just barely enough NT-emulation to fool USB,
Firewire and other "WDM" drivers to run.
0 -
Your help would be appreciated!
I can no longer open my outlook express. Each time I try, I get one message that refers to memory and something called (0x8007000E)
and another message that says "Outlook Express could not be started because MSOE.DLL could not be initialized. Outlook Express may be intalled incorrectly."
I've deleted Outlook Express and re-installed it twice. I get the same message each time I try to open it.
Any suggestions??
Some other e-mail programs know how to import mail from Outlook.
I think Thunderbird (which may be found at {url]http://www.mozilla.com/
is such a program. If that works, you probably won't need Outlook again.
0 -
if i recall correctly, microsoft sold off xenix to someone else.
That's true. It was transferred to SCO (http://www.sco.com/[/ur])
at some point, and in some shape or form, but that's not the
end of the story. For example, the Run-time Library Reference
for version 8 of the MS C compiler, printed in 1993, still says:
I also seem to recall that SCO had to pay royalties to Microsoft
for a long time, and that there was a legal dispute about it.
Changes in the MS-DOS Unix-compatibility suggests a
distinct shift in company policy at some point between MS-DOS
3.0 and 4.0. For example, the 4.x command line utilities
stopped paying attention to the "switch-char" setting (the
primary purpose of which was/is to allow the use of
Unix-style '/'-separated paths that would otherwise conflict
0 -
L1,L2,L3 caches are managed by the hardware. The software need not intervene.
Regarding size of cache, I have a circa. 1993 80486dx2-66 with 512KB of L2, and that was around before 98se...
But, this may be because of another problem. It's possible that Windows 98 SE assumes that it only has 256 KB of L2 cache, because most Athlon processors have 256 KB of L2 cache. (before "Barton") The Windows 98 SE processor driver may be getting confused. It may not like the fact that the L2 cache is integrated. Most processors at the time Windows 98 SE was released didn't have integrated L2 cache!
Operating systems do not "select" how much cache to
use - they either use all or nothing of it, and disabling
the cache would only be useful for troubleshooting.
The fact that Win98 is so much more compact than XP/2K
should affect performance positively as far as the cache
is concerned, because a larger portion of the system will
fit into it.
There other CPU-related features that affect performance,
of course, such as the Memory-Type Range Registers that
Pentium Pro and newer Intel CPUs support, and that can
be used to select caching strategies for portions of the
address space, as appropriate. I assume AMD processors
have something similar.
For example, enabling maximum read/write caching for the
video memory can greatly enhance performance, because
it allows the CPU schedule accesses to it in whatever order
it finds optimal.
However, using the same caching strategy for self-modifying
code (e.g. JIT compilation) or for data segment that need to
be accessed in the order assumed by the compiler or
programmer, would crash either the application in question,
or whole the system.
The default settings programmed by the BIOS at startup,
or the CPU's power-on defaults, are likely to be selected
with stability and compatibility in mind, and of course, the
settings will remain that way until reprogrammed - and
that's where device-, chipset- or CPU-specific drivers
come in.
For example, the DOS kernel basically regards any CPU as
an 8086, and it requires drivers like HIMEM, QEMM or
386MAX to take advantage of more advanced functionality.
Windows 95 is written to run on a 386 (I've tested).
I think Windows 98 demands a 486 at minimum. However,
the setup program installs more specific drivers where
available.
For example, the VMM32.VXD-archive on my Celeron 400
system includes a module called MTRR.VXD. I imagine that
the absence of such processor-specific support could
adversely affect performance to significant degrees.
0 -
I transformed it into "hosts" format using grep, sed and tr.
Download the .zip from:
0 -
0
-
Heh, I guess it doesn't surprise me that Total Commander would work on Win3.1, I mean, it's basically windows explorer reloaded.
I have heard of that registry tweak, Chozo, to force logon to windows, though because I'm on a fresh windows installation, which still hasn't even frozen yet, I don't really wanna mess around with regedit right now. Perhaps in the future...
Remember Microsoft's free "Win32s" add-on for Windows 3.1?
0 -
Dont people realize that 9x platforms cant even come close to utilizing all of the power of modern platforms?
I think everyone who has used 9x recently on a "modern platform"
has noticed that it was designed for older hardware - either the
system runs surprisingly fast, or drivers for some hardware are
nowhere to be found. Such findings are not unusual for older
systems.
Muli-processor PCs were extremely rare at the time Windows/386 wasBelow is a list of unsupported hardware:Multiple processors
Dual Core processors
designed, and multi-processor support in a kernel has a rather high
cost in terms of complexity and resource consumption. That's why
reasonable MP support wasn't introduced into any of the Linux,
FreeBSD or NetBSD x86 kernels until fairly recently, and can still
be disabled at build-time. An additional reason why MP was never
introduced into the Win/386 series is commercial: MS would rather
have you "upgrade" to NT Workstation (2 CPU) or ideally NT
Server (2+ CPU) or their modern equivalents. (Multi-core x86
CPUs is a kind of multi-processing that postdates even WinMe,
and thus not worth addressing separately.)
Below is a list of software limitations:No file level permissions.
No security policies.
No non admin users at all. Everyone that logs on can do whatever they want to the system.
You are comparing totally different categories of operating systems -
apples and oranges, as they say.
The real-mode, 16-bit protected mode (286+) and 386-enhanced versions
of Windows were designed for single-user systems, and thus all of the
above were not worth the cost of implementation.
The NT project did have multi-user ambitions, and although full
support was present in the kernel, it has always been used in a very
limited manner in practice. (For comparison, a typical use of the
same feature in more serious server operating systems - like VMS or
Unix - is to support multiple users logged in via serial lines or the
network and running interactive commands.)
DOS offers no general purpose multi-tasking, but does provide theDOS WAS a good OS back in the day, but it was not able to domultitasking at all.
concept of separate processes with unique IDs (PIDs) that the DOS
kernel uses to track resource allocations (such as file handles and
memory blocks), which is one prerequisite for multi-tasking. What it
doesn't implement is automatic context switching and time-slicing.
Nevertheless, background processes (device drivers and TSR programs)
have always been common.
And all 98SE is is a front end for DOS, it is NOT a 32 bit OS.386 enhanced versions of Windows have always been more than front-
ends to DOS. They all build upon a modular 32-bit pre-emptive multi-
tasking kernel known as the VMM. The reason why it is often
overlooked is that implementations prior to that of Win95 multi-
tasked virtual machines only, and since all Windows tasks run in
the same VM (every DOS box is a separate one), they didn't benefit
from the VMM's time-slice scheduler.
The Win16 subsystem (KRNL386) wss the provider of the infamous
co-operative multi-tasking - it's a 16-bit protected mode (DPMI)
DOS "shell" that implements the Windows operating environment -
but it's was never the operating system.
Since Win95, the VMM supports multi-threading, and the thread control
block (THCB) has become the primary data structure for multi-tasking.
The Win32 subsystem makes the most extensive use of the facility, to
implement pre-emptive multi-tasking for Win32 apps. Another
mult-tasking improvement of Win95 was separate event queues for each
task.
As to reliance on DOS, it's mostly a matter of whether the right
drivers are installed. If not, Win9x will use BIOS and DOS
services - faced with that situation NT/2K/XP or Linux/ BSD would
fail to boot. Such flexibility make the system much more fault
tolerant, and is the means through which "safe mode" can get the
GUI loaded under conditions far beyond the point where you would
have re-installed NT.
Some may regard the fact that Win9x bootstraps via DOS a weakness,
but it isn't - on the contrary! No other operating system has such
an powerful bootstrap loader - a fully usable operating system in its
own right at little extra cost. Among other benefits, DOS services
allows the VMM to load kernel modules and configuration files from
the file system - and indeed, LKMs was a core feature of the VMM
years before its appearance in more advanced operating systems -
systems that still have to catch up fully.
And as far as security goes how can you get any less secure than 98SE.Anyone can write a small program that can access any portion of memory
that it wants, including the portion used by the kernel. This is not possible
easily in NT+.
Yes, especially the NT series is so obsessed with it's own principles
and integrity that it obstructs even the superuser, and you may have
to write a small device driver to cut through the crap - somewhat
more complex and definitely more prone to hanging the system than a
"regular" program. At times, the same procedure is necessary on the
Unix systems, but under DOS or VMM-based Windows you always have
options, making those platforms ideal for testing special kinds
of software. When they crash, they are up an running again in a
fraction of the time of NT.
No operating system is perfect, complete or appropriate for
all imaginable purposes - not even Win9x or DOS. They do, however,
provide unique features not found in any of the systems suggested
or marketed as "upgrade" paths. That's why they stick around.
Incidentally, those features are oftem more or less exactly the
ones NT fans love to ridicule, perhaps only to divert attention
from the role of the NT series, which seems rather unclear (except
from Microsoft's point of view). Which NT features lack superior
or more cost-effective equivalents (or both) in other operating
systems?
For all uses where high reliability, security and/or multi-user
features are desired, I use (and always have used) one of the open
source Unix-like operating systems.
It seems that almost all great designs are ones characterised by
a common theme of modest (but useful) beginnings, validation
through a long period of incremental improvement, reaching heights
beyond what could be imagined or hoped for in early stages. Unix
is an excellent example - so are the IBM PC, DOS, and both the
"DOS shell" and kernel parts of classic Windows.
"Revolutionary" designs tend to face uphill battles - Intel's
Itanium architecture predated AMD64, only to be quickly surpassed
by it, leaving Intel with no other option but to clone it. NT's
share of the desktop market remained small as long as the more
sensible Windows designs were kept up to date. The history is
full of such examples.
0 -
WIndows 2000 Pro upgrade is only $84.00. Anyone who can afford to upgrade hardware every now, even to just Athlon Xp, Sempron CPUs and only 512MB of RAM, can eaisly afford to upgrade to at least a decent OS.
That goes without saying, considering all the freely
downloadable operating system available today, but
as far as the Windows series is concerned, anyone
who has Win98SE has the crown jewel of the family,
and would hardly find any use for Win2K upgrade.
0 -
Windows 98 SE refuses to load the sound card driver with the error message in the screenshot.
This is with the kX Project Sound Blaster Live drivers and SoundBlaster 5.1 SB0100:
If you're fortunate enough to have one or two ISA slots, just
go to eBay and get an SB-AWE 32 or 64.
Anyway, I suspect the reason for this driver's failure is that it
wasn't really tested on Win98, as you would expect these
days. Microsoft hacked various forms of NT-emulation into
Win9x/Me, but since it's no longer being updated, drivers
that attempt to use unsupported APIs will undoubtedly
become more and more widespread.
0 -
I have tried briefly %windir%\SYSTEM32\DRIVERS\TCPIP.SYS, but didn't notice any improvement, and not sure if I did it right.
The only registry entries I found are under the NetTrans key [example]:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000]
"DriverDesc"="TCP/IP"
"InfSection"="MSTCP.ndi"
"DeviceVxDs"="tcpip.sys,vtdi.386,vip.386,vtcp.386,vdhcp.386,vnbt.386"
"InstallVnbt"="0"
"InfPath"="NETTRANS.INF"
"ProviderName"="Microsoft"
"DevLoader"="*ndis"
"NodeType"="1"
"NTEContextList"="0x00000003"
"DriverDate"="06/08/2000"
"SignedBy"="Microsoft Consumer Windows Publisher"I probably need to use also NETTRANS.INF from WinME, or at least add tcpip.sys entries to Win98 SE NETTRANS.INF.
I'll do this again 1 day, when I find more time.
That doesn't look like a good idea - it appears you're trying to load both
the old VxD-based TCP stack as well as the 2K .SYS file. Multiple protocol
stacks attempting to implement the same protocol suite (TCP/IP) usually
do not co-exist peacefully.
If that is really the way WinMe is configured, then there's another
possibility to consider - the TCPIP.SYS may be merely a "wrapper"
rather than a provider of any real functionality. For comparison,
in Win98SE I found a driver called HIDVKD.SYS loaded by default,
and which turned out to be little or nothing more than a wrapper
around VKD.VXD - I disabled it without any (known) side-effects,
except the memory saved (not much).
In any case, I think *NTKERN is required in the DevLoader list (comma-
separated) in order to load a SYS driver. It may be necessary to list
the SYS file under an "NTMPDriver" entry (rather than DeviceVxDs).
0 -
Why does Microsoft want to completely get rid of Windows 9X based operating systems and pretend they never existed? Why are they ok with previous versions of the Windows NT family like Windows 2000 (NT 5.0) and Windows NT 4.0? But they aren't ok with the previous versions of the different OS heritage in Windows 9X? Why is that?
Commercial and psychological reasons, to begin with
One of those reasons is that Win9x was cheaper, but nevertheless
full-featured enough for most people, which is why Microsoft had
such a difficult time to trick people onto the NT bandwagon... until...
Microsoft cleverly decided to cease further development of the 9x line.
It's much like the termination of MS-DOS as a standalone product,
forcing people to buy the Win9x or move to other vendors' operating
systems, plagued with various degrees of compatibility problems as a
result of MS' anti-competitive business practices.
Another major reason is the greater simplicity of maintaining the
NT series, reducing the cost of adding more bloat to it. More
specifically:
- Out of DOS, Win9x and NT, that last is the only one written almost
entirely in a high-level language - namely C++ - whereas in particular
the kernel and device driver source code of DOS and Win9x consists
primarily of assembly language, the mere mention of which instills
great fear into those unfamiliar with it. - Roughly speaking, DOS and Win9x were developed in response to
market demands, in an incremental and evolutionary manner and with
a great deal of attention to compatibility with existing software (*).
The requirements of existing hardware, software, interfaces, standards,
conventions, etc. inevitably demands far greater care and attention
from software developers than does experimental and "toy" software.
NT was written from scratch guided by the whims of operating system
design enthusiasts and purists. That's why it took such as long time
and so much marketing effort for NT to catch up with reality
Major psychological for Microsoft's desire to go NT-only include (but
aren't limited to):
- All the prestige MS invested into NT.
- The never-ending cheap attacks on MS by the computer
trade press and armchair operating system designers, relating
to keywords such as "16-bit", "DOS", "co-operative multi-tasking" (as
opposed to "pre-emptive" ditto), with the implication that these
terms were inherently negative. They aren't - nor are they inherently
positive - which is impossible to grasp for those who see black and
white only. Nor do these terms have nearly the degree of relevance
implied.
0 - Out of DOS, Win9x and NT, that last is the only one written almost
-
Yes? Give me examples. Any.
Also: you want to say Win9x APIs are emulated in NT? Give me examples.
Read this here/ Read the last sentence in the first paragraph. It says how many system utilities have to be written twice with one specific version for Windows NT and one for Windows 9X.
http://www.noccc.org/bytes/articles/v01/414.html
http://www.nod32.com/download/download.htm
Guess what. It has a native NT version and a native 9X version. I'm sure it uses some OS heritage specific APIs and thus why it has better performance. Pretty much every other AV pplication I have used is a resource hog.
Neither of those examples comment on the supposed NT emulation
of 9x APIs. And for a good reason: although NT includes some half-
hearted attempts at emulating DOS, Win16 and Posix (Unix subset)
APIs, it doesn't even begin to address the issues of supporting any
Win9x kernel mode components, which includes, among other things,
the the file system activity "spy" modules that background virus
scanners depend upon. Hooking and adding time-consuming
overhead to a number of frequently used system calls is one of the
reasons why virus scanners slow the system down.
By contrast, Win95 includes relatively extensive emulation for
NT network and block device drivers - usually so-called Miniports.
Win98 and Me extend that support even farther - *all* of the
USB and Firewire support in those systems is based on emulating
NT/2K kernel APIs.
Apparently, the NTKERN VxD plays the role of NT kernel in
Win98/Me, and if Microsoft had only wanted to, there's no
doubt that even greater degrees of emulation could have been
possible.
0 -
By today's horrendously inflated standards, nothing takesWindows 2000 has been rock stable since SP2. It is a very impressive OS overall. Uses little system resources by today's hardware standards and is still a very good quality OS. Windows XP doesn't take up too many either by today's hardware standards, but it still takes up more than 2000.up a lot of resources.
However, if you've seen what can be done in < 64K on
a Commodore, or when you've experienced games that
were fast enough on a 286 or 386, you know there is no
valid excuse for the resource consumption of 99% of
the software released in the past 10 years or so.
If you could help me figure out why svchost.exe takes up 100+ MB on my PC I'd appreciate it. Stopping services doesn't seem to help.There is more than one svchost.exe process. Are all of them together eating up 100MB+ of system RAM, or just one of them?
I have 5 svhost.exe processes running on my system. One of them takes up about 14MB of RAM. All the others take up about 3-4MB of RAM
Are you sure some of them aren't viruses or spyware?
0 -
I have 98SE on my Dell XPS600r. Whenever I start up, it gives me the option to start in Normal, safe etc. I tried setting up Normal as a default thru. MSCONFIG. No luck. Can any one walk me thru, what I need to do other than reinstalling Windows. Thanks.
Try editing C:\CONFIG.SYS and add a default entry with a time out:
[Menu]
MenuItem=DOS
MenuItem=NetBSD
MenuItem=Linux
MenuDefault=Linux,5
In the above example, the "Linux" option will be chosen in 5 seconds.
0 -
Hey, new here, so I probably sound like a layman, but, got bought a wireless mouse and keyboard for xmas, but they are designed for 2000 or newer. I dont really wanna upgrade my OS cos I'm quite happy with 98 thanks! So is there anyway I can "cheat" and get the new stuff to run on the old OS?
Have you tried just plugging them in? Perhaps Windows detects them and finds
working drivers automatically.
0 -
Has anyone else run up against this issue?
I am running Windows 98SE SP2.1a on a dual boot machine with Windows 2000 SP4.
I recently decided to install MS Office XP (2002) on the system.
When I installed it on Windows 98, it appeared to install correctly, and worked fine, but when I restarted I got the dreaded BSOD "A device required for VFAT is missing or unavailable......system halted."
I could boot into Safe Mode, but not into normal mode.
I installed Office XP on Windows 2000, where needless to say it worked perfectly!
To cut a very long and agonising story short, I discovered that I could boot Windows 98 into normal mode only if I disabled my ethernet adapter first. This is an Intel on-board device which had worked perfectly for 18 months. The same result could be achieved by not loading ndis.vxd on a step by step startup.
The strange thing was that once the system had started normally, the adapter could then be re-enabled and worked perfectly! I had to remember to dis-enable it again before shutdown though.........
I spent weeks trying to resolve this, unloading and reloading network drivers, researching on the web, to no avail.
One thing I had noticed when I looked at backups was that my registry files had become much larger as a result of the Office XP install, and it was this that turned out to be the problem.
If my system.dat file is bigger than about 12.5MB, I cannot boot into normal mode without the VFAT error, unless I disable the network adapter first!
I had uninstalled Office XP (which was the first thing I tried of course) and this made no difference to the problem. It wasn't until I labouriously went through the registry manually deleting all the hundreds of entries that the Office XP uninstaller had left behind, that the size of the registry files went down enough to allow the system to boot normally. Talk about bloat, Ofice XP increased the size of the system.dat file by over 2MB!
It was as if the registry files had become too big to fit in memory at start-up.
I can only assume that disabling the ethernet adapter freed up enough extra memory for the system to start, and the adapter could then be re-enabled as it was then using a different bit of memory, ........or something like that!
It makes sense that omitting NDIS.VXD would have the same effect as disabiling
the network adapter, because practically all Win95+ network hardware drivers
conform to NDIS 3.1 or newer (NDIS = Network Driver Interface Specification),
whereas 3.0 drivers included the functionality later factored out into NDIS.VXD.
NDIS.VXD has a real-mode init portion, and uses the bootstrap loader's
registry access services (more on that below) to decide whether it
should load real-mode (NDIS 2) network device drivers. Perhaps that's
where it fails, and perhaps that leads to the indirect failure of VFAT
and others.
32-bit file access is managed by IFSMGR.VXD, which relies on VFAT for
local FAT file systems, and VREDIR for remote ones. VREDIR probably
expects NDIS.VXD services to be available.
Did you check the c:\boorlog.txt by the way?
The VMM bootstap loader, which is actually the DOS "stub" of VMM32.VXD, providesAll my researches seemed to say that there is no practical limit to the size of the registry in Windows 98, as I believe there was in Windows 95, so I am very puzzled by this.I don't know if free conventional memory is an issue here. I have over 500K free, and 1GB of RAM, with all the necessary tweaks to allow for this, vcache size limit etc. I have a bare minimum of entries in config.sys and autoexec.bat. In fact bypassing these files and system.ini and win.ini on start-up made no difference to the problem.
registry access (and system.ini parsing) services to drivers that load early. These
services are implemented indepentently of their "normal" equivalents, in 16-bit
real mode, and may suffer from limitations that don't normally apply.
The only anomaly I've noticed is that my system reports only 1021MB of RAM present instead of 1023MB.In Safe Mode the full 1023MB is reported.
I can find no reason for this despite researching the MS Knowledge Base and on the web generally.
Safe mode is significantly different from (most) normal configurations - for
example, all swapping/paging is done through DOS, the standard VGA
driver is loaded instead of the normal one, 32-bit network drivers are
left unloaded, etc. Perhaps one of the omitted drivers would normally
"hide" a couple of MB.
0 -
You may want to "compress" your registry.
Export the whole thing to a text file (don't open it, it'll be very large), backup your old Registry files, then boot to pure DOS and use the regedit Create ( /c ) option to create a new set of registry files from it.
I dump the whole registry to text frequently and use
text comparison utilities to track changes. Doing it
before and after an installion and backing out
undesirable additions is an excellent way to keep
the registry size under control.
0 -
(So, now I'm starting to wonder whether or not this whole thing is just another Osama bin Laden propaganda schmozzle (Blah Blah Blah, a bearded mickey mouse is hiding all day crawling in his cave, and "vast watershed moments," and now FBI going 911-code-Red over "Homeland Computer Security" and unfixable 98 vulneratilities, and etc.) is just a smoke screen to shut down all 98 systems ... as they afford their owners too much "ownership" over the dos kernels of their own computers.)
I'm not sure what you mean by "ownership", but it's true that
the DOS kernel is a distinguishing feature of Win9x as compared
to NT/2K/XP.
That"
0 -
With no patch applied, I ran the little 4K vulnerability tester ("wmf_checker_hexblog.exe"), and it came up ... negative vulnerability on my system!!! (as to that test anyway).
NB. when I installed my w98, I did not install the "Paint" program, and apparently this virus uses program calls which are linked with that utterly useless program.
I tried it too, and it also reports No Vulnerability. This is with a stock gdi32.dll, v4.10.1998, 155648 bytes. I do have the "Paint" program installed.
When I try to open the German CT magazine's test WMF with
Paint, it says invalid bitmap or unsupported format.
0
Windows 98 in '08
in Windows 9x/ME
Posted
Indeed. Even Win95 would seem like a recent operating system to me if I weren't constantly reminded by the web (and other media) how ancient it is - if its existence is even acknowledged, that is - many sources seem unaware of anything older than XP.
Only 5? The newer one of my two workstations is from 2000 or -01. The older one is from 1995 or -96, and was originally a 133 MHz Pentium (classic, not MMX), with a 1.2 GB IDE drive, 4x CD-ROM, Opti924 sound and S3 Trio64 video. I think the AT case (minitower) and power supply are the only parts that haven't been upgraded: the current specs include AMD K6-III CPU, 73 GB 10k RPM SCSI disk, SCSI CD-RW, AWE32 sound and Matrox Millennium II graphics, but I still count on further upgrades. Also a very significant upgrade was the replacement of the original Win95 keyboard with a proper one with full-size space bar, Ctrl and Alt keys in place of the irritational typo-introducing windoze keys. It came with Win95, but I went back to DOS 6+Win3.x for a while until I learnt about BootGUI=0. Win95 was then used until long after Win98 was released - until around the time that I found out about 98lite.
By the time that I got the newer workstation (this one that I'm using now), I had learnt some lessons and only minor upgrades have been necessary or even interesting (e.g. from 9GB to 73GB disk, 128 to 512 MB RAM, 400 MHz Celeron to 500 MHz P3). The stupid Nvidia graphics driver (Riva TNT) also forced me to switch to Matrox graphics (G400). Due to the existence of so much poorly written software that runs slowly even on a 500 MHz Pentium3, I may upgrade to a 1.x GHz CPU (in fact, I already have several, but I need a Socket3xx->Slot1 adapter). Of course, this machine also runs Win98 (SE with many fixes and modifications).
The servers run Unix/Linux systems, and are easily accessed over the network from the Win98 machines, which greatly reduces the need to switch the workstations to Unix.
I've had more security incidents (including break-ins resulting in full root compromise) with Linux servers than with Win98 machines. All of the machines included in the comparison have (or had) been permanently on-line for years with no firewalls and with public IP-addresses. Try that with an XP box!
I upgraded because I found that Win9x with BootGUI=0 actually is more DOS-compatible than Win3.x, not to mention more stable and otherwise more capable in many ways. The DOS-compatibility is the main reason why I haven't traded Win9x for Unix/Linux.
It's not necessarily better than Winamp, but I play mp3s on a nearby Linux server and connect its line-out port to the line-in port of the SB-AWE64 card of my Win98 box. This allows me to hear the music as soon as autoexec.bat initialises the sound card, and before booting the GUI.
Yes, it would be great to scrap the old 16-bit GUI (Win16 - that is GDI.EXE, KRNL386.EXE, etc.) in favour of a new one based on the X Window System (as used on Unix/Linux). The VMM/VxD layer (mainly VMM32.VXD which contains most core VxDs) really only needs modest upgrades, but due to the lack of source code and documentation that's a more demanding task than it might seem at first.
There are better alternatives than NTFS - eg. the XFS or ReiserFS of Linux.
Most operating systems used 32-bit file offsets until fairly recently (I think the switch from 16 to 32-bit occurred in the 16-bit Bell Labs Research Unix V.7 in approximately 1979), and large file support took time. The kernel and device drivers were the quick part, while it was a long time until applications were upgraded to support the new (usually 64-bit) APIs.
I don't. I don't own a single DVD, and only received a DVD-player yesterday...
Yes, indeed. I thought they had gone as far as they could possibly dare to with XP, but Vista proves that they believe users (and hardware manufacturers) will tolerate anything, which seems an accurate assumption so far, but I think Windows will start to decline in terms of market share, especially considering that competition is increasing.