Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Host Name vs. NetBIOS Name?

4,082 views
Skip to first unread message

Mick

unread,
Apr 26, 2004, 8:46:10 PM4/26/04
to
I've read some conflicting info in a networking book about what the
"Computer Name" in Windows actually is, i.e. is it the NetBIOS name or the
Host Name? So on my machine (running XP home), I changed the Computer Name
in the System Properties Tab. After reboot, I ran IPCONFIG /ALL, and
whataya know, the "Host Name" had changed to the new Computer Name. Okay,
so Computer Name means Host Name. But what about NetBIOS name? Where would
I find that? TIA.
---Mick


Mauricio Fernandez MCSE, CCNA

unread,
Apr 29, 2004, 9:45:45 PM4/29/04
to
There really isn't a contradiction. It goes like this.

A host name is any device in any form that has a network ip address.
It could be a router,workstation, server or whatever.

A NetBIOS name is what Microsoft "WINDOWS" refers to each computer.
Rather than calling a machine by it's IP ADDRESS, windows uses a
friendly NetBIOS name such as Server1 or PC1.

Jeff

unread,
May 4, 2004, 5:05:52 PM5/4/04
to
Isn't a NetBIOS name, a name that Windows NT can translate.

Example: Windows 2000 would see a domain name as EXAMPLE.COM, but
Windows NT would see it as EXAMPLE.

I don't know if I'm right but I just assumed this.

"Mick" <nos...@my.house> wrote in message news:<tcydnXXV8cT...@comcast.com>...

Mauricio Fernandez MCSE, CCNA

unread,
May 5, 2004, 9:04:32 PM5/5/04
to
The Example.com example, i believe your referring to Active Directory.

Getting really technical read this...

NetBIOS Specification

--------------------------------------------------------------------------------

1. Overview
Go to Index

--------------------------------------------------------------------------------

Names
For communication between stations of a network, each station is given
one or more names. These names are alphanumeric names, 16 characters
in length, and should be ASCIIZ form - that is the last byte should be
00h. There are two types of names:

Unique names - these may only be used by one station on the entire
network. If someone else tries to use a unique name, the network is
first checked to ensure that the name requested is not already in use.
A good example of a unique name, is the name a station uses to connect
and communicate with the server. This is usually the station name.
Group names - these may be used by as many stations at once as you
want. When you request the addition of a group name, it must not
already be in use as a unique name anywhere on the network, but it can
be is use as many times as required as a group name. A good example of
the use of group names is a talk program. Each station has its own
unique name from which to send messages, but it sends messages to a
global group name so all stations can see the messages. (Note: I am
currently writing a NetBIOS/IPX talk program, which I will release as
shareware in the coming months - wait out for it in the Free software
section.
Communication
Each station has a number of names, through which it communicates with
other stations on the network. There are two types of communication
within NetBIOS - connectionless and connection-orientated. The two
types will now be described:

Connectionless
A station requests that some data is sent in the form of a datagram.
All other stations are continually checking the network for datagrams,
to see if they apply to themselves. If they do, the message is
received. However, there is no form of handshaking, or
acknowledgement, so it is not guaranteed that all stations on the
network will receive the message as intended. However, in my
experience, the message is received all but a few times in many
thousands - this may be different on other networks.

Datagrams can be addressed to other stations in two ways:

Specific - a name is specified to send the datagram to (the name may
be a unique of group name) - if the software is waiting for a message
on that particular name it will be received
Broadcast - the message is sent to all stations - if the software is
waiting for a broadcast datagram it will be received
Note that the message will only be received, if you have programmed
the station to receive a datagram. Otherwise it will be ignored. The
specification (below) allows you to request that a datagram be
received on a particular name. The network software can then, in the
background, examine every datagram passing, and receive it if
required.

Connection-Orientated
A connection is established between two names. The connection is known
a as session, and may not be between two stations. It can in fact be
between any two names, including two names on the same station. Data
is transferred through this session, rather like dialling up an
Internet service provider via a PPP line. This method is the reliable
method to use, although possibly harder to program. The message is
either delivered successfully, or an error is returned to the
application, so it is aware of the transmission, or receive, failure.

Interface
The interface is accessed through interrupt 5Ch - this interrupt is
called, like any other interrupt, with ES:BX pointing to a 64-byte
data structure, which is known as the Network Control Block (NCB).
This contains the required data, such as names, command codes,
pointers to buffers etc. The NCB must be unaltered until the command
is completed, so it cannot be used for other commands, whilst a
command is still executed. However, once a command has completed, the
NCB can be altered, and reused for another command.

There are two different methods a NetBIOS command can be used -
asynchronous or synchronous.

Synchronous commands
The command is initiated by setting up the NCB, and calling interrupt
5Ch, with ES:BX pointing the the NCB. Control will only be returned to
your program, when the command has completed (or timed out). Bit 7 of
the command byte is set to 0 to indicate a synchronous command. When
control is returned, the return_code field of the NCB indicates the
initiation or completion status. The value of this field is also
returned in AL. An example of the use of this type of command, is
adding a name for communication. The program cannot continue until
this has been successful or failed.

Asynchronous commands
The command is initiated in the same way as synchronous commands,
however bit 7 of the command byte is set to 1, to indicate that you
require an asynchronous command. Control is immediately returned to
your program, with the return code field, and AL, containing the
initiation status. You must therefore check to see when the command
has been completed. There are two ways of doing this:

Poll the command_complete field of the NCB. This contains FFh, if the
command is still being executed, and is set to another value, the
completion code, once the command has been completed (or an error has
occurred).
There is a four byte field (post_address) which is usually set to
0000:0000. This can be used to point to a POST routine. A POST
routine, is a user routine which is called once the command been
completed. The POST routine is called by the networking software with
ES:BX pointing the NCB which has been completed, and AL containing the
contains of the command_complete field. No other registers are
defined. The POST routine should be written in the same way as an
interrupt service routine - that is, interrupts are disabled, and
should not be re-enabled, and the routine should be as quick as
possible, and be terminated with an IRET instruction.
This type of command can be used, for example, in a talk program. An
NCB is set up to receive a message (datagram) on a specific name. The
POST points to the routine to process the received message and display
it on the screen. The software must not wait until a message is
received, as the user cannot enter any messages him/herself.

Asynchronous commands can also be used for multitasking. An
asynchronous command can be initiated within the POST routine of a
command, for example once a message has been received in a talk, the
NCB must be reinitialized to receive the next message. However,
synchronous commands cannot, and should not, be called in a POST
routine, or the machine will also definitely crash.

0 new messages