We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


Automatic hardware detection -HOW?

keldove asked
Medium Priority
Last Modified: 2013-12-16
How do I make an automatic hardware detection? I know I can make a link and
then "start detect.lnk" - but I would like something like: start ?? /autodetect
just like scandisk /autofix....Does anybody know how its called? Regedit? Rundll32?? *.cpl
Watch Question

If you search your registry for detect, you'll find "detfunc=" for all things auto detected. I'm just giving you food for thought here. None of the cpl's that I know of are directly responsible for activating Auto-detect:
The Control Panel Files

Accessibility properties
Add/Remove Programs properties
Display properties
FindFast (come with MS Office for Win95)
Internet properties
Regional Settings properties
Joystick properties
Mouse properties
Microsoft Exchange Service properties
Multimedia properties
Modem properties
Network properties
Data Sources (32-bit ODBC)
Password properties
System properties
Desktop Themes (available with Microsoft
Date/Time properties
Overview: In Windows 95 system.
IO.SYS is a well integrated startup file. It totally controls the default process of system boot. In another word, it has contained the functionality of old IO.SYS, MSDOS.SYS and CONFIG.SYS used in previous DOS system.
Description: When the power is on, what happens?

Before IO.SYS, let's see how system boot really. First, there is a ROM BIOS. ROM reserves the info that you specified in BIOS setup. We will look at a small program named bootstrap loader inside ROM BIOS. From the time when the computer is turned on, series of actions start from this bootstrap loader. Please see the following...

bootstrap loader -> POST (Power on Self Test)
-> load interrupt vector table  
-> search boot sector -> data table reports HD info
-> small program gets loaded -> program loads IO.SYS

As shown in the above diagram, bootstrap loader will first load an interrupt vector table (contains addresses used by CPU for hardware and software interrupts) into the lowest 1k bytes in the memory. And second, this program will look for the boot record that resides at the very first sector (boot sector) on the hard disk or floppy. We will divide boot sector into two parts.
The first part contains a data table which will report the info of your hard disk to the system.

above is XMS
Above 1024

(not available yet)  

Video ROM  

Above 640 KB        
Free Conventional

Device Drivers  

12+ KB
5 KB
System I/O & 
Software I/O
2 KB
Interrupt Vector Table
1 KB

During the implementation of the second part, another small program inside boot record will get loaded by bootstrap loader. This small program will load IO.SYS and leave the rest to it.  
In turn of IO.SYS, three things will happen.  

1st. IO.SYS builds up a bridge between hardware pieces and operating system. In another words, it adds additions to hardware BIOS and draws a basic routine between hard wares and the operating system.
The result is once again placed right above interrupt vector table in the

Second, IO.SYS plots a table of vectors for DOS services calls. This is the part that we call DOS kernel.  It MSDOS, though this can not be confused with MSDOS.SYS. In Windows 95, the similar function is provided by USER, GDI and KERNEL. Future version will have more discussion on that.  

The third and the last, IO.SYS starts loading device drivers. We will begin with the
non-existence of startup files; which consider MSDOS.SYS, CONFIG.SYS and
AUTOEXEC.BAT as a whole. In default, IO.SYS will implement a bunch of drivers. It then
loads default drivers and part of itself into memory. Henceforth the tricky part arrives.
Please continue to the next section.

Default Drivers:
We must first understand what these default drivers are.
First there are HIMEM.SYS and IFSHLP.SYS; which are essential for running Windows 95 in normal mode. Then there are BUFFERS, FILES, FCBS, LASTDRIVE (default
is "Z"), STACKS and some other harddisk related devices; most of which are non-essential to Windows 95 system, but IO.SYS will give them some default values and load them
just in case that old DOS programs still acquire them. At last, there are SETVER, DblSpace and DrvSpace. These three are optional based on their exclusive purposes. (Setver
is useless in today's applications.) All in all, the drivers have to be found at their default Windows path in order to get loaded. (Nothing can be done to disable buffers.)  

It is obvious that this very same stage was taken care of by CONFIG.SYS in previous DOS machines. There are two differences, however. One is that IO.SYS have all the authorities in giving default values as well as loading drivers without permission. And another difference is that IO.SYS does not control the loading of EMM386.EXE, which is to manage expanded memory if asked and to scan available UMA.
Device Drivers, fcbs, stacks, other device drivers... etc.  
DrvSpace.sys, FSHLP.SYS, Himem.sys

It's only a representation of what actual case might be.

The Final Stage:

By far, we have concluded what role IO.SYS is playing in our system boot scenario. By default,
IO.SYS does not load EMM386; in another word UMA has not been utilized to the system.
IO.SYS will place all system data into precious 640 Kb conventional memory. On the other hand, Windows 95 can be booted from 420 KB conventional memory, and the memory utilization in Windows 95 is a totally different story. As a result, one single IO.SYS as a startup file will keep most Windows 95 users happy already.  

However, 640 KB has never been good enough for a memory aware end-user, and it definitely never will be.  With a carefully written startup file, one can optimize as much conventional memory for use with Windows 95 or DOS based games and programs. (The initialization of a VM session is based on the boot state of low memory.) For another hard-coded fact, conventional memory is still the most valuable RAM on the system.  

There are still many factors to look into in regarding to startup processes. Also IO.SYS has not stoped here either. Readers with interests can click on the link Startup Files and go ahead.

I don't know the answer yet but I'll stay with it, maybe between us we can figure this out. Give me feedback.
Do you want something like a doo batch file to do this?
The answer to emulating Hardware Wizard is that you cannot.
Running the Hardware Wizard is another matter. It is easy to do this in an application by using the WinExec() function to run the following line:
   control.exe sysdm.cpl,Add New Hardware
If you try using start to run the above line you'll get no result. but you can run only control.exe.

biyiadeniran, sysdm.cpl is applicable for System Properties.
I don't understand your answer.


control.exe sysdm.cpl,Add New Hardware
Give excactly the same as creating a link from "add new hardware" to the desktop, lets call it detect
and running: start detect.lnk

What I want is a trigger that passes those press button (next)(next)(next). -I want AUTODETECT (no questions to the user please)


I have seen it done on preloads from HP (NT 4.0)
I really would like the hardware detection to run
without expecting input from user.

I finally put 150 points on the line...

Have you tried any of these apps that emulate keypresses for you? Something like Buzzof?


Allen: Do you wan this to occur during a windows 95 install or on an existing system to which new hardware is being added?

Next, is this computer on a network of any kind?

If this is a stand-alone system (non-network) how do you propose to install drivers for the hardware without some sort of user intervention?

Will wait for your post!

Best regards,


1) Yes, its a preload.
2) Yes, but only inorder to get the preload.
3) 90 % of the PC's hardware is included in the Windows 95
    installation. (I have got 400 PC to upgrade.) The rest of the     users I'll manage thru a guide to a driver directory. (superusers
Best regards,


Erh, I forget....
It would be nice if it could be runned from within the registry:
RunOnce - This seems to run first after the prompt for login.
(holding other applications back!)
Best Regards,

You can do this in one of two ways, but both have drawbacks to be considered.

The first would use a push install, eg: you setup a mirror of the install on one machine with all of the drivers, and then copy or move that entire install into a directory on your admin server. You then mirror or download the entire install to the workstation over the network. When the user logs on, the install will complete itself. The drawback here is that each workstation, except for some minor differences, would have to be nearly identical in hardware configuration.

The second would be to create an inf file similar to that which accompanies the OEM versions of OSR2. This will enable you to create the alternate statements necessary to accomodate hardware differences by including " <if> then " statements. The drawback here is if there is a large disparity between work stations as to hardware, the inf file would be a monster.

Let me know the approximate make up or differences between the work stations and we'll try and go further with this.

Won't a Batch.inf do it? That's what they are for.


You dont understand, perhaps I should explain the situation.
I want the installation to be a plain (x)copy! (many years of pessimism gave me that goal:))
1) I have made the preload on a *very* simple PC.
2) I give away a bootdisk
3) The users uses the bootdisk, and it formats the disk
4) Then it connects to a common share and xcopies the source
5) This includes the cabinet files.
6) They boot and NOW: I want a hardware detection
    after the hardware detection they reboot and win95
    automaticly installs "new hardware"!!

I want to add that in the current version, win95 starts the hardware detection, when it notices that no display adapter,
has been defined, BUT its a lot later than the RunOnce could have started it this  AND the user has to make a choice.
Best Regards,

Great Keldove!  This will do it for you, OEM's (us included) use this all the time for new installs or reinstalling.

Forget about xcopy, as it does not work properly. You can do exactly what you want using OSR2 along with the OEM install inf batch setup file. You can use the "Pre-installation wizard" on your system to create the inf batch file and push the basic install to the workstation. The user starts the system and the inf runs the install completely. When sending the install, all you need to do is send the various inf files with it for the hardware and include the calls for the hardware setup right in your wizard inf.    
There are three tools available that you can use, the "Batch Setup Tool", the INF Generator Tool" and the INF Installer Tool", all of which are available on the MS free software download site.

The latest version of these are on two floppies that come with the OEM version of OSR2 (but make sure your supplier knows that you want the OEM installer tools on diskette)

Here's how it works!
1. Setup the inf generator on your server station.

2. Setup a location for the Windows 95 files, you can either do this from the OSR2 cd rom disk in the server cd rom drive or by copying the cd rom's content to a directory on the server  (preferred).

3. Develop the inf files you will need to have on the workstations where WIN95 will be installed. On the server where the WIN95 cabs reside, add another directory for these inf files.

4. Create a master inf file with the inf generator that sets up the hardware during the install. The explanation as to how to do this comes with the program, however the disk with the OEM version has examples that come with it.

5. Once you done the above, create the Batch setup that does the format, system transfer, loads win95 and sets up the hardware.

6. Once the user boots, the run once will occur requiring sign on and final setup.

If you need more, let me know!

Hope you don't mind me stealing this answer Dew.


Not at all Bud!


Is it possible to run an inf file from RunOnce, starting autodetection? eg. c:\Win95\setup detect.inf

Is it possible to define FAT16 via inf files?
Im using 400.950a

dew_associates give be a "yes" and a hint on the detect.inf
part and I'll give you 150 points
Keldove: In answer to your last question, "Is it possible", yes but not the way your approaching it. I'll do it your way, but it's like going from NY City to Brooklyn via Arizona. Anyway......

The syntax would be   ?:\win95\setup /p c- d=detectpic

You would then need to create a modified file called Msdet.inf and place it on the server directory where WIN95 resides, replacing the one that comes with WIN95. Since your using the retail version of WIN95 you will also have to create an inf file that adds the cd rom key.

As for defining FAT 16, you have no choice with the retail version of windows 95, which is 950 or 950a.

Best regards,

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Keldove, If I had known you were going to grade the answer with a "D", I would have let you figure it out yourself!!


Well that was the problem, I already knew that answer!
but thanks anyway (you kinda verified it thou) -thought your effort should be graded thou.
Best regards,
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.