Jump to content

somewan

Member
  • Posts

    73
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Finland

Everything posted by somewan

  1. 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.
  2. 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... 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. 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.
  3. 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! 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).
  4. 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.
  5. 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 Controller technical manual 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
  6. 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. 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! 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 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.
  7. 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.
  8. 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: Microsoft, MS, MS-DOS, XENIX, and QuickC are registered trademarks and Windows, etc... are trademarks of Microsoft Corporation in the USA and other countries. 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 with the use of '/' as a command-line option character).
  9. 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.
  10. I transformed it into "hosts" format using grep, sed and tr. Download the .zip from: ftp://vax.4np.net/out/tmp/
  11. No, not Win9x, and not MS-DOS - a not even OS/2. Refresh your memory... So, does anyone know more?
  12. Remember Microsoft's free "Win32s" add-on for Windows 3.1?
  13. 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 wasdesigned, 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.) 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 theconcept 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. 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. 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.
  14. 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.
  15. 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.
  16. 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).
  17. 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.
  18. 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.
  19. By today's horrendously inflated standards, nothing takesup 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. 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?
  20. 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.
  21. Have you tried just plugging them in? Perhaps Windows detects them and finds working drivers automatically.
  22. 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, providesregistry 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. 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.
  23. 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.
  24. 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"
  25. 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.
×
×
  • Create New...