 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 95 / December 2003getting "error loading PROGMAN.EXE" during OSR2b setup
I have been trying to install a fresh copy of OSR2B on an old IBM 486/33 with 8meg, 210Meg HD. Fdisk'd and formatted with DOS 6.22 (I've also tried DOS 7 and DR-DOS -- same error). After running Setup.exe, the scandisk does it's thing, then I get the above error. I haven't found any win95 specific help on this error message, though other OS's refer to issues with DriveSpace'd drives. I'm doing a low-level format to make sure the drive is absolutely clean before I try it again, but I'm wondering if anybody here has any other suggestions. Use the Windows 95 boot diskette to format your hard drive as FAT16 (with LFN support) If you ca'nt get pas t the problem, try copying the setup files to a folder on the hard drive and running setup from there. >-----Original Message----- >I have been trying to install a fresh copy of OSR2B on an old IBM 486/33 [quoted text clipped - 8 lines] > >. Did both already... I've done nearly 5000 installs of 95 in all sorts of different conditions (I worked for a major call center company for years) and this is the 1st time I've seen this. > Use the Windows 95 boot diskette to format your hard drive > as FAT16 (with LFN support) [quoted text clipped - 21 lines] > > > >. Try running setup with the "/c" switch. setup /c Ben > I have been trying to install a fresh copy of OSR2B on an old IBM 486/33 > with 8meg, 210Meg HD. Fdisk'd and formatted with DOS 6.22 (I've also tried [quoted text clipped - 5 lines] > to make sure the drive is absolutely clean before I try it again, but I'm > wondering if anybody here has any other suggestions. Tried that too... even went so far as running setup /C /is /im Try running setup with the "/c" switch. setup /c Ben > I have been trying to install a fresh copy of OSR2B on an old IBM 486/33 > with 8meg, 210Meg HD. Fdisk'd and formatted with DOS 6.22 (I've also tried [quoted text clipped - 5 lines] > to make sure the drive is absolutely clean before I try it again, but I'm > wondering if anybody here has any other suggestions. The boot drive may have a drive overlay program installed. If you are starting the computer with a boot floppy, you will have to remove the overlay program or start the computer in a manner consistent with it. Most overlay programs display a screen at bootup with floppy boot instructions. Ben > Tried that too... even went so far as running setup /C /is /im > [quoted text clipped - 17 lines] > > to make sure the drive is absolutely clean before I try it again, but I'm > > wondering if anybody here has any other suggestions. I thought of that, too... when I low-level formatted the drive, that should have taken care of that. Anyhow, it's just a Maxtor 2120 (210Meg) drive -- should be no need for an overlay unless it's something the IBM BIOS drops in without me knowing it. The boot drive may have a drive overlay program installed. If you are starting the computer with a boot floppy, you will have to remove the overlay program or start the computer in a manner consistent with it. Most overlay programs display a screen at bootup with floppy boot instructions. Ben > Tried that too... even went so far as running setup /C /is /im > [quoted text clipped - 19 lines] > > to make sure the drive is absolutely clean before I try it again, but I'm > > wondering if anybody here has any other suggestions. On Sun, 14 Dec 2003 13:48:31 -0700, "Gerry Voras" >I thought of that, too... when I low-level formatted the drive, What method? Given that xIDE HDs don't low-level format, and OS-level format is contained entirelky within the volume, excluding the MBR in which the DDO (or MBR virus or boot manager) would reside. >have taken care of that. Anyhow, it's just a Maxtor 2120 (210Meg) drive -- >should be no need for an overlay True - DDOs were used for 500M and 8G barriers, and don't help with the 32G barrier that usually bites at BIOS IDE detection. Doesn't mean a truly moronic HD vendor wouldn't ram it in as a "value add". >unless it's something the IBM BIOS drops in without me knowing it. Unlikely++ >> "Gerry Voras" <gerry.voras@nextaction.com> wrote in message >> > I have been trying to install a fresh copy of OSR2B on an old IBM 486/33 >> > with 8meg, 210Meg HD. Fdisk'd and formatted with DOS 6.22 (I've also >> > tried DOS 7 and DR-DOS -- same error). OK >> After running Setup.exe, the scandisk does it's thing, ...that's DOS mode... >> then I get the above error. Odd; I can't think what Setup would be doing with ProgMan.exe (Program Manager). Standard-mode Win16 (Mini-Windows) yes; GrpCnvrt to spawn the Startup Manu yes, but I'd not have expected ProgMan itself to run. Only thing I can think of that might specifically and reproduceably do this would be a bad instllation CD, such that the ProgMan.exe on it is barfed in such a way that Scandisk cares - which would be expected to block the ability to copy the file, rather than carry over the oddness Formal malware scan done yet? >------------ ----- --- -- - - - - Things should be made as simple as possible, but no simpler - attrib. Albert Einstein >------------ ----- --- -- - - - - Maxtor has a free LLF utility that we use to kill drives that are being reluctant for whatever reason. You're not supposed to do it in most situations, but... > On Sun, 14 Dec 2003 13:48:31 -0700, "Gerry Voras" > [quoted text clipped - 44 lines] > but no simpler - attrib. Albert Einstein > >------------ ----- --- -- - - - - On Mon, 15 Dec 2003 15:42:07 -0700, "Gerry Voras" >Maxtor has a free LLF utility that we use to kill drives that are being >reluctant for whatever reason. You're not supposed to do it in most >situations, but... I think of HD as a three-dimensional box, viewed lying on its side: - heads (physically determined) - tracks (found by reading disk) - sectors on a track (found by reading disk) One may think in terms of head, track, linear (sector) but because it's so slow to change tracks, the HD treats all disk surfaces at the same track as a logical "cylinder" entity (that's what I meant by "viewed lying on its side"). So H,T,L becomes CHS. There's nothing outside of a clean room that will re-do the embedded disk data that is used to locate tracks, and never has been - prior to voice-actuated track positioning, head positioning was done by phyically clanking a stepper-motor "blind" (so that as the disk expands when hot, the heads no longer center the track properly). However, there was a time (and may still be a time, for SCSI drives?) when one could re-do the on-disk information that showed where each physical sector starts. That was the Low Level Format process, and that's what the old legacy BIOS format calls purport to do. Today, that sector preamble and ID info is laid down in the factory, and some of it may be stored in NVRAM off the disk (to reduce the capacity lost to sector ID info) and the BIOS LLF calls no longer re-do it. The HD's firmware may fake it and return an OK, or it may fill the data space with a value, or it may regenerate the checksum info as part of a "long sector" write. What it is unlikely to do is re-create the actual preamble and start mark, sector ID etc. For the purposes of killing malware and other non-standard pre-OS boot code, it's enough to just fill the data area of each sector with nulls, or some arbitrary character (the "divide by" char is popular for some reason, prolly related to its bit pattern). So I presume this is what your LLF did? Context: >"cquirke (MVP Win9x)" wrote >> On Sun, 14 Dec 2003 13:48:31 -0700, "Gerry Voras" >> >I thought of that, too... when I low-level formatted the drive, >> What method? >------------ ----- ---- --- -- - - - - The most accurate diagnostic instrument in medicine is the Retrospectoscope >------------ ----- ---- --- -- - - - - OK, the theory on IDE LLF is basically write random 1's and 0' to every spot on a hard drive -- all platters, tracks, and sectors. It does nothing to rewrite tracks, precopys, LZs, etc. The problem with any LLF is that in the process it wipes out the bad sector list -- an inherently bad thing to do to any Winchester derivative drive. However, I do it whenever the alternative to to throw away the drive. Anyhow, I solved the original problem. It turns out, after some further research, that a couple of the install INF files have pre-programmed cab and device locations in them, including for PROGMAN.EXE. It turns out that the SETUP.EXE file, when reading the INF files, will have problems if the cab source and the install destination are the same logical device. I've never run into this problem before, but apparently shows up on non-AT designs most frequently. Anyhow, the easy way was to copy the cabs onto a logical drive (40 megs, called D:) and install to C: from there. Alternatively, load from a CD drive, network share, or across Interlnk. The assignment I gave my admin class (I teach at a tech school) was to figure out a way to load WIn95 without a CD or NIC. Most teams opted to install over null-modem, but a couple of teams recommended copying over null-modem, then installing locally -- to gain a speed advantage of sorts (I think they'll discover that they really don't get one). Either way would/should have worked, except for the bogus hardware I gave out was a proprietary IBM PS/Valuepoint instead of a standard AT-based 486. Testing on a "regular" 486 did not generate the PROGMAN.EXE issue. Thanks for the help, folks! > On Mon, 15 Dec 2003 15:42:07 -0700, "Gerry Voras" > [quoted text clipped - 49 lines] > in medicine is the Retrospectoscope > >------------ ----- ---- --- -- - - - - On Wed, 17 Dec 2003 20:10:45 -0700, "Gerry Voras" >OK, the theory on IDE LLF is basically write random 1's and 0' to every spot >on a hard drive -- all platters, tracks, and sectors. It does nothing to >rewrite tracks, precopys, LZs, etc. OK, that's pretty much what I'd expect today. When the first IDE HDs were warmed-over MFMs without zones ofdifferent sectors per track, there were reports that BIOS LLF could upset optimized interleave or sector positioning so that the HD would slow down, and later that some 80M drives would lose capacity too (loss of denser zones?) Some sources claim CRC info outside the sectordata area is renewed, either as a self-managed side-effect of changing the contents, or explicitly. I don't know enough to comment on that. >The problem with any LLF is that in the process it wipes out the bad sector >list -- an inherently bad thing to do to any Winchester derivative drive. I doubt if it will re-init the HD's own internal list, though I'd expect it to clear all OS-level bad cluster listings (given the file system's blown away; FDisk would do the same). If the OS lists bad sectors, it's time to sunset the HD anyway, IMO. >However, I do it whenever the alternative to to throw away the drive. I'm using Spinrite under such circumstances. >Anyhow, I solved the original problem. It turns out, after some further >research, that a couple of the install INF files have pre-programmed cab and >device locations in them, including for PROGMAN.EXE. It turns out that the >SETUP.EXE file, when reading the INF files, will have problems if the cab >source and the install destination are the same logical device. I've never >run into this problem before Me neither! >... but apparently shows up on non-AT designs most frequently. Maybe confusion between what BIOS sees as the boot drive (C:) and what PnP thinks is the first HD device, which could be affected by CMOS boot order. Thinking 1 x IDE + 1 x SCSI, and another thread where it is claimed that an F-Prot boot fixer copied a backed-up boot record to the wrong HD. Thinking; build with IDE as C:, add SCSI card and HD, set CMOS to boot off SCSI before IDE, etc. >Anyhow, the easy way was to copy the cabs onto a logical drive >(40 megs, called D:) and install to C: from there. That's what I always do. >Alternatively, load from a CD drive, network share, or across Interlnk. That I'd be far less likely to do. >The assignment I gave my admin class (I teach at a tech school) was to >figure out a way to load WIn95 without a CD or NIC. Most teams opted to >install over null-modem, but a couple of teams recommended copying over >null-modem, then installing locally -- to gain a speed advantage of sorts (I >think they'll discover that they really don't get one). They may or may not, if all goes well. But if glitches arise, or access to the linkage vanishes after restarts during the process that causes further copies from source to fail, then they would be way ahead of the pack - they'd know whether the problem lay in accessing the source, or in the mechanations of Setup.exe itself. >...the bogus hardware I gave out was a proprietary IBM PS/Valuepoint >instead of a standard AT-based 486. That's a cruel trick :-) Did you invite them to add some RAM to speed things up, leaving them to figure "must have parity" followed by "must be 'special' proprietary RAM"? That bit me with an old Valuepoint - grrr >Testing on a "regular" 486 did not generate the PROGMAN.EXE issue. So it prolly works on PCs, and IBM's are just not compatible enough! >------------ ----- --- -- - - - - Things should be made as simple as possible, but no simpler - attrib. Albert Einstein >------------ ----- --- -- - - - - |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.