keldove
asked on
Automatic hardware detection -HOW?
Hi,
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
?
Regards,
Allan
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
?
Regards,
Allan
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.
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.
I don't understand your answer.
ASKER
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)
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)
ASKER
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...
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,
Dennis
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,
Dennis
ASKER
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
involved)
Best regards,
Allan
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
involved)
Best regards,
Allan
ASKER
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,
Allan
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,
Allan
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.
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.
ASKER
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,
Allan
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,
Allan
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!
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!
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Keldove, If I had known you were going to grade the answer with a "D", I would have let you figure it out yourself!!
ASKER
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,
allan
but thanks anyway (you kinda verified it thou) -thought your effort should be graded thou.
Best regards,
allan
------LIST
The Control Panel Files
Access.cpl
Accessibility properties
Appwiz.cpl
Add/Remove Programs properties
Desk.cpl
Display properties
FindFast.cpl
FindFast (come with MS Office for Win95)
Inetcpl.cpl
Internet properties
Intl.cpl
Regional Settings properties
Joy.cpl
Joystick properties
Main.cpl
Mouse properties
Mlcfg32.cpl
Microsoft Exchange Service properties
Mmsys.cpl
Multimedia properties
Modem.cpl
Modem properties
Netcpl.cpl
Network properties
Odbccp32.cpl
Data Sources (32-bit ODBC)
Password.cpl
Password properties
Sysdm.cpl
System properties
Themes.cpl
Desktop Themes (available with Microsoft
Plus!)
TimeDate.cpl
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.
--------------
BOOTSTRAP:
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
KB
BIOS ROM
|
Usable
UMA
(not available yet)
Upper
Memory
Area
|
Video ROM
Above 640 KB
Free Conventional
Memory
Conventional
Memory
Area
|
Device Drivers
12+ KB
MSDOS
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
memory.
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?