Move on to W2K
UZnal
"The Windows 2000 DDK can be installed on the Windows 98 Gold and Windows 98
SE versions of the Windows operating system. Once installed, the DVD samples
can be built and run on Windows 98 Gold and Windows SE as is. In other
words, Windows 2000 DDK contains updated DVD development documentation that
applies to all three operating systems: Windows 98 Gold, Windows 98 SE, and
Windows 2000."
Now that we know what made SPOCK206 to tick again, why shouldn't Windows
2000 install on MCA + Pentium? What are the symptoms?
David L. Beem
> WDM DVD Drivers...
Natively WDM is on ME & XP, although as you say here at least an add-on
portion for W2K works fine on 98SE. Microsoft is not in the habit of saying
(usually very contrary to it in fact) whether newer MS components will run
on older systems. But the video aspects may demand a greater GPU than MCA is
able to support.
David
Da...@IBMMuseum.com
William R. Walsh
> Now that we know what made SPOCK206 to tick again, why shouldn't Windows
> 2000 install on MCA + Pentium? What are the symptoms?
There don't appear to be any drivers for XGA, IBM MCA SCSI and some other
popular MCA hardware.
There also doesn't appear to be an MCA HAL for Windows 2000. Microsoft said
they dropped support for the MCA bus in Windows 2000. People who have tried
the setup routine say that it crashes when it gets to examining hardware.
I find Microsoft's decision odd...there exist more than a few combination
bus machines that exceed the minimum requirements for Windows 2000. The PC
Server 720 would be one such machine.
William
William R. Walsh
> Natively WDM is on ME & XP,
Windows 98(se) is said to have support for WDM drivers. This is allegedly
why many USB devices don't work under Win95 even when you do enable or add
USB support...Win95 doesn't have WDM support.
> But the video aspects may demand a greater GPU than MCA is
> able to support.
Windows 2000 doesn't seem to expect too much from the video subsystem. Its
video requirements seem to be in line with those of Win98(se) and NT. I've
run it with low end Cirrus video cards and had usable results. It is
interesting to note, however, that Microsoft didn't bother fixing the "only
1MB of VRAM is seen on early Cirrus video boards" bug.
William
UZnal
I pasted the text from the 98-DDK. M$ recommends the W2K DDK for DVD support
on W98SE, obviously there is some overlap there. Seeing a Pentium CPU, W98SE
rejects MCA-related settings in a [SCSI miniport] driver, but you have
neither such a setting nor need one in a display driver. I am almost sure -
'almost' because it needs a proof - that Spock206 will work on W2K if given
a chance. Smooth DVD could be possible in a smaller window, XGA-2 is fast.
See the emerging pattern there, devised to kill MCA at the Pentium level.
UZnal
> popular MCA hardware.
> There also doesn't appear to be an MCA HAL for Windows 2000.
MCA support could be borrowed/imported from NT4.
> they dropped support for the MCA bus in Windows 2000. People who have
tried
> the setup routine say that it crashes when it gets to examining hardware.
Setup proceeds over INF files and a few DLLs. It shouldn't be impossible to
adapt the NT4 setup set to work with the W2K files.
Daniel Hamilton
I disagree with this. You're missing something very important: A NT
HAL that supports MCA *AND* WDM. WDM in 98 is provided by a stub of the
NT kernel that was being developed for NT 5.0. It's only a stub though.
I think MCA support was declared DOA for later NTs. That would
explain also why MCA support in Windows 98 was so lack-luster. The NT
HAL was seriously refactored in NT 5.x to add support for WDM, ACPI,
among other things. Remember this is when Microsoft also decided to
stop supporting 2 of the 4 platforms that NT 4.0 runs on: MIPS and PPC.
They dropped Alpha support after Service Pack 2 of 2000. Trying to
shoe-horn a NT 4.0 kernel into NT 5.x will not work. I was using 2000
when it first came out, and the nastiest part was dealing with the lack
of drivers-- because NT 4.0 drivers didn't work anymore, except maybe
for Modems. Everything that worked too intimately with NT 4.0 would
break. :\
--Daniel
William R. Walsh
> I disagree with this. You're missing something very important: A NT
> HAL that supports MCA *AND* WDM.
The HAL is a DLL, and if UZ can adapt one...anything is possible.
I'd be willing to test anything.
> Remember this is when Microsoft also decided to
> stop supporting 2 of the 4 platforms that NT 4.0 runs on: MIPS and PPC.
They stopped support for MIPS RISC much sooner than the release of Windows
2000 FAIK. I'm not sure MIPS RISC machines saw any service packs...
(It's funny that this would come up...I was looking through a 1996-era
magazine the other day and saw an NEC advertisement for a MIPS based server.
NEC was doing a pretty commendable selling job for the machine in question.
If I would have bought one, however, I'd have felt quite bad about that
particular decision. Perhaps another OS would run on it today...?)
I have actually seen an RS/6000 running the PPC version of NT. I never got
to work with it...
> They dropped Alpha support after Service Pack 2 of 2000.
What version of Win2k supports the Alpha CPU? My "gold" Windows 2000 Pro
(SP0) disc has only an i386 folder on it.
While Windows 2000 seems to be a *solid* version of Windows, a PS/2 running
NT4 does quite nicely. The only thing that really gets old is having to
re-apply the service pack after changing the system configuration. (As far
as I'm concerned, WinXP lowered the bar in the Windows world, and I
generally refuse to run it. In light of this, I've purchased an awful lot of
licenses for Windows 2000 Pro.)
William
UZnal
to
> > adapt the NT4 setup set to work with the W2K files.
>
> I disagree with this. You're missing something very important: A NT
> HAL that supports MCA *AND* WDM.
I don't think the MCA HAL has much to do with the WDM (Windows Driver
Model). The MCA layer is a specialisation of the general machine model for a
platform-specific support, like slot/adapter queries, IRQ and DMA specifics.
W98SE does without an MCA VXD but contains an EISA VXD. However, MCA DMA and
IRQ are handled in other W98SE components.
For the driver model, examining the predecessor, NT, is helpful, it contains
only a few
MCA specific calls "...'NdisReadMcaPosInformation' for a bus-relative
configuration information for a NIC on an MCA bus .... 'HalGetBusData' to
get hardware configuration information, particularly for devices on EISA,
MCA, or PCI buses."
The main question is how to integrate the NT4 MCA HAL in W2K.
> Trying to shoe-horn a NT 4.0 kernel into NT 5.x will not work.
No, not the kernel, it is only about playing with the NT4 setup procedure.
The NT4 INF files are scripts, bus specific details (e.g. EISA, MCA) are
handled there. Below is an edited fragment from UTILITY.INF:
[MCAFindBus]
ifint *($(CardInfo), $(NextByte)) == $($1)
LibraryProcedure RealBusNum, $(!LIBHANDLE), GetMCABusInformation,
$(KeyBus), "Configuration Data", $(BusNum)
set-mul mcaid = $($1), 256
set-add mcaid = $(mcaid), $($0)
set InfoList = >($(InfoList),{$(BusNum),$(SlotNum),$(mcaid)})
endif
Take that section out of the INF file and you will have no MCA bus. Further
MCA specifics are in SCSI.INF (miniports) and NETOEMDH.INF (network), but
again just as far to detect and read the card ID, and that is all about it.
It would be worth trying to see the effect of added MCA sections in the W2K
setup, but one one will need some help from the NT4 setup routines resp.
DLLs.
brad.p...@gmail.com
I believe you need to find a copy of the embedded windows ce
development kit for version 3.x, which I think corresponds to W2K.
IIRC somebody told me that a knowledgeable person could build an entire
release of windows with it.
The kit includes libs and souce for many platforms including x86 and
the MCA HAL.
Seems to me that if the build was for x86 and with the MCA HAL, one
might even be able to run regular win32 apps.
At the least it may have some useful stuff in it. I gave a copy to
someone years ago, maybe he still has it.
Someone wake me up if I'm dreaming...
Brad
UZnal
> development kit for version 3.x, which I think corresponds to W2K.
The Windows CE API and DDK are documented in the MSDN Lib April 2001, so I
can have some preliminary info. It looks easy, actually.
> IIRC somebody told me that a knowledgeable person could build an entire
> release of windows with it.
With some limitations, application memory space is 32 MB, files are also 32
MB. But it has a Web server, web explorer, mail, networking and some more.
> The kit includes libs and souce for many platforms including x86 and
> the MCA HAL.
That is interesting. But why MCA HAL for a mobile device? Perhaps as an
example?
> Seems to me that if the build was for x86 and with the MCA HAL, one
> might even be able to run regular win32 apps.
"Windows CE supports a subset of the Win32 API set. Some Win32 functions are
not supported at all and no 16-bit Windows functions are supported...."
But that was 3.0, the specs must have changed.
> Someone wake me up if I'm dreaming...
We are on a lonely detached planet, a new toy story ...?
brad.p...@gmail.com
UZnal wrote:
> > I believe you need to find a copy of the embedded windows ce
> > development kit for version 3.x, which I think corresponds to W2K.
> The Windows CE API and DDK are documented in the MSDN Lib April 2001, so I
> can have some preliminary info. It looks easy, actually.
> > IIRC somebody told me that a knowledgeable person could build an entire
> > release of windows with it.
> With some limitations, application memory space is 32 MB, files are also 32
> MB. But it has a Web server, web explorer, mail, networking and some more.
> > The kit includes libs and souce for many platforms including x86 and
> > the MCA HAL.
> That is interesting. But why MCA HAL for a mobile device?
CE wasn't just for mobile devices, but embedded devices as well. We
were looking at it for use in aircraft instrumentation among other
things. I'm thinking POS cash registers or ATMs where there was already
a MCA presence.
> Perhaps as an example?
My guess is that the code was done for the beta of W2K and because it
existed it was recycled into the CE release. Remember the beta for W2K
supported MCA, but it was removed for the release. Certainly they
didn't write the code just for CE.
UZnal
> existed it was recycled into the CE release. Remember the beta for W2K
> supported MCA, but it was removed for the release. Certainly they
> didn't write the code just for CE.
Certainly not, the CE borrows code from their repository. If the beta
supported MCA, chances are there it still does. I found a W2K DDK link,
however, awfully slow, something like 10 hours to download. Once I get it, I
will have a better idea.
As for CE, I have to look at the CDs here, I didn't pay much attention to it
so far.
Daniel Hamilton
> My guess is that the code was done for the beta of W2K and because it
> existed it was recycled into the CE release. Remember the beta for W2K
> supported MCA, but it was removed for the release. Certainly they
> didn't write the code just for CE.
I have several W2K betas...I can check this out.
--Daniel
UZnal
If you google for "2kddknly.exe" you'll hit it somewhere in the Far East.
The original link does not work:
http://download.microsoft.com/download/win2000ddk/install/august00/nt5/en-us
/2kddknly.exe
UZnal
"To provide support for ... bus on Windows NT 4.0, you must modify the HAL
(hardware abstraction layer) to recognize and initialize the I/O bus during
system boot and you must provide a set of HAL functions for scanning the bus
and accessing the configuration space of the devices by other drivers. Next,
you must write drivers for every type of ... device that load along with the
system, and then use the exported HAL functions to scan the bus to detect
the device, read the I/O resource requirements, and configure and initialize
the device.
To support this bus and its devices under Windows 2000, however, you don’t
have to modify the HAL or export a new set of functions. All you need to do
is write a bus driver that has knowledge of bus architecture, identifies
(enumerates) devices on the bus, reads their resource requirements, and
configures them. This driver model also makes the operating system
independent of its I/O bus. This means you don’t need help from Microsoft if
you design a new I/O bus to modify the HAL.
Then, you write function drivers to control individual devices connected to
the bus. Later on, one can write one or more filter drivers to add or modify
the features supported by bus, a specific device or class of devices. There
can be any number of lower-level or upper-level filter drivers for a bus, a
device, or a class of devices."
UZnal
File SRC\KERNEL\SERIAL\LEGACY.C:
if (defaultInterfaceType == MicroChannel) {
defaultInterruptMode = CM_RESOURCE_INTERRUPT_LEVEL_SENSITIVE;
// Microchannel machines can permit the interrupt to be
// shared system wide.
userData.DefaultPermitSystemWideShare = TRUE;
File SRC\KERNEL\SERIAL\PNP.C:
if ((PConfig->InterfaceType == MicroChannel) &&
(PConfig->InterruptMode == CM_RESOURCE_INTERRUPT_LATCHED)) {
...................
SerialDump(
SERERRORS,
("SERIAL: Latched interrupts and MicroChannel\n"
"------- busses don't mix\n")
);
status = SERIAL_BUS_INTERRUPT_CONFLICT;
goto PortInfoCleanUp;
}
File SRC\STORAGE\MINIPORT\AHA154X\AHA154X.C:
hwInitializationData.AdapterInterfaceType = MicroChannel;
if (ConfigInfo->AdapterInterfaceType != MicroChannel)
File SRC\INPUT\PNPI8042\KBDDEP.C:
if (configuration->InterfaceType == MicroChannel) {
File SRC\INPUT\PNPI8042\MOUDEP.C:
if (configuration->InterfaceType == MicroChannel) {
File SRC\NETWORK\NDIS\E100BEX\INIT.C:
//Must be ISA, EISA or MicroChannel (not supported)
File SRC\NETWORK\NDIS\NE2000\NE2000.C:
// Microchannel adapters.
// and Interrupt from the registry. Used for Microchannel
File INC\DDK\WDM\STRMINI.H:
// MicroChannel
File INC\DDK\MINIPORT.H:
MicroChannel,
File INC\DDK\NDIS.H:
MicroChannel,
NdisInterfaceMca = MicroChannel,
File INC\DDK\NTDDK.H:
MicroChannel,
File INC\DDK\SRB.H:
// MicroChannel
File INC\WDM.H:
MicroChannel,
File SRC\NETWORK\NDIS\NE2000\NE2000HW.H:
// ID for MCA Ne2000 clone cards
#define AE2_ADAPTER_ID 0x67b0
#define UB_ADAPTER_ID 0x611f
#define NE2_ADAPTER_ID 0x7154
// Microchannel IRQ POS register mask and shift count
// Microchannel I/O base address mask and shift count
File INC\REGSTR.H:
// Values in REGSTR_KEY_SYSTEMBOARD
#define REGSTR_MACHTYPE_IBMPS2_25 TEXT("IBM PS/2-25")
#define REGSTR_MACHTYPE_IBMPS2_30_286 TEXT("IBM PS/2-30 286")
#define REGSTR_MACHTYPE_IBMPS2_30 TEXT("IBM PS/2-30")
#define REGSTR_MACHTYPE_IBMPS2_50 TEXT("IBM PS/2-50")
#define REGSTR_MACHTYPE_IBMPS2_50Z TEXT("IBM PS/2-50Z")
#define REGSTR_MACHTYPE_IBMPS2_55SX TEXT("IBM PS/2-55SX")
#define REGSTR_MACHTYPE_IBMPS2_60 TEXT("IBM PS/2-60")
#define REGSTR_MACHTYPE_IBMPS2_65SX TEXT("IBM PS/2-65SX")
#define REGSTR_MACHTYPE_IBMPS2_70 TEXT("IBM PS/2-70")
#define REGSTR_MACHTYPE_IBMPS2_P70 TEXT("IBM PS/2-P70")
#define REGSTR_MACHTYPE_IBMPS2_70_80 TEXT("IBM PS/2-70/80")
#define REGSTR_MACHTYPE_IBMPS2_80 TEXT("IBM PS/2-80")
#define REGSTR_MACHTYPE_IBMPS2_90 TEXT("IBM PS/2-90")
Daniel Hamilton
> To support this bus and its devices under Windows 2000, however, you don’t
> have to modify the HAL or export a new set of functions. All you need to do
> is write a bus driver that has knowledge of bus architecture, identifies
> (enumerates) devices on the bus, reads their resource requirements, and
> configures them. This driver model also makes the operating system
> independent of its I/O bus. This means you don’t need help from Microsoft if
> you design a new I/O bus to modify the HAL.
>
> Then, you write function drivers to control individual devices connected to
> the bus. Later on, one can write one or more filter drivers to add or modify
> the features supported by bus, a specific device or class of devices. There
> can be any number of lower-level or upper-level filter drivers for a bus, a
> device, or a class of devices."
Eureka!
--Daniel
Daniel Hamilton
>>> W2K DDK
> Then, you write function drivers to control individual devices connected to
> the bus. Later on, one can write one or more filter drivers to add or modify
> the features supported by bus, a specific device or class of devices. There
> can be any number of lower-level or upper-level filter drivers for a bus, a
> device, or a class of devices."
So perhaps the reason then that MCA is not supported on W2K is because
no bus driver was written or provided? If this is the problem, then not
only could W2K be made to work, but also XP. It might take some
work...it'd be funny to see XP boot-up on a Model 70 386, it might take
it a week though. :)
--Daniel
UZnal
> no bus driver was written or provided?
MCA is already supported to some degree - serial port, parallel port,
keyboard, mouse, floppy drive, AHA-1640, NE2000, level sensitive
interrupts - all examples from the DDK and the 'MicroChannel' interface type
has not yet vanished.
Some but not all W2K drivers comply with the WDM. The DLLs still export the
legacy calls, those that were available on NT. Unless there are hidden
traps, there is not much left for a full scale support, whatever that means
to us.
Perhaps M$ let the door open for IBM to jump in or as a sign of a good will.
But to develop M$CA software would have been the least IBM would do. No big
bucks any more there.
> If this is the problem, then not
> only could W2K be made to work, but also XP. It might take some
> work...it'd be funny to see XP boot-up on a Model 70 386, it might take
> it a week though. :)
Things can happen, you just have to keep in mind people are scared to touch
a tested sofware, and they want to and must stay Win-compatible.
IBMMuseum
Louis Ohland
RickE
> Riddick?
"You keep what you kill" a fun movie, not a great one.
Louis Ohland
Tomas Slavotinek
dated 1998-10-19 seems to be the last one with the "proprietary" HAL
DLLs still in place: HALMCA, HALCBUS (Corollary), HALCBUSM (Corollary
MCA), and HALNCR (NCR MP).
They are all gone in the next leaked/released build - 1946 dated 1999-04-25.
While the HAL files are still present in the 1911 image, they may be
unused, broken, or unstable.
If anyone wants to mess with these old builds, just let me know...
Louis Ohland
restrictions for the beta 2K progress. I DIMMly remember some progress,
but there seems to have been a sticking point.
When it seemdt to hit a brick wall, the efforts trailed off...