"Frank Gilliland" wrote in message
news
On Sat, 28 Aug 2004 14:16:56 -0400, "Leland C. Scott"
wrote in :


"Twistedhed" wrote in message
...
Do or can you write and design software programs?

I did for class projects when I was working on my computer science
degree.
The biggest program was an integrated DOS utility for reading disk
parameters, viewing the raw sector data, showing what disk clusters were
used by any file on the disk, and finally a disk defragmentation
function.
The program featured pop-up overlapping menus, hot keys, and mouse
control.
It was written in C++ and took me about 2-1/2 months to write working on
it
around 15 to 20 hours per week, design - test - debugging. And after all
that it was specifically written for a 720K floppy disk so the professor
could test it without killing his hard drive in case of bugs. All that
was
for a project for a class I took in operating systems. I think mine was
the
only one that worked and also handled subdirectories too. Even the 20+
something year old class computer geek wiz, and the professor's pet
student
no less, couldn't do it. I got the "look" from him in the hallway one day
at
the start of the next semester.


2-1/2 months? You should have learned disk access functions on a
COCO-II -- your program would have been up and running in about three
days. IOW, it's much easier if you bypass the BIOS calls and access
the disk directly.

I didn't use any OS calls at all. The only BIOS functions I used were direct
calls to read/write absolute disk sectors. Everything else I had to write
from scratch. As simple as the DOS file system was there was still a lot to
handle. What made thing more interesting was all I had to work with was a
Windows 98 machine. That made thing more complicated because Windows always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows file
system extensions out, thus generating a valid DOS disk.



I haven't really gotten in to doing Windows programming, it's event
driven
verses procedural coded. That's a totally different animal. Windows
programming is a real pain, and complex if you really want to take full
advantage of the system. For simple programs that don't need a lot of
fancy
wiz-bang features Visual Basic is a good choice to use. The other choices
are Visual C++, C#, or Java. The last three are object orientated
languages.
That could be a big chuck to bite off and learn for somebody who hasn't
done
any programming at all.


I'll agree, Windoze sucks for programming. The libraries required for
even simple programs, while easier to understand than DOS, are far
more extensive than the DOS interrupt list, direct hardware control is
almost impossible, and the OS overhead sucks up most of the processing
power.

No kidding!

I've also done some Intel assembly language programming - 8080 and X86,
and
VAX-11 assembly too. Assembly language programming is to computers like
Morse Code is to Ham Radio. Now that I think about it the first computer
I
had was a Radio Shack TRS-80 with16K of memory. The first assembly
language
program I wrote, in Z80 assembly, was to translate text on the screen
into
Morse Code by keying the relay contact used to control the
record/play-back
function of the cassette recorder used for program storage.


You might have enjoyed playing with a TI-990 I scrapped a couple
months ago.

Those were rather unique if I remember right they used a 16 bit micro at the
time. They even had an expansion box for add ons too.

--
Leland C. Scott
KC8LDO

Wireless Network
Mobile computing
on the go brought
to you by Micro$oft

On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were direct
calls to read/write absolute disk sectors. Everything else I had to write
from scratch. As simple as the DOS file system was there was still a lot to
handle. What made thing more interesting was all I had to work with was a
Windows 98 machine. That made thing more complicated because Windows always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.

"Lancer" wrote in message
ews.com...
On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were
direct
calls to read/write absolute disk sectors. Everything else I had to write
from scratch. As simple as the DOS file system was there was still a lot
to
handle. What made thing more interesting was all I had to work with was a
Windows 98 machine. That made thing more complicated because Windows
always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows
file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.

Yeah, however I didn't feel like rebooting the computer 20 - 30 times going
through the design - test - debug routine each time I worked on the project.
The complier runs under Windows, but the defrag program runs under DOS. When
the program failed I ended up with a wrecked disk format. It was easier to
format the disk in a DOS window and just filter the long file name directory
entries out during the defrag process. It was rather easy to do anyway since
the long file name extension is done by using extra directory entries, 11
characters per entry, following the normal DOS directory entry for a given
file. The long file name directory entry is marked with an invalid set of
attribute bits that can't be set by the user under any condition so its easy
to detect. Also it just so happens that DOS ignores the directory entries
with the invalid attribute bit settings. The long file name ability using
Windows is a real hack on the part of Microsoft. Each directory entry uses
32 bytes, and only 11 are used, the old DOS 8 dot 3 file name format, the
rest is wasted. Enough of these directory entries are used as required until
there is enough 11 byte blocks to hold the long file name.

--
Leland C. Scott
KC8LDO

Wireless Network
Mobile computing
on the go brought
to you by Micro$oft

On Sun, 29 Aug 2004 15:34:31 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were direct
calls to read/write absolute disk sectors. Everything else I had to write
from scratch. As simple as the DOS file system was there was still a lot to
handle. What made thing more interesting was all I had to work with was a
Windows 98 machine. That made thing more complicated because Windows always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?





-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On Sun, 29 Aug 2004 14:42:31 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 15:34:31 GMT, Lancer wrote in
.com:

On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were direct
calls to read/write absolute disk sectors. Everything else I had to write
from scratch. As simple as the DOS file system was there was still a lot to
handle. What made thing more interesting was all I had to work with was a
Windows 98 machine. That made thing more complicated because Windows always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?


No, it shouldn't. There are no VFAT or virtual drivers loaded.

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
. com:

snip
Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On Sun, 29 Aug 2004 15:45:23 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
.com:

snip
Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?



Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.

On Sun, 29 Aug 2004 23:16:36 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 15:45:23 -0700, Frank Gilliland
wrote:

On Sun, 29 Aug 2004 22:33:01 GMT, Lancer wrote in
s.com:

snip
Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?


No, it shouldn't. There are no VFAT or virtual drivers loaded.


What I mean is, the disk is configured for use with a VFAT driver.
Doesn't that cause compatibility problems when working under the FAT
under DOS?



Frank;
The way I understand it, is that the disk is configured or uses
FAT. VFAT serves as an interface between applications and the FAT.
So there shouldn't be any compatibilty problems when running DOS
programs.


Ok.... but if the FAT is set for short (8.3) filenames while the VFAT
uses long filenames, there are going to be short filenames that are
identical in the same directory; i.e, under VFAT;

pornpic001.jpg
pornpic002.jpg
pornpic003.jpg

....but under DOS FAT they are listed as:

pornpic~.jpg
pornpic~.jpg
pornpic~.jpg

So how do you discriminate between these identical filenames from DOS
without the VFAT driver? Does the VFAT driver maintain a directory
index file?





-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

"Frank Gilliland" wrote in message
...
On Sun, 29 Aug 2004 15:34:31 GMT, Lancer wrote in
. com:

On Sun, 29 Aug 2004 01:20:38 -0400, "Leland C. Scott"
wrote:

I didn't use any OS calls at all. The only BIOS functions I used were
direct
calls to read/write absolute disk sectors. Everything else I had to
write
from scratch. As simple as the DOS file system was there was still a lot
to
handle. What made thing more interesting was all I had to work with was
a
Windows 98 machine. That made thing more complicated because Windows
always
wanted to create long file names which messed things up a bit when you
format a disk. I had to put extra routines in to the code to filter that
crap out so when the disk was defragmented I had wiped all the Windows
file
system extensions out, thus generating a valid DOS disk.


Windows 98 runs on a DOS kernel, so all windows 98 systems run on a
"valid" DOS disk. Edit your msdos.sys and turn your GUI off. Or just
make yourself a boot disk and format the drive.


Doesn't it still run on virtual FAT even without the GUI?

Yes it does use a FAT, File allocation Table, to manage the storage space on
the disk. Windows 95, 98 and DOS use it. The storage space is managed as one
or more disk sectors call a "cluster". The cluster number has to be mapped
to absolute disk sectors. The mapping varies depending on the size of the
disk. The FAT is nothing more than a table that maps one cluster to the
next. The file directory entry has the starting cluster number in it. The
way it works is the OS reads the starting cluster number out of the file
directory header. The numeric value points to a sequential entry in the FAT.
The OS then reads that value which again points to another entry in the FAT.
This proceeds until one of several special values is read, one of which
signals the value just read as being the last cluster in the chain. The
numeric value of the entries is also the cluster number of the data stored
on disk. Thus by following the chain of cluster numbers the OS is able to
read the file's data off of the disk in the correct order, even if the
clusters are not in sequential order on the disk. When this mapping gets
screwed up that's when you get messages from the OS about lost or cross
linked "chains". You may get more that one file that have a common cluster
mapped to it which should never happen, crossed linked files, or you have a
chain of clusters on the disk for which there is no file directory entry
with a staring cluster pointing to the beginning of the chain, i.e. lost
chains. The OS tries to clean up the mess by marking the clusters in the
lost chains as being free disk space. For crossed linked files the OS just
picks one file out of the two or more crossed linked and fixes the FAT so
that the cluster(s) in common are mapped to only one file while removing it
from the chain for the other files. There is no guarantee the OS is going to
pick the right file to do this either.

The other thing the FAT table makes hard is file un-deletion and making sure
nobody can read the deleted file's data. When you erase a file all that
happens is the OS makes the file's directory header as being unused by
changing some byte(s) in the header. The starting cluster number is not
zeroed out either. The OS also runs through the file's allocation chain
marking each entry with another of those special values that signals the OS
that the cluster is available for data storage. The actual data in the
cluster is not over written until it is used to hold the data from another
file. It's still there if you use a disk sector viewing utility. That's why
you see those utilities for scrubbing the disk of data from deleted files.
They write random data to the free clusters to make sure anything there is
unreadable.

Un-deleting a file is at best a pain and doesn't always work. The OS can
store the file's data in any available clusters on the disk. There is no
guarantee that the clusters will be used in order, or even sequentially, on
the disk. Thus any file's data that spans more that one cluster you normally
have to help the un-delete utility by looking at the data in the cluster and
deciding if this should be included in the reconstructed FAT chain. If the
data is not in human readable format you're screwed. If you're lucky the OS
tries to allocated the clusters from low to high numbers so the un-deleted
utility may try looking for the next free cluster on the disk assuming that
is was likely used by the file. It does this until the clusters have enough
storage space to hold the data as specified by the file size in the old
directory header. Some times the last method works, and some times it don't.


--
Leland C. Scott
KC8LDO

Wireless Network
Mobile computing
on the go brought
to you by Micro$oft