ast@cs.vu.nl (Andy Tanenbaum) (10/14/89)
Here is a (hopefully) improved version of dos/read/write.dir. Could DOS
users please try it on floppies, HD, 12-bit FAT, 16-bit FAT etc and post
the findings. The idea is to get a version of this program that works
on all current versions of DOS.
Andy Tanenbaum
--------------------------- cut here --------------------------------
/*
* dosdir - list MS-DOS directories.
* doswrite - write stdin to DOS-file
* dosread - read DOS-file to stdout
*
* Author: Michiel Huisjes.
*
* Usage: dos... [-lra] drive [file/dir]
* l: Give long listing.
* r: List recursively.
* a: Set ASCII bit.
*/
#ifdef debug /* usually avoid stdio, what a nuisance */
#include <stdio.h>
#undef EOF /* one-off stdio redefines it different */
#endif
#include <sys/stat.h>
#define DRIVE "/dev/dosX"
#define DRIVE_NR 8
#define MAX_CLUSTER_SIZE 4096
#define MAX_ROOT_ENTRIES 512
#define FAT_START 512L /* After bootsector */
#define ROOTADDR (FAT_START + 2L * (long) fat_size)
#define clus_add(cl_no) ((long) (((long) cl_no - 2L) \
* (long) cluster_size \
+ data_start \
))
struct dir_entry {
unsigned char d_name[8];
unsigned char d_ext[3];
unsigned char d_attribute;
unsigned char d_reserved[10];
unsigned short d_time;
unsigned short d_date;
unsigned short d_cluster;
unsigned long d_size;
};
typedef struct dir_entry DIRECTORY;
#define NOT_USED 0x00
#define ERASED 0xE5
#define DIR 0x2E
#define DIR_SIZE (sizeof (struct dir_entry))
#define SUB_DIR 0x10
#define NIL_DIR ((DIRECTORY *) 0)
#define LAST_CLUSTER 0xFFFF
#define MASK 0xFF8
#define MASK16 0xFFF8
#define FREE 0x000
#define BAD 0xFF0
#define BAD16 0xFFF0
typedef char BOOL;
#define TRUE 1
#define FALSE 0
#define NIL_PTR ((char *) 0)
#define DOS_TIME 315532800L /* 1970 - 1980 */
#define READ 0
#define WRITE 1
#define disk_read(s, a, b) disk_io(READ, s, a, b)
#define disk_write(s, a, b) disk_io(WRITE, s, a, b)
#define get_fat(f, b) buf_read(FAT_START + f, b, 1)
#define put_fat(f, b) { disk_io(WRITE, FAT_START + f, b, 1); \
disk_io(WRITE, FAT_START + f + fat_size, b, 1);}
#define put_fat16(f, b) { disk_io(WRITE, FAT_START + f, b, 2); \
disk_io(WRITE, FAT_START + f + fat_size, b, 2);}
#define get_fat16(f, b) buf_read(FAT_START + f, b, 2)
#define FIND 3
#define LABEL 4
#define ENTRY 5
#define find_entry(d, e, p) directory(d, e, FIND, p)
#define list_dir(d, e, f) (void) directory(d, e, f, NIL_PTR)
#define label() directory(root, root_entries, LABEL, NIL_PTR)
#define new_entry(d, e) directory(d, e, ENTRY, NIL_PTR)
#define is_dir(d) ((d)->d_attribute & SUB_DIR)
#define EOF 0400
#define EOF_MARK '\032'
#define STD_OUT 1
#define flush() print(STD_OUT, NIL_PTR, 0)
short disk;
unsigned char fat_info;
DIRECTORY root[MAX_ROOT_ENTRIES];
DIRECTORY save_entry;
char null[MAX_CLUSTER_SIZE], device[] = DRIVE, path[128];
long data_start, mark;
unsigned short total_clusters, cluster_size, fat_size,
root_entries, sub_entries;
BOOL Rflag, Lflag, Aflag, dos_read, dos_write, dos_dir, fat_16 = 0;
char disk_written = 1, buf_buf[1025];
long buf_addr = 0;
DIRECTORY *directory(), *read_cluster();
unsigned short free_cluster(), next_cluster();
char *make_name(), *num_out(), *slash(), *brk();
long lseek(), time();
leave(nr)
short nr;
{
(void) umount(device);
exit(nr);
}
usage(prog_name)
register char *prog_name;
{
print_string(TRUE, "Usage: %s [%s\n", prog_name,
dos_dir ? "-lr] drive [dir]" : "-a] drive file");
exit(1);
}
unsigned c2u2( ucarray )
unsigned char *ucarray;
{
return ucarray[0] + (ucarray[1] << 8); /* parens vital */
}
determine()
{
struct dosboot {
unsigned char cjump[2]; /* unsigneds avoid bugs */
unsigned char nop;
unsigned char name[8];
unsigned char cbytepers[2]; /* don't use shorts, etc */
unsigned char secpclus; /* to avoid struct member */
unsigned char creservsec[2]; /* alignment and byte */
unsigned char fats; /* order bugs */
unsigned char cdirents[2];
unsigned char ctotsec[2];
unsigned char media;
unsigned char csecpfat[2];
unsigned char csecptrack[2];
unsigned char cheads[2];
unsigned char chiddensec[2];
/* char fill[482]; */
} boot;
unsigned short boot_magic; /* last of boot block */
unsigned bytepers, reservsec, dirents, totsec;
unsigned secpfat, secptrack, heads, hiddensec;
int errcount = 0;
/* read Bios-Parameterblock */
disk_read(0L, &boot, sizeof boot);
disk_read(0x1FEL, &boot_magic, sizeof boot_magic);
/* convert some arrays */
bytepers = c2u2(boot.cbytepers);
reservsec = c2u2(boot.creservsec);
dirents = c2u2(boot.cdirents);
totsec = c2u2(boot.ctotsec);
secpfat = c2u2(boot.csecpfat);
secptrack = c2u2(boot.csecptrack);
heads = c2u2(boot.cheads);
hiddensec = c2u2(boot.chiddensec);
/* calculate everything before checking for debugging print */
total_clusters = totsec / (boot.secpclus == 0 ? 1 : boot.secpclus);
cluster_size = bytepers * boot.secpclus;
fat_size = secpfat * bytepers;
data_start = (long)bytepers + (long)boot.fats * (long)fat_size
+ (long)dirents * 32L;
root_entries = dirents;
sub_entries = boot.secpclus * bytepers / 32;
if (total_clusters > 4096)
fat_16 = 1;
#ifdef debug
/* This used to help find foolish sign extensions and op precedences.
* It remains useful for looking at nonstandard formats.
*/
fprintf(stderr, "OEM = %8.8s\n", boot.name);
fprintf(stderr, "Bytes/sector = %u\n", bytepers);
fprintf(stderr, "Sectors/cluster = %u\n", boot.secpclus);
fprintf(stderr, "Number of Reserved Clusters = %u\n", reservsec);
fprintf(stderr, "Number of FAT's = %u\n", boot.fats);
fprintf(stderr, "Number of root-directory entries = %u\n", dirents);
fprintf(stderr, "Total sectors in logical volume = %u\n", totsec);
fprintf(stderr, "Media descriptor = 0x%02x\n", boot.media);
fprintf(stderr, "Number of sectors/FAT = %u\n", secpfat);
fprintf(stderr, "Sectors/track = %u\n", secptrack);
fprintf(stderr, "Number of heads = %u\n", heads);
fprintf(stderr, "Number of hidden sectors = %u\n", hiddensec);
fprintf(stderr, "Bootblock magic number = 0x%04x\n", boot_magic);
#endif
/* safety checking */
if (boot_magic != 0xAA55) {
print_string(TRUE, "magic != 0xAA55\n");
++errcount;
}
/* check sectors per track instead of inadequate media byte */
if (secptrack < 15 && /* assume > 15 hard disk & wini OK */
#ifdef SECT10 /* BIOS modified for 10 sec/track */
secptrack != 10 &&
#endif
#ifdef SECT8 /* BIOS modified for 8 sec/track */
secptrack != 8 &&
#endif
secptrack != 9) {
print_string(TRUE, "sectors per track not supported\n");
++errcount;
}
if (boot.secpclus == 0) {
print_string(TRUE, "sectors per cluster == 0\n");
++errcount;
}
if (boot.fats != 2 && dos_write) {
print_string (TRUE, "fats != 2\n");
++errcount;
}
if (reservsec != 1) {
print_string (TRUE, "reserved != 1\n");
++errcount;
}
if (cluster_size > MAX_CLUSTER_SIZE) {
print_string (TRUE, "cluster size too big\n");
++errcount;
}
if (errcount != 0) {
print_string (TRUE, "Can't handle disk\n");
leave (2);
}
}
main(argc, argv)
int argc;
register char *argv[];
{
register char *arg_ptr = slash(argv[0]);
DIRECTORY *entry;
short index = 1;
char dev_nr = '0';
unsigned char fat_check;
if (!strcmp(arg_ptr, "dosdir"))
dos_dir = TRUE;
else if (!strcmp(arg_ptr, "dosread"))
dos_read = TRUE;
else if (!strcmp(arg_ptr, "doswrite"))
dos_write = TRUE;
else {
print_string(TRUE, "Program should be named dosread, doswrite or dosdir.\n");
exit(1);
}
if (argc == 1)
usage(argv[0]);
if (argv[1][0] == '-') {
for (arg_ptr = &argv[1][1]; *arg_ptr; arg_ptr++) {
if (*arg_ptr == 'l' && dos_dir)
Lflag = TRUE;
else if (*arg_ptr == 'r' && dos_dir)
Rflag = TRUE;
else if (*arg_ptr == 'a' && !dos_dir)
Aflag = TRUE;
else
usage(argv[0]);
}
index++;
}
if (index == argc)
usage(argv[0]);
if ((dev_nr = (0x5f & *argv[index++])) < 'A' || dev_nr > 'Z')
usage(argv[0]);
device[DRIVE_NR] = dev_nr;
if ((disk = open(device, dos_write ? 2 : 0)) < 0) {
print_string(TRUE, "Cannot open %s\n", device);
exit(1);
}
disk_read(FAT_START, &fat_info, 1);
determine();
disk_read(FAT_START + (long) fat_size, &fat_check, sizeof(fat_check));
if (fat_check != fat_info) {
print_string(TRUE, "Disk type in FAT copy differs from disk type in FAT original.\n");
leave(1);
}
disk_read(ROOTADDR, root, DIR_SIZE * root_entries);
if (dos_dir && Lflag) {
entry = label();
print_string(FALSE, "Volume in drive %c ", dev_nr);
if (entry == NIL_DIR)
print(STD_OUT, "has no label.\n\n", 0);
else
print_string(FALSE, "is %S\n\n", entry->d_name);
}
if (argv[index] == NIL_PTR) {
if (!dos_dir)
usage(argv[0]);
if (Lflag)
print(STD_OUT, "Root directory:\n", 0);
list_dir(root, root_entries, FALSE);
if (Lflag)
free_blocks();
flush();
leave(0);
}
for (arg_ptr = argv[index]; *arg_ptr; arg_ptr++)
if (*arg_ptr == '\\')
*arg_ptr = '/';
else if (*arg_ptr >= 'a' && *arg_ptr <= 'z')
*arg_ptr += ('A' - 'a');
if (*--arg_ptr == '/')
*arg_ptr = '\0'; /* skip trailing '/' */
add_path(argv[index], FALSE);
add_path("/", FALSE);
if (dos_dir && Lflag)
print_string(FALSE, "Directory %s:\n", path);
entry = find_entry(root, root_entries, argv[index]);
if (dos_dir) {
list_dir(entry, sub_entries, FALSE);
if (Lflag)
free_blocks();
}
else if (dos_read)
extract(entry);
else {
if (entry != NIL_DIR) {
flush();
if (is_dir(entry))
print_string(TRUE, "%s is a directory.\n", path);
else
print_string(TRUE, "%s already exists.\n", argv[index]);
leave(1);
}
add_path(NIL_PTR, TRUE);
if (*path)
make_file(find_entry(root, root_entries, path),
sub_entries, slash(argv[index]));
else
make_file(root, root_entries, argv[index]);
}
(void) close(disk);
flush();
leave(0);
}
DIRECTORY *directory(dir, entries, function, pathname)
DIRECTORY *dir;
short entries;
BOOL function;
register char *pathname;
{
register DIRECTORY *dir_ptr = dir;
DIRECTORY *mem = NIL_DIR;
unsigned short cl_no = dir->d_cluster;
unsigned short type, last;
char file_name[14];
char *name;
int i = 0;
if (function == FIND) {
while (*pathname != '/' && *pathname && i < 12)
file_name[i++] = *pathname++;
while (*pathname != '/' && *pathname)
pathname++;
file_name[i] = '\0';
}
do {
if (entries != root_entries) {
mem = dir_ptr = read_cluster(cl_no);
last = cl_no;
cl_no = next_cluster(cl_no);
}
for (i = 0; i < entries; i++, dir_ptr++) {
type = dir_ptr->d_name[0] & 0x0FF;
if (function == ENTRY) {
if (type == NOT_USED || type == ERASED) {
if (!mem)
mark = ROOTADDR + (long) i * (long) DIR_SIZE;
else
mark = clus_add(last) + (long) i * (long) DIR_SIZE;
return dir_ptr;
}
continue;
}
if (type == NOT_USED)
break;
if (dir_ptr->d_attribute & 0x08) {
if (function == LABEL)
return dir_ptr;
continue;
}
if (type == DIR || type == ERASED || function == LABEL)
continue;
type = is_dir(dir_ptr);
name = make_name(dir_ptr, (function == FIND) ?
FALSE : type);
if (function == FIND) {
if (strcmp(file_name, name) != 0)
continue;
if (!type) {
if (dos_dir || *pathname) {
flush();
print_string(TRUE, "Not a directory: %s\n", file_name);
leave(1);
}
}
else if (*pathname == '\0' && dos_read) {
flush();
print_string(TRUE, "%s is a directory.\n", path);
leave(1);
}
if (*pathname) {
dir_ptr = find_entry(dir_ptr,
sub_entries, pathname + 1);
}
if (mem) {
if (dir_ptr) {
bcopy(dir_ptr, &save_entry, DIR_SIZE);
dir_ptr = &save_entry;
}
(void) brk(mem);
}
return dir_ptr;
}
else {
if (function == FALSE)
show(dir_ptr, name);
else if (type) { /* Recursive */
print_string(FALSE, "Directory %s%s:\n", path, name);
add_path(name, FALSE);
list_dir(dir_ptr, sub_entries, FALSE);
add_path(NIL_PTR, FALSE);
}
}
}
if (mem)
(void) brk(mem);
} while (cl_no != LAST_CLUSTER && mem);
switch (function) {
case FIND:
if (dos_write && *pathname == '\0')
return NIL_DIR;
flush();
print_string(TRUE, "Cannot find `%s'.\n", file_name);
leave(1);
case LABEL:
return NIL_DIR;
case ENTRY:
if (!mem) {
flush();
print_string(TRUE, "No entries left in root directory.\n");
leave(1);
}
cl_no = free_cluster(TRUE);
link_fat(last, cl_no);
link_fat(cl_no, LAST_CLUSTER);
disk_write(clus_add(cl_no), null, cluster_size);
return new_entry(dir, entries);
case FALSE:
if (Rflag) {
print(STD_OUT, "\n", 0);
list_dir(dir, entries, TRUE);
}
}
}
extract(entry)
register DIRECTORY *entry;
{
register unsigned short cl_no = entry->d_cluster;
char buffer[MAX_CLUSTER_SIZE];
short rest;
if (entry->d_size == 0) /* Empty file */
return;
do {
disk_read(clus_add(cl_no), buffer, cluster_size);
rest = (entry->d_size > (long) cluster_size) ? cluster_size : (short) entry->d_size;
print(STD_OUT, buffer, rest);
entry->d_size -= (long) rest;
cl_no = next_cluster(cl_no);
if (cl_no == (fat_16? BAD16: BAD)) {
flush();
print_string(TRUE, "Reserved cluster value encountered.\n");
leave(1);
}
} while (entry->d_size && cl_no != LAST_CLUSTER);
if (cl_no != LAST_CLUSTER)
print_string(TRUE, "Too many clusters allocated for file.\n");
else if (entry->d_size != 0)
print_string(TRUE, "Premature EOF: %L bytes left.\n",
entry->d_size);
}
print(fd, buffer, bytes)
short fd;
register char *buffer;
register short bytes;
{
static short index;
static BOOL lf_pending = FALSE;
static char output[MAX_CLUSTER_SIZE + 1];
if (buffer == NIL_PTR) {
if (dos_read && Aflag && lf_pending) {
output[index++] = '\r';
lf_pending = FALSE;
}
if (write(fd, output, index) != index)
bad();
index = 0;
return;
}
if (bytes == 0)
bytes = strlen(buffer);
while (bytes--) {
if (index >= MAX_CLUSTER_SIZE) {
if (write(fd, output, index) != index)
bad ();
index = 0;
}
if (dos_read && Aflag) {
if (*buffer == '\r') {
if (lf_pending)
output[index++] = *buffer++;
else {
lf_pending = TRUE;
buffer++;
}
}
else if (*buffer == '\n') {
output[index++] = *buffer++;
lf_pending = FALSE;
}
else if (lf_pending) {
output[index++] = '\r';
output[index++] = *buffer++;
}
else if ((output[index++] = *buffer++) == EOF_MARK) {
if (lf_pending) {
output[index - 1] = '\r';
index++;
lf_pending = FALSE;
}
index--;
return;
}
}
else
output[index++] = *buffer++;
}
}
make_file(dir_ptr, entries, name)
DIRECTORY *dir_ptr;
int entries;
char *name;
{
register DIRECTORY *entry = new_entry(dir_ptr, entries);
register char *ptr;
char buffer[MAX_CLUSTER_SIZE];
unsigned short cl_no, next;
short i, r;
long size = 0L;
bcopy(" ",&entry->d_name[0],11); /* clear entry */
for (i = 0, ptr = name; i < 8 && *ptr != '.' && *ptr; i++)
entry->d_name[i] = *ptr++;
while (*ptr != '.' && *ptr)
ptr++;
if (*ptr == '.')
ptr++;
for (i=0;i < 3 && *ptr; i++)
entry->d_ext[i] = *ptr++;
for (i = 0; i < 10; i++)
entry->d_reserved[i] = '\0';
entry->d_attribute = '\0';
entry->d_cluster = 0;
while ((r = fill(buffer)) > 0) {
if ((next = free_cluster(FALSE)) > total_clusters) {
print_string(TRUE, "Diskette full. File truncated.\n");
break;
}
disk_write(clus_add(next), buffer, r);
if (entry->d_cluster == 0)
cl_no = entry->d_cluster = next;
else {
link_fat(cl_no, next);
cl_no = next;
}
size += r;
}
if (entry->d_cluster != 0)
link_fat(cl_no, LAST_CLUSTER);
entry->d_size = Aflag ? (size - 1) : size; /* Strip added ^Z */
fill_date(entry);
disk_write(mark, entry, DIR_SIZE);
}
#define SEC_MIN 60L
#define SEC_HOUR (60L * SEC_MIN)
#define SEC_DAY (24L * SEC_HOUR)
#define SEC_YEAR (365L * SEC_DAY)
#define SEC_LYEAR (366L * SEC_DAY)
short mon_len[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
fill_date(entry)
DIRECTORY *entry;
{
register long cur_time = time((long *) 0) - DOS_TIME;
unsigned short year = 0, month = 1, day, hour, minutes, seconds;
int i;
long tmp;
if (cur_time < 0) /* Date not set on booting ... */
cur_time = 0;
for (;;) {
tmp = (year % 4 == 0) ? SEC_LYEAR : SEC_YEAR;
if (cur_time < tmp)
break;
cur_time -= tmp;
year++;
}
day = (unsigned short) (cur_time / SEC_DAY);
cur_time -= (long) day *SEC_DAY;
hour = (unsigned short) (cur_time / SEC_HOUR);
cur_time -= (long) hour *SEC_HOUR;
minutes = (unsigned short) (cur_time / SEC_MIN);
cur_time -= (long) minutes *SEC_MIN;
seconds = (unsigned short) cur_time;
mon_len[1] = (year % 4 == 0) ? 29 : 28;
i = 0;
while (day >= mon_len[i]) {
month++;
day -= mon_len[i++];
}
day++;
entry->d_date = (year << 9) | (month << 5) | day;
entry->d_time = (hour << 11) | (minutes << 5) | seconds;
}
char *make_name(dir_ptr, dir_fl)
register DIRECTORY *dir_ptr;
short dir_fl;
{
static char name_buf[14];
register char *ptr = name_buf;
short i;
for (i = 0; i < 8; i++)
*ptr++ = dir_ptr->d_name[i];
while (*--ptr == ' ');
ptr++;
if (dir_ptr->d_ext[0] != ' ') {
*ptr++ = '.';
for (i = 0; i < 3; i++)
*ptr++ = dir_ptr->d_ext[i];
while (*--ptr == ' ');
ptr++;
}
if (dir_fl)
*ptr++ = '/';
*ptr = '\0';
return name_buf;
}
fill(buffer)
register char *buffer;
{
static BOOL eof_mark = FALSE;
char *last = &buffer[cluster_size];
char *begin = buffer;
register short c;
if (eof_mark)
return 0;
while (buffer < last) {
if ((c = get_char()) == EOF) {
eof_mark = TRUE;
if (Aflag)
*buffer++ = EOF_MARK;
break;
}
*buffer++ = c;
}
return (int) (buffer - begin);
}
get_char()
{
static short read_chars, index;
static char input[MAX_CLUSTER_SIZE];
static BOOL new_line = FALSE;
if (new_line == TRUE) {
new_line = FALSE;
return '\n';
}
if (index == read_chars) {
if ((read_chars = read(0, input, cluster_size)) == 0)
return EOF;
index = 0;
}
if (Aflag && input[index] == '\n') {
new_line = TRUE;
index++;
return '\r';
}
return input[index++];
}
#define HOUR 0xF800 /* Upper 5 bits */
#define MIN 0x07E0 /* Middle 6 bits */
#define YEAR 0xFE00 /* Upper 7 bits */
#define MONTH 0x01E0 /* Mid 4 bits */
#define DAY 0x01F /* Lowest 5 bits */
char *month[] = {
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
};
modes(mode)
register unsigned char mode;
{
print_string(FALSE, "\t%c%c%c%c%c", (mode & SUB_DIR) ? 'd' : '-',
(mode & 02) ? 'h' : '-', (mode & 04) ? 's' : '-',
(mode & 01) ? '-' : 'w', (mode & 0x20) ? 'a' : '-');
}
show(dir_ptr, name)
DIRECTORY *dir_ptr;
char *name;
{
register unsigned short e_date = dir_ptr->d_date;
register unsigned short e_time = dir_ptr->d_time;
unsigned short next;
char bname[20];
short i = 0;
while (*name && *name != '/')
bname[i++] = *name++;
bname[i] = '\0';
if (!Lflag) {
print_string(FALSE, "%s\n", bname);
return;
}
modes(dir_ptr->d_attribute);
print_string(FALSE, "\t%s%s", bname, strlen(bname) < 8 ? "\t\t" : "\t");
i = 1;
if (is_dir(dir_ptr)) {
next = dir_ptr->d_cluster;
while ((next = next_cluster(next)) != LAST_CLUSTER)
i++;
print_string(FALSE, "%L", (long) i * (long) cluster_size);
}
else
print_string(FALSE, "%L", dir_ptr->d_size);
print_string(FALSE, "\t%N:%N %P %s %d\n", ((e_time & HOUR) >> 11),
((e_time & MIN) >> 5), (e_date & DAY),
month[((e_date & MONTH) >> 5) - 1], ((e_date & YEAR) >> 9) + 1980);
}
free_blocks()
{
register unsigned short cl_no;
long free = 0;
long bad = 0;
for (cl_no = 2; cl_no <= total_clusters; cl_no++) {
switch (next_cluster(cl_no)) {
case FREE:
free++;
break;
case BAD16:
bad++;
break;
case BAD:
if(!fat_16)
bad++;
}
}
print_string(FALSE, "Free space: %L bytes.\n", free * (long) cluster_size);
if (bad)
print_string(FALSE, "Bad sectors: %L bytes.\n", bad * (long) cluster_size);
}
char *num_out(number)
register long number;
{
static char num_buf[13];
char temp[13];
register short i = 0;
short j;
if (number == 0)
temp[i++] = '0';
while (number) {
temp[i++] = (char) (number % 10L + '0');
number /= 10L;
}
for (j = 0; j < 11; j++)
num_buf[j] = temp[i - j - 1];
num_buf[i] = '\0';
return num_buf;
}
/* VARARGS */
print_string(err_fl, fmt, args)
BOOL err_fl;
char *fmt;
int args;
{
char buf[200];
register char *buf_ptr = buf;
char *scan_ptr;
register int *arg_ptr = &args;
short i;
while (*fmt) {
if (*fmt == '%') {
fmt++;
if (*fmt == 'c') {
*buf_ptr++ = (char) *arg_ptr++;
fmt++;
continue;
}
if (*fmt == 'S') {
scan_ptr = (char *) *arg_ptr;
for (i = 0; i < 11; i++)
*buf_ptr++ = *scan_ptr++;
fmt++;
continue;
}
if (*fmt == 's')
scan_ptr = (char *) *arg_ptr;
else if (*fmt == 'L') {
scan_ptr = num_out(*((long *) arg_ptr));
arg_ptr++;
}
else {
scan_ptr = num_out((long) *arg_ptr);
if (*fmt == 'P' && *arg_ptr < 10)
*buf_ptr++ = ' ';
else if (*fmt == 'N' && *arg_ptr < 10)
*buf_ptr++ = '0';
}
while (*buf_ptr++ = *scan_ptr++);
buf_ptr--;
arg_ptr++;
fmt++;
}
else
*buf_ptr++ = *fmt++;
}
*buf_ptr = '\0';
if (err_fl) {
flush();
write(2, buf, (int) (buf_ptr - buf));
}
else
print(STD_OUT, buf, 0);
}
DIRECTORY *read_cluster(cluster)
register unsigned short cluster;
{
register DIRECTORY *sub_dir;
extern char *sbrk();
if ((sub_dir = (DIRECTORY *) sbrk(cluster_size)) < 0) {
print_string(TRUE, "Cannot set break!\n");
leave(1);
}
disk_read(clus_add(cluster), sub_dir, cluster_size);
return sub_dir;
}
unsigned short free_cluster(leave_fl)
BOOL leave_fl;
{
static unsigned short cl_index = 2;
while (cl_index <= total_clusters && next_cluster(cl_index) != FREE)
cl_index++;
if (leave_fl && cl_index > total_clusters) {
flush();
print_string(TRUE, "Diskette full. File not added.\n");
leave(1);
}
return cl_index++;
}
link_fat(cl_1, cl_2)
unsigned short cl_1;
register unsigned short cl_2;
{
register unsigned fat_index;
unsigned char pad;
unsigned pad16;
if(fat_16) {
pad16 = cl_2;
put_fat16((long)(cl_1 << 1), &pad16);
return;
}
fat_index = (cl_1 >> 1) * 3 + 1;
if (cl_1 & 0x01) {
pad = cl_2 >> 4;
put_fat((long)(fat_index + 1), &pad);
get_fat((long)fat_index, &pad);
pad = (pad & 0x0F) | ((cl_2 & 0x0F) << 4);
put_fat((long)fat_index, &pad);
}
else {
pad = cl_2;
put_fat((long)(fat_index - 1), &pad);
get_fat((long)fat_index, &pad);
pad = (pad & 0xF0) | (0xf & (cl_2 >> 8));
put_fat((long)fat_index, &pad);
}
}
unsigned short next_cluster(cl_no)
register unsigned short cl_no;
{
register unsigned fat_index;
unsigned char pad;
unsigned pad16;
unsigned mask = MASK16;
unsigned bad = BAD16;
if(!fat_16) {
fat_index = (cl_no >> 1) * 3 + 1;
get_fat((long)fat_index, &pad);
if (cl_no & 0x01) {
pad16 = 0x0f & (pad >> 4);
get_fat((long)(fat_index + 1), &pad);
cl_no = (((short)pad) << 4) | pad16;
}
else {
pad16 = (0x0f & pad) << 8;
get_fat((long)(fat_index - 1), &pad);
cl_no = (short)pad | pad16;
}
mask = MASK;
bad = BAD;
}
else {
get_fat16((long)(cl_no << 1), &pad16);
cl_no = pad16;
}
if ((cl_no & mask) == mask)
cl_no = LAST_CLUSTER;
else if ((cl_no & bad) == bad)
cl_no = bad;
return cl_no;
}
char *slash(str)
register char *str;
{
register char *result = str;
while (*str)
if (*str++ == '/')
result = str;
return result;
}
add_path(file, slash_fl)
register char *file;
BOOL slash_fl;
{
register char *ptr = path;
while (*ptr)
ptr++;
if (file == NIL_PTR) {
if(ptr != path)
ptr--;
if(ptr != path) do {
ptr--;
} while (*ptr != '/' && ptr != path);
if (ptr != path && !slash_fl)
*ptr++ = '/';
*ptr = '\0';
}
else
while (*ptr++ = *file++);
}
bcopy(src, dest, bytes)
register char *src, *dest;
short bytes;
{
while (bytes--)
*dest++ = *src++;
}
disk_io(op, seek, address, bytes)
register BOOL op;
unsigned long seek;
DIRECTORY *address;
register unsigned bytes;
{
unsigned int r;
if (lseek(disk, seek, 0) < 0L) {
flush();
print_string(TRUE, "Bad lseek\n");
leave(1);
}
if (op == READ)
r = read(disk, address, bytes);
else {
disk_written = 1;
r = write(disk, address, bytes);
}
if (r != bytes)
bad();
}
bad()
{
flush();
perror("I/O error");
leave(1);
}
buf_read(seek, b, c)
long seek;
register char *b;
int c;
{
if(disk_written || (seek & (~0x3ffL)) != buf_addr) {
disk_written = 0;
disk_io(READ, buf_addr = seek & (~0x3ffL), buf_buf, 1025);
}
seek &= 0x3ffL;
*b++ = buf_buf[seek++];
if(c == 2)
*b = buf_buf[seek];
}
------------------------------------- cut here -----------------------ronald@ibmpcug.co.uk (Ronald Khoo) (10/14/89)
[about reading/writing messDOS floppies formatted under Xenix] In article <3717@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > Here is a (hopefully) improved version of dos/read/write.dir. Could DOS > users please try it on floppies, HD, 12-bit FAT, 16-bit FAT etc and post > the findings. The idea is to get a version of this program that works > on all current versions of DOS. Hi Andy... I'm not a messDOS user, but since Xenix is another macrohard product, I thought that would almost count :-) So here are my results running your dosdir under SCO Xenix 2.3.1 with a floppy formatted under the same OS. After linking /dev/dsk/f0q15dt to /dev/dosX, I get: /tmp/dosdir X OEM = SCO BOOT Bytes/sector = 512 Sectors/cluster = 1 Number of Reserved Clusters = 1 Number of FAT's = 2 Number of root-directory entries = 224 Total sectors in logical volume = 2400 Media descriptor = 0xf9 Number of sectors/FAT = 7 Sectors/track = 15 Number of heads = 2 Number of hidden sectors = 0 Bootblock magic number = 0x0000 magic != 0xAA55 Can't handle disk Interesting that this has never stopped me using floppies formatted under SCO Xenix before. Is dos{read,write,dir) the only program in the world that checks the magic number? Interessant.... The rest of the stuff looks approximately reasonable to me, let me take out the sanity check, hang on.. OK it's got no files, let me put a couple on.. hmmm.. seems to work. Does your /dev/dos? do something that my /dev/dsk/f0q15dt doesnt? Seems unlikely somehow... Does this prove anything ? -- Ronald.Khoo@ibmpcug.CO.UK (The IBM PC User Group, PO Box 360, Harrow HA1 4LQ) Path: ...!ukc!slxsys!ibmpcug!ronald Phone: +44-1-863 1191 Fax: +44-1-863 6095 $Header: /users/ronald/.signature,v 1.1 89/09/03 23:36:16 ronald Exp $ :-)
ast@cs.vu.nl (Andy Tanenbaum) (10/15/89)
In article <3a18.2536ede8@ibmpcug.co.uk> ronald@ibmpcug.co.uk (Ronald Khoo) writes: >Does this prove anything ? Not to me. My knowledge of DOS is zilch, and will stay that way. Thus I leave the debugging of dosread.c to the net. Since I never use DOS and do not own any DOS files, I don't care much whether it works or not, but if there is someone who does care, by all means try it and if there are problems, try to fix them. Andy Tanenbaum
evans@ditsyda.oz (Bruce Evans) (10/16/89)
In article <3a18.2536ede8@ibmpcug.co.uk> ronald@ibmpcug.co.uk (Ronald Khoo) writes: >magic != 0xAA55 >Can't handle disk > >Interesting that this has never stopped me using floppies formatted under >SCO Xenix before. Is dos{read,write,dir) the only program in the world Sorry about that. Even DOS doesn't check this particular magic number. It probably only belongs on *bootable* disks. DOS 3.3 requires it for bootable hard disk partitions at least. Sun 386i's are reported to require it for bootable floppies. So you can delete the test, and the program should be changed to check some other magic numbers (probably just the consistency of the parameter block). -- Bruce Evans evans@ditsyda.oz.au
cramer@optilink.UUCP (Clayton Cramer) (10/17/89)
In article <3721@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <3a18.2536ede8@ibmpcug.co.uk> ronald@ibmpcug.co.uk (Ronald Khoo) writes: > >Does this prove anything ? > > Not to me. My knowledge of DOS is zilch, and will stay that way. Thus I > leave the debugging of dosread.c to the net. Since I never use DOS and do > not own any DOS files, I don't care much whether it works or not, but if > there is someone who does care, by all means try it and if there are problems, > try to fix them. > > Andy Tanenbaum This posting is really the definitive statement of disdain for DOS. "My knowledge of DOS is zilch, and will stay that way." For anyone to make such a statement, along with the contempt shown in the rest of the posting, provides all the evidence needed that elitism has a lot more to do with DOS-hatred than anything else. I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters would make appropriate criticisms of the many very real deficiencies of DOS, and leave it at that. But as long as someone can learn to use a computer without devoting years of their life to it, the DOS-haters will remain filled with irrational hatred. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Human rights are non-negotiable -- respect the Bill of Rights, or you'll soon find out why the Second Amendment guarantees the right to keep and bear arms. Disclaimer? You must be kidding! No company would hold opinions like mine!
ok@cs.mu.oz.au (Richard O'Keefe) (10/20/89)
In article <2501@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) writes: > I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters > would make appropriate criticisms of the many very real deficiencies > of DOS, and leave it at that. But as long as someone can learn to > use a computer without devoting years of their life to it, the > DOS-haters will remain filled with irrational hatred. Learn to use a computer without devoting years to it? He must be talking about Macintoshes. DOS-hatred has a heck of a lot to do with DOS and nothing at all to do with who uses it. Common people can be taught how to use UNIX (or MINIX) quite effectively, as long as you tell them how to do what _they_ want to do and don't try to make hackers of them. I just read a review of the Norton Utilities in New Scientist; the author of the review doesn't appear to be a hacker, but he was raving about being able to attach meaningful strings to files so that he could tell which of NSREVA, NSREVB and so on held which review. "Irrational" hatred?
ast@cs.vu.nl (Andy Tanenbaum) (10/20/89)
>> My knowledge of DOS is zilch, and will stay that way. >> My knowledge of Tiny BASIC is zilch, and will stay that way. >> My knowledge of VMS is zilch, and will stay that way. >> My knowledge of OS/360 is zilch, and will stay that way. >> My knowledge of FORTRAN 9x is zilch, and will stay that way. The worst part of it is that I am not even ashamed at all. Andy Tanenbaum (ast@cs.vu.nl)
henry@utzoo.uucp (Henry Spencer) (10/21/89)
In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: >I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters >would make appropriate criticisms of the many very real deficiencies >of DOS, and leave it at that. But as long as someone can learn to >use a computer without devoting years of their life to it, the >DOS-haters will remain filled with irrational hatred. The common people make essentially no use of DOS; they just use it to load programs that take over the whole machine and largely ignore DOS. Learning to use DOS itself -- especially the fine points of the file system, which is what this discussion was about -- *does* take lots of work. And it's not worth the trouble for most people, which is exactly what Andy was getting at. Hatred of DOS is entirely rational, and has nothing to do with who else uses it. There are ample reasons to despise that feeble excuse for an operating system. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (10/21/89)
In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: > I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters > would make appropriate criticisms of the many very real deficiencies > of DOS, and leave it at that. But as long as someone can learn to > use a computer without devoting years of their life to it, the > DOS-haters will remain filled with irrational hatred. Oh, fiddlesticks. If this was the case then the Macintosh would be the computer everyone feels disdain for. Making effective use of a DOS machine is much, much harder than making effective use of a Mac. But us slimey elitists merely point out the fery real deficiencies of the Mac and leave it at that. Why? Largely because where the Mac is limited by its origins, DOS is limited by deliberate malice on the part of IBM and Microsoft. (yes, I know that a corporation can't feel malice, but if you trust the Turing test there is no better phrase for the behaviour of these companies) -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "ERROR: trust not in UUCP routing tables" 'U` -- MAILER-DAEMON@mcsun.EU.net
webb@uhccux.uhcc.hawaii.edu (Thomas Webb) (10/21/89)
In article <1989Oct20.170447.19573@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: >>I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters >>would make appropriate criticisms of the many very real deficiencies >>of DOS, and leave it at that. But as long as someone can learn to >>use a computer without devoting years of their life to it, the >>DOS-haters will remain filled with irrational hatred. > >The common people make essentially no use of DOS; they just use it to load >programs that take over the whole machine and largely ignore DOS. Learning >to use DOS itself -- especially the fine points of the file system, which >is what this discussion was about -- *does* take lots of work. And it's not >worth the trouble for most people, which is exactly what Andy was getting at. > >Hatred of DOS is entirely rational, and has nothing to do with who else >uses it. There are ample reasons to despise that feeble excuse for an >operating system. Hey folks, this isn't a class strugle. I program at the DOS level nearly every day and Henry is right, it does take a bit of work to learn about 80x86 assembly language and DOS, and a lot of times you end-up by-passing the operating system to get decent results anyway. So, in a sence, DOS isn't much of an operating system. On the other hand, it does do a pretty good job of organising files and loding programs. It is fast and small. For those of us who still have to put-up with slow 8088 PC' speed is the bottom line. Also, those of us on tight personal budgets can get a complete DOS development system for about $1500, $1000 for the machine and $500 for a very complete set of development software. It costs more than that just to get a unix development package, plus the hardware needed to run unix is far more expensive. The moral here is that while DOS is undeniably feeble, it works very well in a low cost, low power environment. BTW, it isn't easy to learn to program in DOS, but it is even harder to program in 'real' operating systems at the OS level. At least you can get a good book on DOS programing, God help you if you need a quick function reference and programing primer for unix. Anyway, my feeling is that people who hate DOS are comparing it to OSes that cost a lot more and run on more expensive platforms. This is an apples and oranges type problem, not a class struggle. PS Henry, I teach 'common people' about unix as part of my job, and most of them don't want to know anthing more then how to load SPSS or whatever anyway. Maybe DOS has all they need? -tom -- =============================================================================== webb@uhccux.uhcc.Hawaii.edu ===============================================================================
chan@eeserv (Andrew Chan) (10/21/89)
In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: > >I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters >would make appropriate criticisms of the many very real deficiencies >of DOS, and leave it at that. But as long as someone can learn to >use a computer without devoting years of their life to it, the >DOS-haters will remain filled with irrational hatred. >-- How about the Mac? Do you hate the Mac OS Andy? :-) I am yet another COMMON PERSON but I do hate DOS. I wish Minix could be more powerful as a multi-user system. I want to run a BBS but don't want it to be yet another MS-DOS bbs. I want an Unix board but cannot afford the money they want for Unix/Xenix. By the way, I have an 12 Mhz AT clone and I am very reluctant to commit myself on 286 Unix/Xenix. I am afraid that the vendors will soon abandon supporting 286 Unix/Xenix as 386's become cheaper. Any suggestion from the net?
ast@cs.vu.nl (Andy Tanenbaum) (10/22/89)
In article <1989Oct21.013342.2168@ccu.umanitoba.ca> chan@eeserv.ee.umanitoba.ca (Andrew Chan) writes: >How about the Mac? Do you hate the Mac OS Andy? :-) Does it even have anOS? The Mac seems to have a niche. Our secretaries and the pure mathematicians love them. I ascribe this to limited power of abstraction. >I wish Minix could be more powerful as a multi-user system. I am curious about what this means. Is MINIX slower than XENIX (probably)? Has fewer features (Thank Goodness)? What is it that it lacks? This is a purely academic question, since sight unseen I am against the answer :-(. Andy Tanenbaum (ast@cs.vu.nl)
gdtltr@vax1.acs.udel.EDU (Gary D Duzan) (10/22/89)
In article <1989Oct21.013342.2168@ccu.umanitoba.ca> chan@eeserv.ee.umanitoba.ca (Andrew Chan) writes: =>In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: =>> =>>I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters =>>would make appropriate criticisms of the many very real deficiencies =>>of DOS, and leave it at that. But as long as someone can learn to =>>use a computer without devoting years of their life to it, the =>>DOS-haters will remain filled with irrational hatred. =>>-- => =>How about the Mac? Do you hate the Mac OS Andy? :-) I am yet another COMMON =>PERSON but I do hate DOS. I wish Minix could be more powerful as a multi-user =>system. I want to run a BBS but don't want it to be yet another MS-DOS bbs. =>I want an Unix board but cannot afford the money they want for Unix/Xenix. => =>By the way, I have an 12 Mhz AT clone and I am very reluctant to commit myself =>on 286 Unix/Xenix. I am afraid that the vendors will soon abandon supporting =>286 Unix/Xenix as 386's become cheaper. => =>Any suggestion from the net? Here's one: lets move this to alt.religion.computers. No need to clutter comp.os.minix. Gary Duzan Time Lord Third Regeneration -- _o_ _o_ [|o o|] "Two hearts are better than one." -- Yes [|o o|] |_O_| "Don't listen to me; I never do." -- Doctor Who |_O_|
jca@pnet01.cts.com (John C. Archambeau) (10/22/89)
cramer@optilink.UUCP (Clayton Cramer) writes: >This posting is really the definitive statement of disdain for DOS. >"My knowledge of DOS is zilch, and will stay that way." For anyone >to make such a statement, along with the contempt shown in the rest >of the posting, provides all the evidence needed that elitism has >a lot more to do with DOS-hatred than anything else. AST isn't the only one that hates MeSs-DOS. Meet another 'DOS hater' here and most of our claims for hatred of MeSs-DOS are very well justified considering its fatal flaws. It took how long for Micro$haft to break the 32 Mb problem with DOS? And I'm not even sure that 4.x does it all that well either. Now everybody is trying to break the 640K memory problem, well, it ain't going to happen because of the fact DOS was designed around an 8086 address space. Big bucks are in it for ANY company that makes a 100% (not 80%, 90%, or 95%) compatable 386 protect mode implementation of DOS. They are close with things such as VP/ix, but it's not close enough. I personally think that DOS will be chucked eventually since it doesn't even utilitize the power of a 386. >I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters >would make appropriate criticisms of the many very real deficiencies >of DOS, and leave it at that. But as long as someone can learn to >use a computer without devoting years of their life to it, the >DOS-haters will remain filled with irrational hatred. I know a lot of common people who will use *nix before even turning on an IBM clone/compatable. My boss only uses his IBM AT with a 40 Mb hard drive as a rolodex under SideKick. My boss' partner doesn't even like the letters IBM and is about as technically minded as Dan Quayle is informed of the state of the union and he prefers *nix based systems. Hell, I have to kick him off the SPARCstation 1 just for routine file system maintainance. DOS for common people? Maybe in the past and possibly the present, but now we have chips out there that DOS can't even push to the limit because of its design flaws. If I ever manage to get Bill Gates' business card, it's going on my dart board. ;) /*--------------------------------------------------------------------------* * Flames: /dev/null (on my Minix partition) *--------------------------------------------------------------------------* * ARPA : crash!pnet01!jca@nosc.mil * INET : jca@pnet01.cts.com * UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca *--------------------------------------------------------------------------* * Note : My opinions are that...mine. My boss doesn't pay me enough to * speak in the best interests of the company (yet). *--------------------------------------------------------------------------*/
henry@utzoo.uucp (Henry Spencer) (10/22/89)
In article <5182@uhccux.uhcc.hawaii.edu> webb@uhccux.UUCP (Thomas Webb) writes: >... The moral here is that while DOS is undeniably >feeble, it works very well in a low cost, low power environment. Actually, Unix used to work pretty well in equally low-power environments. (Similarly slow CPUs, slightly better disks, far less memory, poorer I/O.) >PS >Henry, I teach 'common people' about unix as part of my job, and most >of them don't want to know anthing more then how to load SPSS or >whatever anyway. Maybe DOS has all they need? Until they want to know why their DOS programs can't use any more than 640K of memory even though their 386 box has 2MB, that is. DOS's mistakes have very little impact on canned-program users directly, but it gets its licks in indirectly, by making life harder for the application programs. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mju@mudos.ann-arbor.mi.us (Marc Unangst) (10/22/89)
In article <3767@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1989Oct21.013342.2168@ccu.umanitoba.ca> chan@eeserv.ee.umanitoba.ca (Andrew Chan) writes: >>I wish Minix could be more powerful as a multi-user system. >I am curious about what this means. Is MINIX slower than XENIX (probably)? >Has fewer features (Thank Goodness)? What is it that it lacks? This is a >purely academic question, since sight unseen I am against the answer :-(. I'm not Andrew Chan, but I can tell you the things MINIX lacks that it should have: * Full support for "large model" programs. I realize this would be difficult to add, but there are a lot of "real programs" out there that would be difficult or impossible to support because they have more than 64K of code. Rn, for example, or nethack, or Elm. * Some sort of virtual memory. I don't really care if this is demand-paging or swapping or whatever (and don't know enough to choose which one would be best), and I realize that this, too, would be difficult to impliment (especially if you also impliment large-model programs), but it's really needed. I have a 640K system, and it's silly to run out of memory when all you have running is cron(1) and cc(1). * A real shell. I've often had to pull apart shell archives by hand, because the MINIX shell chokes on them. In particular, I think the 'Configure' script included with most Larry Wall software makes MINIX puke because MINIX doesn't properly impliment the 'eval' command. * A version of UUCP. GNUUCP probably wouldn't be hard to port (it's written with portability in mind), but you might run into the 64K wall. * A real version of mail(1). Actually, I'm not even sure if MINIX comes with *any* version of mail(1), since I haven't gotten 1.4a running yet. If it doesn't, this is a major flaw. * Ability to put / somewhere other than a ramdisk. I have a hard disk, and I suspect many other "serious" MINIX users do also. Putting the root filesystem in RAM seriously handicaps users who have hard disks, users who would be happy to give up 400K or so of disk space in order to free up that RAM; 270K is over one third of the PC's total accessable memory. I don't think we'll suffer a large speed hit if MINIX has to go to a hard disk to read stuff from /bin or whatever, and I *know* I'd rather have the RAM than the speed. Users who are running floppy-only could always enable the ramdisk through a compile-time option or by booting off a different boot disk. This would also prevent the mistakes that happen when you update a file on the root filesystem (in RAM) but forget to update the root disk, thus losing the changes when you re-boot. * Ability to boot off the hard disk. This follows directly from the previous statement; IMHO, the only things floppies should be used for are backups and transferring files between systems. If you can store the root filesystem on the hard disk, you ought to be able to boot from it. "Protection against the hard disk getting trashed" is a poor excuse; you can always haul out the floppy if something goes seriously wrong, and then just mount /dev/hd1 or whatever. * "Real" job control. I'm not sure what this is, but I *do* know that I sorely miss the ability to suspend jobs, move them from the foreground to the background and back again, etc. that I have on my Sun-3. * The ability to format floppies from within MINIX. As I understand it, right now the only reason to keep DOS around is because you have to format floppies with it before you can use them with MINIX. This is silly; an OS should be self-sufficient. Plus, it will mean (with the addition of the above suggestion, job control) that if you run out of floppies in the middle of a backup, you can just suspend the job, format some more, and pick up where you left off. You won't have to quit, start up DOS, format some more, and then restart both MINIX and the backup. * The addition of "real" backup software. Does MINIX 1.4a have dump and restor? If not, why? If so, you can ignore this point... I think the problem with the 64K code-size limit (which you have, even if you use the split I&D asld) is what hampers most program development. I'm all for the "small is beautiful" way of life, but there are just some things that *cannot* be expressed in only 64K. I think we'll all agree that Nethack is a great game (I certainly think so, and its popularity speaks for itself), but the thing is much too big to port to MINIX. (It's probably much too big to be running on an 8088 pseudo-Unix machine, anyhow, but that's just an example.) I'll be the first to admit that most of these changes won't be easy, especially adding job control (which Andy has said would require major changes to most of the OS). I'll also be the first to admit that I probably couldn't do any of them, and am really in awe of the OS that we have all created. However, it can be made even better...With the addition of these changes (or at least most of them), I might consider eliminating DOS entirely from my machine. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832
peter@ficc.uu.net (Peter da Silva) (10/22/89)
In article <5182@uhccux.uhcc.hawaii.edu> webb@uhccux.UUCP (Thomas Webb) writes: > Also, those > of us on tight personal budgets can get a complete DOS development > system for about $1500, $1000 for the machine and $500 for a very > complete set of development software. Fiddlesticks. (I'm saying that a lot lately. It's a lot more polite than what I'm thinking) You can get an Amiga development system for about that, and you get a real operating system with a message-based kernel, multitasking, windowing, and a decent base of commercial programs (yes, only a couple of the spreadsheets are 1-2-3 compatible. Shucks). Or of you don't care whether you can run commercial software, you can get your IBM-PC or an Atari ST with MINIX (have a look at the first group on the newsgroups line again). You will soon be able to get MINIX for the Amiga, though why you'd want to I don't know. For a little more money you can get a Macintosh, with a vast array of commercial software. The system software is pretty psychotic, but it's a hell of a lot better than DOS. > BTW, it isn't easy to learn to program in DOS, but it is even harder > to program in 'real' operating systems at the OS level. No, it's not. The DOS system calls are a proper subset of the UNIX system calls. The names and calling arguments are, in most cases, the same within two decimal places. Just about everyone (Microsoft included) has discovered the UNIX programming model by now. > Anyway, my feeling is that people who hate DOS are comparing it to > OSes that cost a lot more and run on more expensive platforms. This > is an apples and oranges type problem, not a class struggle. No, it's an apples-and-apples comparison. There are plenty of low-cost alternatives to DOS, even on 8088-based machines. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "ERROR: trust not in UUCP routing tables" 'U` -- MAILER-DAEMON@mcsun.EU.net
ast@cs.vu.nl (Andy Tanenbaum) (10/22/89)
In article <695.254152F7@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >I'm not Andrew Chan, but I can tell you the things MINIX lacks [Summarized] 1. Large model. A real ugly hack forced by the brain damaged Intel architecture. MINIX doesn't inherently have an 64K limit. On the Atari you can have programs as large as physical memory. I expect the arrival of the 386SX will spell the end of the 8088 and 80286 within a couple of years. At that point we can adopt a single linear 32-bit address space, like MINIX-ST. 2. Virtual memory. I tend to regard this as obsolete. With Bruce Evans' protected mode kernel and a 2M 386 you can have up to 2M of programs running at once. That has to be enough for a personal computer. Thus I see virtual memory as something with a lifespan limited to the older machines, which will probably be gone in a couple of years. 3. A real shell. The shell is pretty much the Bourne shell. If it has bugs, please try to fix them. No conceptual problem there. You may have an old version. I have extracted some pretty large shell files. Make sure you have enough stack (chmem). 4. UUCP. I believe Peter Housel posted something along this line (uupc). 5. Mail. There actually is a mail program, but it is only for local mail at the moment. I'll (re)post it as part of 1.4b. 6. Root on hard disk. That is already in as of 1.4a and will stay in. 7. Boot off hard disk. I suppose it is possible, but a low priority item. Many people still use DOS and want to have the hard disk boot start DOS. You can't have it both ways. 8. Job control. No way. Too messy. Maybe virtual screens next time. 9. A format program. I'd love it. Any volunteers? 10. Backup. There is no dump/restore, but I wrote a program called backup.c and posted it. I use it all the time and find it quite adequate. You give it the name of a directory and put a floppy in the drive, and it looks for files that have changed since the last backup and saves them all. I even have a shell script that calls the program with the right flags (which I posted). Conclusion >> With the addition of these changes (or at least most >> of them), I might consider eliminating DOS entirely from my machine. I find this a bit odd. As far as I can see, the scorecard is: Item DOS MINIX 1. Large model Yes No 2. Virtual memory No No 3. Real shell No Almost 4. UUCP No UUPC 5. Mail No No (except local mail) 6. Root on HD Yes Yes 7. Boot off HD Yes No 8. Job control No No 9. Formatter Yes No 10. Dump/restore No No (although I think 'backup' is better) If one is willing to concede that the Bourne shell is close enough, and accept UUPC, it looks like the score is 4 to 4. I can easily understand someone saying "Until MINIX gets virtual memory I'll stick with XENIX," but the list above (except for large model, doesn't really put DOS in that great a light either). And things like multiuser, multiprogramming, ability to use 16M memory, etc. aren't really strong points for DOS either. Andy Tanenbaum (ast@cs.vu.nl)
ok@cs.mu.oz.au (Richard O'Keefe) (10/23/89)
In article <3768@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > 2. Virtual memory. I tend to regard this as obsolete. With Bruce Evans' > protected mode kernel and a 2M 386 you can have up to 2M of programs > running at once. That has to be enough for a personal computer. Um. I'm using a machine with 4M. The manufacturer doesn't make them that small any more. Let's just stop and calculate for a second. How big a square matrix of IEEE doubles will fit into 2M? N**2 * 8 = 2 * 1024**2 means N = 512. (The "2M of programs running at once" has to include the data they are currently working with!) Ok, linear programming on a personal computer is out. How about Lisp? Well, 'size $OAKLISP' reckons the total is 400k, and the bootfile it loads is another 400k. So that lets me run two programs the size of OakLisp on a personal computer. Not a lot. GNU Emacs runs fine on 386/UNIX systems with 4M of memory, but you don't really stand a chance on 2M without VM. Heck, even Jove starts at around 300k. How big is a statistics package like GENSTAT or S? Is there any reason why I _shouldn't_ want to run them on a "personal computer"? "2M has to be enough for a personal computer"? I'm not knocking Minix. Nobody ever claimed that Minix was the answer to everyone's needs. There are other more urgent things to do to Minix. (Like upgrading the ST version. It just so happens that I have an ST at home...) There are good reasons for not doing VM for a while (like not putting more 80*86 dependencies in and leaving the ST further behind...). But "2M has to be enough for a personal computer" is not a good reason.
chasm@attctc.Dallas.TX.US (Charles Marslett) (10/23/89)
In article <1989Oct20.170447.19573@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: > >I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters > >would make appropriate criticisms of the many very real deficiencies > >of DOS, and leave it at that. But as long as someone can learn to > >use a computer without devoting years of their life to it, the > >DOS-haters will remain filled with irrational hatred. > > The common people make essentially no use of DOS; they just use it to load > programs that take over the whole machine and largely ignore DOS. Learning > to use DOS itself -- especially the fine points of the file system, which > is what this discussion was about -- *does* take lots of work. And it's not > worth the trouble for most people, which is exactly what Andy was getting at. I might point out that perhaps 1% of all users of the Unix operating system and its various imitators probably have any interest at all in the fine points of that file system. And I believe it was Dennis Ritchie himself who noted that Unix was a nice file system with a rudimentary OS attached (pardon the paraphrase). And neither point keeps people from using it. So the fact that DOS is a nice file system (and I disagree with anyone who says otherwise -- it is well suited for the tasks most of its users put it to) with virtually no OS attached is not to say it is inadequate. > Hatred of DOS is entirely rational, and has nothing to do with who else > uses it. There are ample reasons to despise that feeble excuse for an > operating system. > -- > A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology > megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Henry, please read your little note here. Some might take your comments to be a bit of fire from the north! Charles Marslett (author of two DOSes somewhat more primative than Microsoft's) chasm@attctc.dallas.tx.us
chasm@attctc.Dallas.TX.US (Charles Marslett) (10/23/89)
In article <1989Oct22.003554.24199@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <5182@uhccux.uhcc.hawaii.edu> webb@uhccux.UUCP (Thomas Webb) writes: > >... The moral here is that while DOS is undeniably > >feeble, it works very well in a low cost, low power environment. > > Actually, Unix used to work pretty well in equally low-power environments. > (Similarly slow CPUs, slightly better disks, far less memory, poorer I/O.) Come on, I used to work on such machines (PDP-11s, even the older VAXen) and they were dogs under Unix. Why do you think so many people used (use?) VMS? It is still around, isn't it? Unix on a fast 11 might support a compile and two edits. And the total clock time was comparable to that of a 10 MHz 286 with Xenix. For that matter, I think Turbo C would do the whole thing twice as fast with the same hardware. AND YOU SEEM TO HAVE MISSED THE PHRASE: low cost. > >PS > >Henry, I teach 'common people' about unix as part of my job, and most > >of them don't want to know anthing more then how to load SPSS or > >whatever anyway. Maybe DOS has all they need? > > Until they want to know why their DOS programs can't use any more than > 640K of memory even though their 386 box has 2MB, that is. DOS's mistakes > have very little impact on canned-program users directly, but it gets its > licks in indirectly, by making life harder for the application programs. Yes, and try to explain why AutoCAD takes 2 MB under DOS, 4 MB under OS/2 and 7 MB under Xenix to get the same performance. Again, life can be easier (as in the Mac world), but you pay for it. > -- > A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology > megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Charles chasm@attctc.dallas.tx.us
chasm@attctc.Dallas.TX.US (Charles Marslett) (10/23/89)
In article <6627@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > [wrt Mac vs. DOS] The system software is pretty psychotic, but it's a hell of a lot > better than DOS. I don't know what you are refering to here, but having used MANY operating systems, and programmed them, the Mac OS (Finder, et al.) is only marginally better than DOS. In fact I find DOS+MS/Windows to be not only comparable, but more flexible (it does have a command line interpreter), and more intuitive. So what if it came along two or three years later -- it is an improvement. If you are referring to programming, the Mac is the only machine I have surrendered to (I have never successfully written a program from scratch for it. They all get bogged down in trying to do some trivial little thing that both DOS and Unix do make easy). > No, it's not. The DOS system calls are a proper subset of the UNIX system > calls. The names and calling arguments are, in most cases, the same within > two decimal places. Just about everyone (Microsoft included) has discovered > the UNIX programming model by now. Except Apple. > No, it's an apples-and-apples comparison. There are plenty of low-cost > alternatives to DOS, even on 8088-based machines. WHAT?????????????????? Be real, If you can mention a single real alternative to DOS on an 80x86 machine that qualifies (even being rather liberal and ignoring the cost of application programs) as low cost, I'll shut up and go along with this (%censored%). Minix is hardly useful as a programming environment (for example, it is not even on my hard disk now, Xenix has displaced it, but DOS is always there, because I cannot work without it -- My MINIX kernel is, of course, compiled under DOS). DRDOS has most of the drawbacks of MSDOS, and a few extra. Xenix costs more than the machine I run it on (and more than all but two or three of the programs on the disk put togather). Interactive Unix is even more (and runs only on a 386). VM/386 is likewise nice, but not cheap and not supported universally among software vendors ;^). And I cannot waste the netwidth for a complete list, so I'll just ask: what is a worthwhile alternative?? > -- > Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. > Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' > "ERROR: trust not in UUCP routing tables" 'U` > -- MAILER-DAEMON@mcsun.EU.net Charles Marslett chasm@attctc.dallas.tx.us [Speaking purely personally, since I have lots of personality to speak from.]
mju@mudos.ann-arbor.mi.us (Marc Unangst) (10/23/89)
In article <3768@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > 1. Large model. A real ugly hack forced by the brain damaged Intel > architecture. MINIX doesn't inherently have an 64K limit. On the > Atari you can have programs as large as physical memory. I expect > the arrival of the 386SX will spell the end of the 8088 and 80286 > within a couple of years. At that point we can adopt a single linear > 32-bit address space, like MINIX-ST. My point is about the here-and-now, not some distant point down the road. Despite the fact that I really like having an OS with full source and all that (hell, I *like* to hack), I'd also like to be able to use MINIX for "real" things, too, like reading news, or running a BBS. I only have a V20 machine now, and that's why I'm running MINIX. If I had a 386SX, I'd be running Xenix/386 (or some other version of 386 Unix), not MINIX. > 2. Virtual memory. I tend to regard this as obsolete. With Bruce Evans' > protected mode kernel and a 2M 386 you can have up to 2M of programs > running at once. That has to be enough for a personal computer. > Thus I see virtual memory as something with a lifespan limited to > the older machines, which will probably be gone in a couple of years. As I said previously, I don't *have* a 386. If I did, I'd be running Bruce Evans's protected mode kernel. However, virtual memory has been around since Unix on the PDP-11, so I don't think it's too much to ask for it to be present on an 8088 Unix. > 4. UUCP. I believe Peter Housel posted something along this line (uupc). Okay; I've never seen this -- I'll have to go hunting on bugs.nosc.mil. > 7. Boot off hard disk. I suppose it is possible, but a low priority item. > Many people still use DOS and want to have the hard disk boot start DOS. > You can't have it both ways. Well, there are several ways you can do this: 1. Make up a special "MINIX boot floppy" that just jumps to the boot track on the MINIX root partition, and boots from there. You use this floppy when you want to boot MINIX; although you still have to get the floppy out, the actual boot process occurs on the hard disk. 2. Use FDISK to switch around the default boot partition whenever you want to boot MINIX. 3. Have MINIX offer a "boot to DOS" option, where it just restarts and boots off the partition of your choice. I believe that SCO Xenix does something similar to this, and this is probably the most elegant way of handling it. > 9. A format program. I'd love it. Any volunteers? Maybe I'll give it a whack after I upgrade to 1.3d and get all of my favorite patches/ugprades installed. Who knows; by then, someone else may have written it. >10. Backup. There is no dump/restore, but I wrote a program called backup.c > and posted it. I use it all the time and find it quite adequate. > You give it the name of a directory and put a floppy in the drive, and > it looks for files that have changed since the last backup and saves them > all. I even have a shell script that calls the program with the right > flags (which I posted). Yeah, I saw your backup.c. While it's perfectly fine for backing up a few files (those that fit on one floppy), it's not good for backing up your whole hard disk or something. I have a version of PDTAR, which supports multi-volume archives, so this isn't so bad...Still, it would be nice to have something other than tar. > Item DOS MINIX > 4. UUCP No Yes Actually, DOS has at least four UUCP implimentations I can think of. UUPC, UFGATE, PC-MAIL, and UUMAIL. > 5. Mail No No (except local mail) Again, with the addition of one of the above UUCP programs, you can do UUCP/Internet mail. You say the score is 4 to 4. I pretty much agree -- MINIX makes up for its (many) lacking qualities by being closer to Unix than DOS is (and probably the closest I'll ever get on this machine). I'll still use MINIX, and I'll still use DOS, but those additions would make me use MINIX almost exclusively. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832
henry@utzoo.uucp (Henry Spencer) (10/23/89)
In article <9829@attctc.Dallas.TX.US> chasm@attctc.Dallas.TX.US (Charles Marslett) writes: > [Unix on small machines] > >Come on, I used to work on such machines (PDP-11s, even the older VAXen) and >they were dogs under Unix... I worked on such machines for some years. They weren't exactly Crays, but the well-managed ones were perfectly acceptable. Remember what machines Unix was *invented* on. >Why do you think so many people used (use?) VMS? Because they were seduced by DEC propaganda. :-) Most of the folks I know who started out using VMS switched to Unix as quickly as they could. >Unix on a fast 11 might support a compile and two edits... The ones I worked on did a lot better than that. >AND YOU SEEM TO HAVE MISSED THE PHRASE: low cost. I didn't miss it, it's just irrelevant. Of course hardware costs were higher fifteen years ago. The point is, *now* hardware of that caliber is cheap. But somehow the software is no longer prepared to exploit it efficiently. As Mike O'Dell has observed, somehow the hardware keeps getting faster but the response time at my keyboard doesn't improve. >... try to explain why AutoCAD takes 2 MB under DOS, 4 MB under OS/2 >and 7 MB under Xenix to get the same performance... Incompetence? Actually, although I don't dismiss the possibility of sheer incompetence, software bloat is everywhere these days. As witness the 500KB text editors that very definitely are *not* 10 times better than the 50KB ones we used to have. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (10/23/89)
In article <3768@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > 2. Virtual memory. I tend to regard this as obsolete. With Bruce Evans' > protected mode kernel and a 2M 386 you can have up to 2M of programs > running at once. That has to be enough for a personal computer. My personal computer has 4 megabytes, and it's enough for now. *but* I have frequently had less than 2 megabytes free, and on occasion I've gone down as low as 1 megabyte. > 7. Boot off hard disk. I suppose it is possible, but a low priority item. > Many people still use DOS and want to have the hard disk boot start DOS. > You can't have it both ways. We have a few of thses sick individuals here. They run fdisk when they want to change between booting System V and DOS. 11. Message queues in the kernel instead of depending on rendezvous, and make the messages visible to user programs. This would cut down the race conditions (that still occasionally show up), and pave the way for a real lightweight kernel a-la Mach. > >> With the addition of these changes (or at least most > >> of them), I might consider eliminating DOS entirely from my machine. > I find this a bit odd. As far as I can see, the scorecard is: > Item DOS MINIX 0. Commercial applications Yes No. This one is why I don't care too much about getting MINIX on my Amiga. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "I feared that the committee would decide to go with their previous 'U` decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP
madd@world.std.com (jim frost) (10/23/89)
In article <3768@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: | 2. Virtual memory. I tend to regard this as obsolete. Eek. Perhaps unnecessary for MINIX, but far from obsolete. Further, adding it would be the best way to show students what kinds of junk a "real" operating system has to deal with, which was what I thought MINIX was all about in the first place. jim frost software tool & die madd@std.com
cramer@optilink.UUCP (Clayton Cramer) (10/24/89)
In article <6615@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <2501@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes: # # I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters # # would make appropriate criticisms of the many very real deficiencies # # of DOS, and leave it at that. But as long as someone can learn to # # use a computer without devoting years of their life to it, the # # DOS-haters will remain filled with irrational hatred. # # Oh, fiddlesticks. # # If this was the case then the Macintosh would be the computer everyone # feels disdain for. Making effective use of a DOS machine is much, much Missed all the nasty remarks about the "Macintoy" a while back? # harder than making effective use of a Mac. But us slimey elitists merely # point out the fery real deficiencies of the Mac and leave it at that. Why? # Largely because where the Mac is limited by its origins, DOS is limited # by deliberate malice on the part of IBM and Microsoft. # # (yes, I know that a corporation can't feel malice, but if you trust the # Turing test there is no better phrase for the behaviour of these companies) # -- # Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. I think a more accurate statement is that DOS is limited by its age. (Of course, Microsoft's approach to software doesn't excite me much either, but comparing DOS -- still largely limited by hardware compatibility problems from 1979 design requirements) to the Mac (five very fast years later) isn't particularly fair. I'm not particularly a DOS partisan, either. I have an AT at home, I use a Mac regularly, and a Sun 3, but this arrogant contempt that is continually being shown by academics for the PC AND the Mac annoys me. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Drugs are destroying the moral fiber of America...Another beer, please. ---------------------------------------------------------------------- Disclaimer? You must be kidding! No company would hold opinions like mine!
gary@dvnspc1.Dev.Unisys.COM (Gary Barrett) (10/24/89)
> I'm sure that if DOS weren't used by COMMON PEOPLE, the DOS-haters > would make appropriate criticisms of the many very real deficiencies > of DOS, and leave it at that. But as long as someone can learn to > use a computer without devoting years of their life to it, the > DOS-haters will remain filled with irrational hatred. Wow, some fairly strong words here! Might I even say ... irrational hatred? Don't get me wrong, I believe that DOS has proven itself a very useful tool. But there is a heck of lot of difference between being a DOS PC **user** and a DOS developer. DOS-based programmers have often fought long and hard to get their applications to work DESPITE DOS. And THAT is what makes DOS PCs so special, my opinion: the applications that run over the DOS base, not DOS per se. But let's face it, DOS needs to enter the world of protected-mode and multi-tasking to handle the kinds of sophisticated applications now being demanded of desktop devices. Does that mean OS/2 is inevitable? Not necessarily. OS/2 seems to be overkill. Seems to me that if something like the Amiga OS can exist, for a reasonable cost, we could develop something like it (super DOS) for the PC. Of course, I'm not sure that fits well into IBM's plans, who targets the moneyed corporate user. (The same may be true of Microsoft anymore, who seems to have forgotten its roots with the "little guy".) I suspect that Mr. Tannenbaum's disdain for DOS comes from a developer's (craftman's) critical eye, not from an elitist perspective. -- ======================================================================== Gary L. Barrett My employer may or may not agree with my opinions. And I may or may not agree with my employer's opinions. ========================================================================
jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) (10/24/89)
In article <6627@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <5182@uhccux.uhcc.hawaii.edu> webb@uhccux.UUCP (Thomas Webb) writes: >> Also, those >> of us on tight personal budgets can get a complete DOS development >> system for about $1500, $1000 for the machine and $500 for a very >> complete set of development software. > >You can get an Amiga development system for about that, and you get a real >operating system with a message-based kernel, multitasking, windowing, and >a decent base of commercial programs (yes, only a couple of the spreadsheets >are 1-2-3 compatible. Shucks). Or of you don't care whether you can run >alternatives to DOS, even on 8088-based machines. >-- >Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. >Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' Maybe, maybe not. DON'T try developing on an Amiga without at least a meg of memory and two floppies. Having watched a friend deal with a 512K Amiga with one floppy, I have a few doubts about the Amiga. The OS (which SOUNDS good) tended to lock up randomly or do whimsical things, like run out of memory and never give an error message (that's our best explanation for why a certain graphics program would work only every second or third time). However, I understand that version 1.3 is better (he was using 1.2). So, assuming one can get a loaded-enough Amiga for the same price, and that the new version of the OS works better, let's talk about the compilers. I understand that the Amiga developers' community itself is up in arms about the compilers, which still have major bugs even in versions 5.x (I may have the number wrong -- but I know it was many, many generations). Standard C code, using only standard library calls, which would compile under both DOS and UNIX without changes, would either not compile or would crash the system on the Amiga. The Amiga compilers make UNIX compilers (which tend toward the flaky themselves) look utterly reliable. If and when the compilers are finally fixed, then the Amiga will be a really nice computer. Except for the graphics, which are merely adequate, which I don't understand at all. The resolution is comparable to the medium-res modes on my Super VGA. So why does the text look like my old CGA, with scan lines not only clearly visible but SEPARATED by a thin blank? IMPORTANT NOTE: I AM NOT FLAMING THE AMIGA. I would take an Amiga over a Mac any day. I just don't think that it is a LOW-COST development platform, since an Amiga 2000 costs something like $2000 all by itself (price courtesy of my friend, who gave up on his old system). The software has a few problems yet, but it *is* possible to work around them (as witness all the Amiga software available) and the problems are far less evident on a loaded machine (part of why it isn't low-cost). I guess all the Amiga supremacists will have to flame me anyway... Sorry, guys, but there isn't a machine on the market which I don't have at least _some_ reservations about. -- James W. Birdsall jwbirdsa@phoenix.Princeton.EDU jwbirdsa@pucc.BITNET ...allegra!princeton!phoenix!jwbirdsa Compu$erve: 71261,1731 "For it is the doom of men that they forget." -- Merlin
root@cca.ucsf.edu (Systems Staff) (10/24/89)
In article <1989Oct23.155023.28185@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > ... > >Why do you think so many people used (use?) VMS? > > Because they were seduced by DEC propaganda. :-) No smiley needed; DEC put out a sales force to push VMS and tried to sweep Unix under the rug for a long time. > ... > Actually, although I don't dismiss the possibility of sheer incompetence, > software bloat is everywhere these days. As witness the 500KB text editors > that very definitely are *not* 10 times better than the 50KB ones we used > to have. As soon as the suppliers found out they could charge more for a big program than for a small one that did the same job the game changed. The compactness and efficiency that users would like were quickly discouraged by their own actions. Well, the knowledgeable users would like it; the status game players are another story. And the hardware manufacturers love it -- sells more expensive machines, right? Guess what software they are going to recommend? And that one works both ways; if the machine it runs on costs more you can charge more for the software. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
peter@ficc.uu.net (Peter da Silva) (10/25/89)
In article <11039@phoenix.Princeton.EDU> jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) writes: > Maybe, maybe not. DON'T try developing on an Amiga without at least a > meg of memory and two floppies. I'll agree with two floppies, but then I have NEVER found a machine that's worth a damn with only one floppy. But 512K and two floppies is quite usable. That's all I had while we were developing "Tracers". Remember, these are 880K floppies. But the new machines (500 and 2000) come with or cheaply expand to 1 meg. End of problem. > So, assuming one can get a loaded-enough Amiga for the same price, > and that the new version of the OS works better, let's talk about the > compilers. Let's talk about the compilers. They're certainly better than the PC compilers at a similar point in their development cycle. I remember using Microsoft C back when it was made by Lattice. Bletch. And if you want to develop for Windows, you need to buy the new Microsoft compiler, Windows development kit, and so on. We're talking big bucks. All that comes for free with the Amiga. And the Aztec and Lattice debuggers are as good as anything on the PC. Better, because with the windowing you can run them without interfering with your precious screen output. > I understand that the Amiga developers' community itself is > up in arms about the compilers, which still have major bugs even in > versions 5.x (I may have the number wrong -- but I know it was many, > many generations). That call them "V 5.x", but they've skipped a few numbers. Aztec is about to jump straight from 3.6 to 5.0. Marketing hype. > Standard C code, using only standard library calls, > which would compile under both DOS and UNIX without changes, would > either not compile or would crash the system on the Amiga. I don't know what "standard C code" we're talking about, but that hasn't been my experience. And how about standard library calls like "popen"? How do you do that on an IBM? > The resolution is comparable > to the medium-res modes on my Super VGA. So why does the text look like > my old CGA, with scan lines not only clearly visible but SEPARATED by a > thin blank? Because you're not using the high resolution mode for text. Not only do you have a selection of modes, you can have them on the screen at the same time. > IMPORTANT NOTE: I AM NOT FLAMING THE AMIGA. I would take an Amiga > over a Mac any day. I just don't think that it is a LOW-COST development > platform, since an Amiga 2000 costs something like $2000 all by itself > (price courtesy of my friend, who gave up on his old system). So get an Amiga 500. > I guess all the Amiga supremacists will have to flame me anyway... > Sorry, guys, but there isn't a machine on the market which I don't have > at least _some_ reservations about. Me too, but I try to avoid comparing apples to oranges. The biggest problem with the Amiga is Commodore's advertising budget. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
mju@mudos.ann-arbor.mi.us (Marc Unangst) (10/25/89)
In article <6660@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: >And how about standard library calls like "popen"? >How do you do that on an IBM? You use the "popen" library that was posted for DOS a while back in comp.sources.misc. I've used it to port several Unix programs to DOS that would have required a major re-write if I didn't have popen(). -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832 ?
shawn@marilyn.UUCP (Shawn P. Stanley) (10/25/89)
I don't think contempt for DOS should be realised as contempt for a DOS user, who is only trying to get a task done no matter what anyone's opinion of their environment. Let's try to help each other instead of withholding information indiscriminantly.
peter@ficc.uu.net (Peter da Silva) (10/25/89)
I asked: "How do you do popen on a PC?" In article <699.2545546D@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > You use the "popen" library that was posted for DOS a while back in > comp.sources.misc. I've used it to port several Unix programs to DOS > that would have required a major re-write if I didn't have popen(). That handles the case where you're using pipes like temp files, but what about interactive pipes? What about stuff too big to fit on disk? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
madd@world.std.com (jim frost) (10/25/89)
In article <6660@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: |And how about standard library calls like "popen"? |How do you do that on an IBM? I did an off-the-cuff implementation a couple of years ago. If it's a write pipe, open a tmp file on popen, dump the stuff to it, and spawn the other process on pclose. If it's a read pipe, spawn the process immediately with output to a tmp file and start reading on its completion. Perfect semantics is a little more difficult but it does work fairly well. Someone actually turned my implementation into a real thing, so I guess there was demand for it :-). Personally I'd just put UNIX on the machine and solve the whole problem. Followups redirected to comp.sys.ibm.pc. jim frost software tool & die madd@std.com
jose.dias@canremote.uucp (JOSE DIAS) (10/26/89)
What's the problem here folks? Minix was written to teach OS courses, and is now changing into a very useful OS. Let's not attack ast but let's instead congratulate him! He did a good job! In my opinion, if Minix is missing something then write it yourself! Don't complain that it doesn't have this and doesn't have that. Take advantage of what it does have! Oh boy! --- Jos Dias --- ~ DeLuxe 1.11a10 #1744
shawn@marilyn.UUCP (Shawn P. Stanley) (10/26/89)
In article <2521@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >As soon as the suppliers found out they could charge more for a big >program than for a small one that did the same job the game changed. I disagree. If that were as true as you appear to think it is, there would be more marketing effort put into informing potential users as to the "new and improved" size of the programs. Rather, I believe that through the years companies have made more and more use of high-level languages to write their applications, which is of course going to use more space, but at the same time the programmer is more free to think of the application itself and not just the details of coding. Object-oriented programming may or may not take this a step further. The concept is so new, I have to believe that most programmers are still learning how much or how little to put into a single object so that you don't have to write too many objects to deal with them, or re-write objects because they don't allow enough manipulation or flexibility. Add to this the fact that UNIX is much more commonplace than before, with programmers that are used to programming on bigger machines with more features, and what you have in the end is not intentional hogging but the evolution of the MS-DOS world, for better or for worse.
cs304pal@rata.vuw.ac.nz (Lloyd Parkes) (10/27/89)
In article <6627@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <5182@uhccux.uhcc.hawaii.edu> webb@uhccux.UUCP (Thomas Webb) writes: >> Also, those >> of us on tight personal budgets can get a complete DOS development >> system for about $1500, $1000 for the machine and $500 for a very >> complete set of development software. > >Fiddlesticks. (I'm saying that a lot lately. It's a lot more polite than >what I'm thinking) I would just like to add my fiddlesticks as well, I have a 12Mhz AT, with two (small) hard drives, with an excellent VGA card, with VGA monitor. All for $NZ2700 + $NZ700 + $NZ900. This is about $US2600 max (exchange rates are a bit dodgy). All this paid for by a part time job, while I study here at University. It really isn't that hard to get a very nice AT based development system. I would actually like to see more work done on using VGAs as graphics terminals, with windows etc. :-) Fun for someone. Lloyd Quick, send your money to cs304pal@rata.vuw.ac.nz now! If you think anyone believes what I have just said, then you must be daft in the head!
dhesi@sun505.UUCP (Rahul Dhesi) (10/27/89)
In article <1989Oct20.170447.19573@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Hatred of DOS is entirely rational, and has nothing to do with who else >uses it. There are ample reasons to despise that feeble excuse for an >operating system. That depends on the particular DOS, you know. UNIX, for example, is a pretty decent DOS. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi Use above addresses--email sent here via Sun.com will probably bounce.
dhesi@sun505.UUCP (Rahul Dhesi) (10/27/89)
In article <3768@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > 2. Virtual memory. I tend to regard this as obsolete. With Bruce Evans' > protected mode kernel and a 2M 386 you can have up to 2M of programs > running at once. That has to be enough for a personal computer. > Thus I see virtual memory as something with a lifespan limited to > the older machines, which will probably be gone in a couple of years. My eyes :-) perked up at this. I doubt that virtual memory (defined in some reasonable way) will ever be obsolete. So long as people use disk drives, they will have sets of data that are bigger than their main memory will hold. They will make their programs read in parts of those data, process them, and write them back. They will be happier if the operating system does that for them transparently. Bingo! Virtual memory. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi Use above addresses--email sent here via Sun.com will probably bounce.
news@bbn.COM (News system owner ID) (10/31/89)
cramer@optilink.UUCP (Clayton Cramer): < Missed all the nasty remarks about the "Macintoy" a while back? Well, no, actually. Programming the Mac is a very "a ha" sort of thing -- the learning curve is rather long, but after a few months it all makes sense, and is relatively elegant. If you don't "get it", then you havn't thought long enough about it yet -- go and meditate some more... Most of the people who have been saying otherwize have been doing MeSsy-DOS for so long that it seems to have rotted their brains... (only 1/2 :-); flames to /dev/null, NUL:, Trashcan (your choice)). The basic bit of uglyness is that you have to start up all the handlers by hand because the Mac doesn't have a real OS. Neither does the PC, for that matter. Also, you *do* have to pay attention to *all* the result codes (but that's true for everything anyway), and you have to poll for events rather than getting interupts (but this is true for most window systems). As for command line interfaces, Apple loves them _for_development_ -- MPW is command line based, and works Just Fine, Thanks. Plus you get the added bonus of consistancy: all applications look basically the same, so it takes about 1/10 the time to learn to use a Mac than for a PC (this tidbit from one of the PC rags' surveys). Look at it this way: MSDOS is an overgrown program loader; the MacOS is an overgrown user interface. Neither is an operating system, but the second is better for running applications. -- Paul Placeway