DesertPenguin.org

This is a continuation of my series of articles on the history of personal computers. It follows my fifth CP/M article.

The series starts with my first CP/M article. If you have not read the previous articles, I recommend that you read them first.

Looking at 8 bits

Our story started with the Intel 8080 CPU (and its clone, the Zilog z80 CPU), which was an 8 bit CPU with 8 bit bytes, meaning that both the smallest and largest unit it could address in memory was 8 bits wide. Its general purpose registers, meant to store data loaded from such a unit in memory, were also 8 bits wide.

But the 8080 did have 16 bit registers as well. Most prominently the program counter and registers used to address memory were 16 bits wide, because the 8080 CPU did have an address bus 16 bits wide. It could address, without using bank switching, 64 KB of memory.

The 8080's 8 bit registers are paired to form 16 bit registers. The registers are nominally general purpose registers, which apparently means that programmers are supposed to use them or at least know of them. But convention and limitations of the CPU's instruction set do define certain purposes to each register. Generally, those purposes are these:

1. Accumulator: originally the only register of a CPU this is the register which usually contains the number one works with
2. Flags register: this register is not used as a register but contains (for example 8) bits that are either on or off to switch on or off certain modes or mechanisms of the CPU or the computer; it is listed here only because it is paired with the 8 bit accumulator of the 8080
3. Address register: such a register contains a memory address, usually a destination address (meaning an address the programmer sets) or a source address (meaning an address returned by a call to a calling routine)
4. Counter: a counter
   
5. System call register: used to store the system call number a system call parameter
6. Not normally used: a register or view of a register that isn't used for anything but exists anyway for technical reasons

All of these registers except the system call registers can be 8 or 16 bit wide in the Intel 8080 and Zilog z80.

I am getting to why this is relevant for MS-DOS shortly. Stay with me.

The 8080's general purpose registers are the following 16 bit registers consisting of two 8 bit registers each:

• AF (not normally used) consisting of A (accumulator) and F (flags register)
• HL (source address) consisting of H (not normally used) and L (not normally used)
• BC (16 bit counter) consisting of B (8 bit counter) and C (system call number)
• DE (destination address) consisting of D (not normally used) and E (system call parameter)

Note that registers used for system calls by the operating system have not technically been designed for that purpose, at least at first. The OS vendor just chose those because they were available.

This was the standard for CP/M computers and when Intel designed a 16 bit CPU to take over the market, Intel tried to make it easy for software to be written for the new CPU when it had already been written for the old CPU.

Enter 16 bits

The Intel 8086 CPU, which followed the 8080-compatible Intel 8085 CPU, paid lip service to 8080-compatibility. But it also added several new features.

The 8080 CPU was an 8 bit CPU and could address a minimum and maximum unit of 8 bits in memory. The new 8086 CPU could address a minimum unit of 8 bits (the CPU's "byte") but a maximum unit of 16 bits (the CPU's "word") in memory. The old 8080 CPU could address up to 2^16 bytes (the minimum unit) of memory, the new 8086 CPU can address 2^20 bytes of memory. I am sure there are other differences but those are the ones we have to worry about here. Apparently the new CPU was also faster.

I'll ignore the new 20 but memory addressing scheme for the moment.

The 8086's general purpose registers are the following 16 bit registers consisting of two 8 bit registers each:

• AX (16 bit accumulator) consisting of AH (MS-DOS system call number) and AL (8 bit accumulator)
• BX (source address) consisting of BH (not normally used) and BL (not normally used)
• CX (16 bit counter) consisting of CH (8 bit counter) and CL (compatibility system call number)
• DX (destination address) consisting of DH (not normally used) and DL (system call parameter)

Note that the 8086's flags registers are not paired with general purpose registers and hence don't appear here in this list.

The 8086 machine language is sufficiently similar to the 8080's that assembler programs could be translated automatically (and then re-assemled for the 8086 CPU).

And since I like tables and since it might make comparisons easier:

Enter MS-DOS

MS-DOS, originally marketed as PC DOS and originally named 86-DOS, is a CP/M clone. The term "clone" here does not mean "identical genes" as it does in biology but only (and solely) that the "clone" behaves like the "cloned" software. It is important to note that a clone is not a copy. It is a piece of software written separately to conform to certain standards defined by another piece of software.

Such a clone might not just behave like the original software but might happily add new features, especially to support new hardware which the original software was never designed to support. The creation of clones in the software industry is as old as the creation of industry standards. Linux is a clone of Unix, MS-DOS is a clone of CP/M.

MS-DOS quickly became better than CP/M.

Back in 1980 Microsoft was a developer of developer tools, a compiler writer. All the example programs written for the previous articles in this series were created with Microsoft's products for CP/M. When IBM designed a new personal computer based around the Intel 8086 CPU, IBM went to Microsoft to buy developer tools for it and ultimately an operating system as well, which was then sold by Microsoft for less money per licence than the 16 bit version of CP/M that was finished later than Microsoft's 86-DOS.

MS-DOS quickly became the market leader in the new 16 bit world.

Ignoring the new memory features of (later versions of) MS-DOS and the 8086 CPU, MS-DOS looked and felt pretty much like CP/M, naturally, with the following notable differences:

• The command interpreter was called command.com instead of cpp.com.
• The command interpreter's prompt was "A:>" rather than "A>".
• The command to copy a file was an internal command copy rather than CP/M's external pip.com.
• The copy command followed the syntax of Unix' cp command, i.e. copy file1 file2 to copy from file1 to file2.
• Files' sizes are counted in bytes rather than blocks, allowing text files not to be filled in with ^Z.
• MS-DOS ran on IBM PCs and compatible using an 8086 CPU
• MS-DOS eventually supported subdirectories.
• MS-DOS eventually supported hard disks (as did a later 16 bit version of CP/M)

But apart from a few differences like those MS-DOS and CP/M were very similar. They also ran the same programs, if translated and re-assembled to 8086 machine code or written in C or some other high-level language. There was no binary compatibility between the two CPUs or between MS-DOS and 16 bit CP/M for the same CPU.

Enter the IBM PC

The IBM PC and the 8086 CPU could address 2^20 bytes or 1 MB of RAM.

This is what the world looks like in an IBM PC:

1 MB of addressable memory are divided into two zones: 640 KB of "conventional memory" and 384 KB of ROM, video RAM, and other stuff like that. A typical IBM PC had 64 KB of memory plus ROM and, presumably, some sort of video memory. I assume this gives the programmer more memory than he had on a CP/M computer since the BIOS doesn't have to be in that same 64 KB.

If the computer had more than 64 KB of memory, the operating system itself can also be outside the 64 KB. And if the computer had a multiple of 64 KB of memory, the program itself could occupy more than 64 KB of memory. I will come to that later. For our purposes here there are 64 KB of Transient Program Area somewhere in the Conventional Memory, the operating system is also somewhere and for some reason all addresses we are using are relative to the start of our Transient Program Area. This is actually literally true.

Hello, IBM world

MS-DOS supports the same system calls as CP/M. In general. For the most part. Sometimes.

I wrote about CP/M that system calls can be made by calling address 05h in the Zero Page.

The instruction at address 05h calls the BDOS and allows a transient program to make a system call without having to know where in memory the operating system actually is. System calls are made by configuring registers for the call number and parameters and then calling address 05h. (In DOS jargon this is referred to as a "call 5" system call. It is supported by both CP/M and MS-DOS.)

(See my article on CP/M at the start of this series.)

This theoretically still holds true. Allegedly and according to the 86-DOS documentation, MS-DOS does support making system calls the same way CP/M does. I never got this to work. The computer simply hangs when I try.

However, making system calls does work using the native 86-DOS way of doing it. Instead of call 5 MS-DOS defines a software interrupt 21h that does the job and can be called as int 0x21.

The system call number goes in (8 bit) register AH, a system call parameter goes into register DL, and a memory address to be used by the system call goes into (16 bit) register DX.

A "Hello, world" for MS-DOS thus looks very similar to a "Hello, world" program for CP/M.

You can copy and paste the source from here: hello1.asm

This appears to work.

Next I will take a look at how MS-DOS and the IBM PC are different from CP/M running on an 8080 or z80 CPU.

To be continued…

I have successfully installed Microsoft Exchange 2013 in my test environment. But I will describe that adventure later.

Rather what spiked my interest today is ADSI, Active Directory Service Interfaces.

Microsoft describes ADSI thus:

"Active Directory Service Interfaces (ADSI) is a set of COM interfaces used to access the features of directory services from different network providers. ADSI is used in a distributed computing environment to present a single set of directory service interfaces for managing network resources. Administrators and developers can use ADSI services to enumerate and manage the resources in a directory service, no matter which network environment contains the resource."

In other words, ADSI is Your Plastic Pal Who's Fun to Be With.

But what ADSI can do is help a system administrator access directory information from any language that has access to the .NET framework, including PowerShell, using a few useful classes like System.DirectoryServices.DirectorySearcher and System.DirectoryServices.DirectoryEntry.

Here are a few somewhat useful examples.

DirectorySearcher

$searcher = new-object system.directoryservices.directorysearcher
This creates a new object searcher of the type directorysearcher. Note that the type has several constructors which can make the next two lines unnecessary if the object is only needed once.

$searcher.searchroot = [ADSI]"LDAP://dc=ludwig,dc=example,dc=com"
The field searchroot is an ADSI object which can be created on-the-fly by casting a string containing an LDAP URL. In this case it's the LDAP URL for the domain ludwig.example.com. Note that this is somewhat case-sensitive. "ADSI" is upper case, as is "LDAP". "dc=" means "domain component=".
The searchroot field can also be initialised as the first or only parameter of the constructor. Note the second-last example.

$searcher.filter = "(objectclass=computer)"
This field defines what type of object is to be searched for. It's a string. The format appears to be "(objectlass=whatever type of object you want)". Apparently an empty string is automatically changed to "(objectclass=*)".
The filter field can also be initialised as the second or only parameter of the constructor. Note the last example.

$searcher.findall()
This method simply displays all matching objects.

$searcher = new-object system.directoryservices.directorysearcher([ADSI]"LDAP://foobar")
Creates a directorysearcher object with searchroot set to the ADSI object created on-the-fly.

$searcher = new-object system.directoryservices.directorysearcher("(foobar)")
Creates a directorysearcher object with filter set to the given string.

DirectoryEntry

$group = [ADSI]"WinNT://client1/administrators,group"
This creates a new object group of the type directoryentry based on a local directory entry on the computer client1, namely the group "administrators" on that computer. WinNT URLs look simpler than LDAP URLs. I don't know why casting to ADSI is enough to create a specific type of object. (The ",group" at the end of the URL is possibly unnecessary but who knows.)

$members = $group.psbase.invoke("Members")
I don't know what psbase is, but it contains a method invoke() which, in a coincidence that reminds me of Groucho Marx, invokes methods. Apparently there is a method Members which returns the members the directory entry has, presumably when it is a group. Note that the newly-created object members is now completely unusable and has to be cast into an array first.

$members = @($group.psbase.invoke("Members"))
This returns the same contents as the call above but casts the result into an array members.

$members[0].gettype().invokemember("Name", "GetProperty", $null, $members[0], $null)
Now it gets complicated. The class to which each individual object in the members array belongs has a static (class) method invokemember() which apparently takes four parameters. The first parameter is the name of the field (here "Name"), the second maybe a method (here "GetProperty"), the third and fifth are null and the fourth is the object on which to unleash this monster.

$members[0].gettype().invokemember("Name", "GetProperty", $null, $members[1], $null)
Note that since $members[0] is here only used to get the type of the objects in the members array it doesn't matter that the static method is called on the type of object number 0 while addressing object number 1. It's the same method on both objects but different data in the fields. Note that those are COM objects and rest assured that you don't want to deal with them more directly.

$user = [ADSI]"WinNT://ludwig/superman"
This creates another directoryentry, this time named user. The user in question is a domain user ludwig\superman.

$group.psbase.invoke("Add", $user.path)
This adds a user defined in the string user.path to the local group represented by the object group.

$group.psbase.invoke("Remove", $user.path)
And this removes that same user.

$group = [ADSI]"LDAP://cn=domain admins,cn=users,dc=ludwig,dc=example,dc=com"
And yes, this can be done with an LDAP (i.e. a domain-based) group as well. However, since the LDAP URLs to those groups are not as simple as the WinNT URLs to local groups, it is probably best to play with directorysearcher first, see above.

Anyway, this is how you can be finding it out with ADSI.

SharePoint is one of the more tiresome Microsoft server products. It has lots of prerequisites and the installer expects to have Internet access to download those because they are not part of the distribution.

SharePoint also required a server Graphical User Interface and does not install on Server Core.

Running sharepoint.exe results in files being extracted somewhere. Finally a splash screen appears.

The feared prerequisites installer can be launched from here. After running, it conveniently complains about all the things it couldn't do because a) it cannot configure Windows components and b) it just assumed that it has Internet access which is often not the case on internally deployed servers.

At least we are getting a nice list of prerequisites (from now on called "preqs") which we must find and install. Note that the preqs installer can be configured to use a different source than the Internet and must be run for the installation of Windows Server AppFabric because a manual installation of AppFabric just won't work.

Let us take a look at each preq.

1. Microsoft .NET Framework 4.5
   • This is a Windows component.
   • It is already installed and if not can be installed from Server Manager or PowerShell.
2. Windows Management Framework 3.0
   • I am pretty sure this is simply PowerShell.
3. Application Server Role, Web Server (IIS) Role
   • Those are Windows components.
   • They can be installed from Server Manager or PowerShell
4. Microsoft SQL Server 2008 R2 SP1 Native Client
   • This is technically a component of SQL Server 2008 R2.
   • However, the SQL Server 2008 R2 DVD does not have SP1.
   • Native Client is part of the SQL Server 2008 R2 SP1 Feature Pack, file name is sqlncli.msi.
   • Download here: http://www.microsoft.com/en-us/download/details.aspx?id=26728
5. Microsoft Sync Framework Runtime v1.0 SP1 (x64)
   • This is a free Microsoft download.
   • Download here: http://www.microsoft.com/en-us/download/details.aspx?id=17616
6. Windows Server AppFabric
   • This is a free Microsoft download.
   • Download here: http://www.microsoft.com/en-us/download/details.aspx?id=27115
   • Note that AppFabric must be installed by the preq installer!
7. Microsoft Identity Extensions
   • This is one of Microsoft's better-protected secrets. Microsoft's Download Center has never heard of it.
   • This is a direct download link to the file: http://download.microsoft.com/download/0/1/D/01D06854-CA0C-46F1-ADBA-EBF86010DCC6/r2/MicrosoftIdentityExtensions-64.msi
8. Microsoft Information Protection and Control Client
   • This is actually called "Active Directory Rights Management Service Client 2.0"
   • Download it here: http://www.microsoft.com/en-us/download/details.aspx?id=29892
9. Microsoft WCF Data Services 5.0
   • Download it here: http://www.microsoft.com/en-us/download/details.aspx?id=29306
10. Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server
    
    • This finally gives us a hint that version 1.1 of AppFabric is meant above.
    • Download the update here: http://support.microsoft.com/kb/2671763

We can proceed with installing a few required Windows components. Note that the Windows Server 2012 DVD is in drive D: in these examples.

Install IIS:

add-windowsfeature web-server -includeallsubfeature -source d:\sources\sxs

Install Application Server:

add-windowsfeature application-server -includeallsubfeature

Now we need to configure the preqs installer to use the installer files downloaded manually above. We cannot read the installation guide because that too needs to be downloaded. First we need to find out where the preqs installer actually is. Task Manager identifies its location as

"c:\program files (x86)\MSECache\SharePoint2010"

despite the fact that this is SharePoint 2013.

Running prerequisiteinstaller /? finally tells us how we can tell the preqs installer where it will find the preqs installation files.

It also confirms that "Windows Management Framework" really is another term for PowerShell and mentions for the first time that we also need "Windows Identity Foundation" which is a Windows component.

add-windowsfeature windows-identity-foundation

After installing Windows Identity Foundation we can run the preqs installer with the required file locations to see what happens. Don't forget to copy all those files into the same folder as the preqs installer, which is

"c:\program files (x86)\MSECache\SharePoint2010"

despite the fact that this is SharePoint 2013. Also let's not forget to restart the computer before we proceed.

Only one preq must be installed by the preqs installer itself. Install the following preqs simply by double-clicking the files.

1. Microsoft SQL Server 2008 R2 SP1 Native Client
2. Microsoft Sync Framework Runtime v1.0 SP1 (x64)
3. Microsoft Identity Extensions
4. Microsoft Information Protection and Control Client
5. Microsoft WCF Data Services 5.0

The following preqs have to be installed by the preqs installer.

1. Windows Server AppFabric
2. Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server

From cmd.exe run

prerequisiteinstaller /appfabric:.\WindowsServerAppFabricSetup_x64.exe /kb2671763:.\AppFabric1.1-RTM-KB2671763-x64-ENU.exe

and I wish I were kidding!

Now we are done with the prerequisites and can begin with the installation.

This process takes a l-o-n-g time. Seriously, go to lunch!

After the installation, the Configuration Wizard launches and configures.

Incidentally, this configuration also takes rather l-o-n-g. It is definitely time for a second lunch.

After configuration the new SharePoint site can be accessed. My SharePoint server is called client3.

This is a continuation of the previous blog entry about configuring Windows Server 2012.

*** Installing SQL Server 2012 with full GUI***

SQL Server 2012 cannot easily be installed on Windows Server 2012. SQL Server 2012 requires .NET Framework 3.5 and the full GUI. Let's assume that the drive letter for the Windows Server 2012 DVD is D:.

add-windowsfeature net-framework-core -source d:\sources\sxs
This installs .NET Framework 3.5 needed by SQL Server 2012. If your server has Internet access you don't need the -source switch.

add-windowsfeature server-gui-shell
This installs the GUI necessary for SQL Server 2012.

Now we can install SQL Server 2012 using setup.exe on the SQL Server 2012 DVD.

*** Installing SQL Server 2012 on Server Core ***

SQL Server 2012 setup.exe requires WoW64 for some reason, or at least it complains about a missing 32 bit DLL. It will only tell us if we start it using the start command. It does not output to the command line or draw a window otherwise.

add-windowsfeature net-framework-core -source d:\sources\sxs
This installs .NET Framework 3.5 needed by SQL Server 2012. If your server has Internet access you don't need the -source switch.

add-windowsfeature wow64-support
This will install WoW64.

With WoW64 installed, setup.exe runs and informs us that it is not supported on Server Core but will run in Full Quiet mode (/Q switch) or Quiet Simple mode (/QS switch).

This Microsoft article describes how to install SQL Server 2012 from the command line.

I tried it out.

We need the following parameters (I think):

• /qs or /q for Quiet Simple or Full Quiet mode
• /action=install
• /features=sqlengine
• /instancename=mssqlserver
• /agtsvcaccount="nt service\sqlserveragent"
• /sqlsvcaccount="nt service\mssqlserver"
• /sqlsysadminaccounts=domain\someuser
• /iacceptsqlserverlicenseterms

There are also parameters /agtsvcpassword and /sqlsvcpassword if needed. The accounts of the type "nt service\servicename" are "virtual accounts" that don't have passwords and essentially are supposed to act as service accounts locally and computer accounts when connecting to other computers in a domain. Obviously this never works.

setup.exe /qs /action=install /features=sqlengine /instancename=mssqlserver /agtsvcaccount="nt service\sqlserveragent" /sqlsvcaccount="nt service\mssqlserver" /sqlsysadminaccounts=ludwig\superman /iacceptsqlserverlicenseterms
This finally installs SQL Server 2012.

See screenshots of Windows Server 2012 (mostly in Server Core mode) and SQL Server 2012 here.

These are four helpful links for anyone in the business of administering or engineering computer networks. Those documents seem simple but are very helpful indeed.

What are the different wireless network security methods?
http://windows.microsoft.com/en-us/windows-vista/what-are-the-different-wireless-network-security-methods

Cisco Router Configuration Tutorial
http://www.joshgentry.com/cisco/cisco.htm

Routing Protocol Comparison (PDF file)
http://www.routeralley.com/ra/docs/routing_protocol_comparison.pdf

ASCII Table
http://www.asciitable.com

Yes, I keep forgetting these things all the time.