(Sorry for the formatting of the response - I use MS Outlook 97 against
Exchange, this mail client is not capable of sensible formatting...)

Just to answer your question; I have done many Windows-installation over
the network, but I do it by loading MS-DOS and dos-clients for the
network. During install I believe that Windows is running the same as
choosing "Safe mode"; this means you are probably right; the difficult
parts are skipped.

It is possible that Win95 eliminates the "well-known-trouble", by
probing for the most troublesome hardware and this way avoids using
these addresses.

The way Win95 eliminates the problem with cards that "dont identify
themselves", is that you may exclude the resources manually. But this
also indicates that there is some way for most cards to identify
themselves for the system (even older special-purpose cards). If this is
not true, Windows must have a very huge database over resources that
might be in use, and how to probe these. 

I remember when I wrote an application for QNX that read a
special-purpose card, the only means for identifying if the card was at
the specified location was to write to a test-register and read back to
see if the value remained; if it didn't the card wasn't present.
believe that card would make trouble for Windows 95. 

As I said I don't normally program at this level, so I wouldn't know,
but isn't there a standard way to query a card for information? As far
as I know, the devices laptops normally have trouble with is various
sound-chipsets and maybe some serial devices (IR and modems); it must be
possible to just probe for these (without a full driver) just to reserve
the resources?

By the way, Windows NT installation starts the network and starts many
other drivers during installation, I believe you also may start PCMCIA
network cards during install. The network is started to make the machine
join the Windows NT domain. So there is some way to make this work in a
general way. For Windows NT the default hardware detection is very
limited, so it definetely doesn't find all odd hardware, but it
certainly installs troublefree on many strange machines.

If the interest is there, I believe I can manage to dig out a document
that describes the "big bang" of Windows NT (also possibly Win95), so we
can find a "right" way to do it in NetBSD.

Regards,

Harald.

BTW! How about porting C-64 Basic as a kernel boot-program language? If
the user can't boot NetBSD, he can take an old C-64 magazine, type in a
game, and be happy anyway!

> -----Original Message-----
> From:	Nathan J. Williams [SMTP:nathanw@MIT.EDU]
> Sent:	11. august 1998 19:17
> To:	Harald Bjoroy
> Cc:	port-i386@netbsd.org
> Subject:	RE: PCIC interrupt selection
> 
> >	There are no mods to the OS for the machine. The only difference
> >is that the licensing pages tells the customer to call the hardware
> >vendor for support, not M$. (Also some preloaded software and
> specific
> >utilitysoftware sometimes, but you can always scrap the machine and
> >install a blank OSR2, infact if you get a CD-ROM with the machine, it
> is
> >a MS-printed OSR2 CD.)
> 
> 	My error; as all the Win95 laptops I've seen come up with
> custom splash screens and custom restore disks, I
> 
> >
> >	There is definately some magic the OS does to boot the devices,
> >and it is embedded in the PNP concept.
> 
> 	[... windows configuration description snipped ...]
> This sounds reasonably similar to what we do.
> 
> >	What NetBSD must do to fix this, is to compile in all drivers it
> >needs to support, add a special driver for the PCMCIA controller
> which
> >finds which cards are in the controller and then activates the
> correct
> >driver based on the ID from the card. How to assign the correct
> >resources I don't know, but I believe there is already code for this
> in
> >the PNP support (?).
> 
> 	This is exactly what our pcmcia code does already. But there are
> two places where we lose:
> 	1) Resources used by devices we don't probe. This includes
> things like sound cards and printer ports, whose drivers we leave out
> of the install kernels due to size constraints. These usually stop
> being a problem once the machine has a non-INSTALL kernel loaded, and
> we could probably deal with them in the INSTALL kernels with some
> agressive combination of "stub" drivers (to find what resources are in
> use, without including the body of the driver code) and keeping track
> of resource information we gather from other sources, such as the ISA
> PnP configuration. 
> 	Can you do an over-the-network install of Windows? If not, it
> suggests that they simply avoided this issue, and that their system
> tries to avoid the problem of ever having devices without drivers for
> them. 
> 	
> 	2) Resources that cannot be used on a particular system. This
> is usually some irq that the system board has reserved for an device
> which isn't always present. If what you say about the genericness of
> Win95 installs is true, then there must be *some* way of dealing with
> them, because it deals with them. Perhaps some
> poking-at-the-interrupts magic that we've tried to avoid using to
> date?
> 	
> 	- Nathan