[Info-vax] System Programming versus Application Programming

[Stephen Hoffman]

On 2014-02-08 18:27:23 +0000, JF Mezei said:


Welcome y'all, to just some of what's involved with writing and 
maintaining an operating system.

Your training here will be complete when you can avoid even raising an 
eyebrow when somebody tells you that all systems and all I/O devices 
have truly compatible ABIs, and that these boards and these devices 
will never vary in characteristics or timing or features or status 
codes.  Only when you can remain stoic, will you truly understand the 
quicksand computing is built on.


> On 14-02-08 13:21, David Froble wrote:
>> Properly chastised.  Thanks Steve and John for furthering my education
> 
> To take this is a different direction.
> 
> I realise that Poulson is fairly different from Tukwilla.
> 
> But when Intel comes out with a new 8086, does it require the same type 
> of OS tuning as did the transition from Tukwila to Poulson ?

Microsoft has published specs 
<http://msdn.microsoft.com/en-US/windows/hardware/> for this stuff; the 
Windows Hardware Dev Center (WHDC) details, or whatever it's called 
now.   Here is some of the related history 
<http://en.wikipedia.org/wiki/PC_connector_colors> — these specs are 
where those funky pastel port colors came from, for instance.

The x86-64 ABIs for the core system designs are fairly well specified, 
and it's only the peripheral pieces that tend to vary.  Where there are 
differences, those can need vendor drivers.

So long as the operating system itself sticks to the subset for the 
processor and enough of the boot path is consistent with Windows 
expectations, it'll boot and run.  The vendor drivers and the platform 
ACPI data then present the rest of the device access and the system 
hardware.

> Or is upward compatibility too important in the x86 market and new 
> chips will run "off the shelf" opetating systems without any tailoring 
> being required ?
> 
> (I assume that some optional tailoring may be added later on to take 
> advantage of new instructions etc).

The compilers can choose to emit those instructions, and the 
programmers can choose to use or disallow the instructions.

> We rarely hear about the need to upgrade an OS to run on a now 8086.

Beyond the hardware specs, Windows has boot-start drivers 
<http://msdn.microsoft.com/en-us/library/windows/hardware/ff547570(v=vs.85).aspx> 
and some related baggage, and vendors commonly provide 
platform-specific software for booting Windows on a particular box.

Here's the Windows SAN boot <http://support.microsoft.com/kb/305547> 
discussion, which points to the vendors for the related documentation 
and drivers.

It wouldn't surprise me to learn that a few of the service packs also 
included different boot support, for that matter.

Anybody that's used WiFi on older Windows has probably tangled with the 
vendor drivers involved with that, too.

OpenVMS had created a few SHIP kits for a similar purpose — booting on 
otherwise unsupported hardware — mentioned briefly here 
<http://h71000.www7.hp.com/wizard/wiz_3750.html>.  These SHIP kits were 
used briefly by OpenVMS engineering, but I haven't seen indications of 
any recent SHIP kits being used — more recent practice seems to involve 
remastering the distributions with some UPDATE kit.

As for OS X, here are the versions involved for newer boxes: 
<http://support.apple.com/kb/HT1159>

See some very general discussions of the Linux and FreeBSD x86-64 ABI 
compliance <http://en.wikipedia.org/wiki/X86-64>

> Just wondering if this is because it is done behind the scenes and 
> makes no noise, or whether it is because new 8086s do not need the same 
> type of tailoring as Tukwila to Poulson did.

Spend more time with the low-level hardware and software and it'll be 
front-and-center.   Run Windows application programs on a 
vendor-supported box running Windows, and you'll probably not notice, 
until and unless you need a game or a tool that expects or needs 
specific hardware or software.


-- 
Pure Personal Opinion | HoffmanLabs LLC