author: WillerZ

text:
ARMAS wrote:

It's hardly difficult.  My solution, in which English words work for all
32-bit integers and Roman Numerals work for all numbers between 1 and
9999999 inclusive is below.  Note that I have used English punctuation,
and the convention that upper-case Roman numerals are multiplied by 1000
compared to their lower-case versions.  There's a main() function with
test code at the end.  The length field in the structures was useful
when I was assembling the strings in memory rather than just printing
them out.

I haven't bothered to write code to read numbers in because you didn't
tell me the format they would be in.

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>

struct { int len; const char *str; } roman_numerals[7][10] =
{
   {
     { 0, NULL },       // 0
     { 1, "i" },        // 1
     { 2, "ii" },       // 2
     { 3, "iii" },      // 3
     { 2, "iv" },       // 4
     { 1, "v" },        // 5
     { 2, "vi" },       // 6
     { 3, "vii" },      // 7
     { 4, "viii" },     // 8
     { 2, "ix" }        // 9
   },
   {
     { 0, NULL },       // 0
     { 1, "x" },        // 10
     { 2, "xx" },       // 20
     { 3, "xxx" },      // 30
     { 2, "xl" },       // 40
     { 1, "l" },        // 50
     { 2, "lx" },       // 60
     { 3, "lxx" },      // 70
     { 4, "lxxx" },     // 80
     { 2, "xc" }        // 90
   },
   {
     { 0, NULL },       // 0
     { 1, "c" },        // 100
     { 2, "cc" },       // 200
     { 3, "ccc" },      // 300
     { 2, "cd" },       // 400
     { 1, "d" },        // 500
     { 2, "dc" },       // 600
     { 3, "dcc" },      // 700
     { 4, "dccc" },     // 800
     { 2, "cm" }        // 900
   },
   {
     { 0, NULL },       // 0
     { 1, "m" },        // 1000
     { 2, "mm" },       // 2000
     { 3, "mmm" },      // 3000
     { 2, "mV" },       // 4000
     { 1, "V" },        // 5000
     { 2, "Vm" },       // 6000
     { 3, "Vmm" },      // 7000
     { 4, "Vmmm" },     // 8000
     { 2, "mX" }        // 9000
   },
   {
     { 0, NULL },       // 0
     { 1, "X" },        // 10000
     { 2, "XX" },       // 20000
     { 3, "XXX" },      // 30000
     { 2, "XL" },       // 40000
     { 1, "L" },        // 50000
     { 2, "LX" },       // 60000
     { 3, "LXX" },      // 70000
     { 4, "LXXX" },     // 80000
     { 2, "XC" }        // 90000
   },
   {
     { 0, NULL },       // 0
     { 1, "C" },        // 100000
     { 2, "CC" },       // 200000
     { 3, "CCC" },      // 300000
     { 2, "CD" },       // 400000
     { 1, "D" },        // 500000
     { 2, "DC" },       // 600000
     { 3, "DCC" },      // 700000
     { 4, "DCCC" },     // 800000
     { 2, "CM" }        // 900000
   },
   {
     { 0, NULL },       // 0
     { 1, "M" },        // 1000000
     { 2, "MM" },       // 2000000
     { 3, "MMM" },      // 3000000
     { 4, "MMMM" },     // 4000000
     { 5, "MMMMM" },    // 5000000
     { 6, "MMMMMM" },   // 6000000
     { 7, "MMMMMMM" },  // 7000000
     { 8, "MMMMMMMM" }, // 8000000
     { 9, "MMMMMMMMM" } // 9000000
   }

};

void
to_roman_numeral(int number)
{
   int i, j;
   for (i = 1000000, j = 6; i > 0 ; i /= 10, --j)
   {
     if (roman_numerals[j][number / i].len)
       fputs(roman_numerals[j][number / i].str, stdout);
     number %= i;
   }
}

struct { int len; const char *str; } english_nums[3][10] =
{
   {
     { 0, NULL },    // 0
     { 3, "one" },   // 1
     { 3, "two" },   // 2
     { 5, "three" }, // 3
     { 4, "four" },  // 4
     { 4, "five" },  // 5
     { 3, "six" },   // 6
     { 5, "seven" }, // 7
     { 5, "eight" }, // 8
     { 4, "nine" }   // 9
   },
   {
     { 0, NULL },      // 0
     { 0, NULL },      // 10
     { 6, "twenty" },  // 20
     { 6, "thirty" },  // 30
     { 5, "forty" },   // 40
     { 5, "fifty" },   // 50
     { 5, "sixty" },   // 60
     { 7, "seventy" }, // 70
     { 6, "eighty" },  // 80
     { 6, "ninety" }   // 90
   },
   {
     { 0, NULL },    // 0
     { 11, "one-hundred" },   // 100
     { 11, "two-hundred" },   // 200
     { 13, "three-hundred" }, // 300
     { 12, "four-hundred" },  // 400
     { 12, "five-hundred" },  // 500
     { 11, "six-hundred" },   // 600
     { 13, "seven-hundred" }, // 700
     { 13, "eight-hundred" }, // 800
     { 12, "nine-hundred" }   // 900
   }
};

struct { int len; const char *str; } english_teens[10] =
{
   { 3, "ten" },       // 10
   { 6, "eleven" },    // 11
   { 6, "twelve" },    // 12
   { 8, "thirteen" },  // 13
   { 8, "fourteen" },  // 14
   { 7, "fifteen" },   // 15
   { 7, "sixteen" },   // 16
   { 9, "seventeen" }, // 17
   { 8, "eighteen" },  // 18
   { 8, "nineteen" }   // 19
};

int
do_triplet_english(int number, int printing, int last)
{
   int i,j,ten = 0, printed = 0;
   for (i = 100, j = 2; i>0;i/=10,--j)
   {
     if (english_nums[j][number / i].len)
     {
       if (printed)
       {
	if (ten || j != 0)
	  fputs("-and-", stdout);
	else
	  fputs("-",stdout);
       }
       else
       {
	if (printing)
	{
	  if (!last || j == 2)
	  {
	    fputs(" ", stdout);
	    printing = 0;
	  }
	  else
	  {
	    fputs(" and ", stdout);
	    printing = 0;
	  }
	}
       }
       if (ten)
	fputs(english_teens[number / i].str, stdout);
       else
	fputs(english_nums[j][number / i].str, stdout);
       printed = 1;
       number %= i;
     }
     else if (j == 1 && (number / i) == 1)
       ten = 1;
   }
   return printed;
}

void
to_english(int number)
{
   int i, printing = 0, printed = 0;
   if (number < 0)
   {
     fputs("minus ",stdout);
     number *= -1;
   }
   i = 1000000000;
   printed = do_triplet_english(abs(number/i), printing, 0);
   if (printed)
     fputs("-billion", stdout);
   printing = printing | printed;
   number %= i;
   i /= 1000;
   printed = do_triplet_english(abs(number/i), printing, 0);
   if (printed)
     fputs("-million", stdout);
   printing = printing | printed;
   number %= i;
   i /= 1000;
   printed = do_triplet_english(abs(number/i), printing, 0);
   if (printed)
     fputs("-thousand", stdout);
   printing = printing | printed;
   number %= i;
   i /= 1000;
   printed = do_triplet_english(abs(number/i), printing, 1);
   printing = printing | printed;
   if (!printing)
     fputs("zero", stdout);
}

void test (int x)
{
   to_roman_numeral(x);
   fputs("\t", stdout);
   to_english(x);
   fputs("\n", stdout);
}

#include <limits.h>

int main(void)
{
   to_english(0);
   fputs("\n", stdout);
   to_english(-1);
   fputs("\n", stdout);
   to_english(2040100009);
   fputs("\n", stdout);
   to_english(INT_MAX);
   fputs("\n", stdout);
   to_english(INT_MIN);
   fputs("\n", stdout);
   test(1);
   test(1981);
   test(2007);
   test(9888888);
   return 0;
}


author: Aninda Dasgupta

subject: Reliable UDP Broadcasts?

text:
Does anyone have any experience with "reliable UDP broadcasts?"
I am simulating a protocol using UDP broadcasts.  A node
on the network doesn't know of the existence or identity of the
other nodes on the network.  Thus, if node A wishes to discover
who else is listening to its broadcasts on the subnet, it shouts
a 'grope' packet.  The reciepients of the grope packet reply
back, again using broadcasts.

The problem I am facing is as follows:

Host B and C are listening for broadcasts on the subnet.  Node A
broadcasts a grope packet, which is received by both B and C.
Immediately, B and C decide to broadcast grope packets.  However,
B does not hear C's broadcast.  Strangely enough, C can hear B's
broadcast.  I suspect that the UDP packets from C are being
dropped at B.  I guess that is part of the unreliability of the
UDP protocols.

If anyone has dealt with such a problem and built a reliability
layer over UDP broadcasts, I would like to hear from you.  Please
note that I cannot use end to end acknowledgements as the identity
of other nodes on the network are not known before the grope packets
are sent out.  Thus, C cannot expect to get an acknowledgement from
B as C does not know of B's existence.

If it matters, I am using Sparc IPX, with SunoS 4.1.2.

Thanks for any ideas/information you can give me.

Regards,

Aninda


author: Greg Law

subject: Re: Reliable UDP Broadcasts?

text:
In article <[email]> [email] (Aninda Dasgupta) writes:

The general technique used in amateur radio to avoid packet collisions is to
wait a random interval of time (up to a specified maximum) before sending or
replying. While it doesn't guarantee collisions won't happen, it reduces the
odds considerably.


author: Bruins

subject: where to find lowpass filter code written in c

text:
Hi all,

   I need c code of lowpass filter,can you share me?
   Thanks!


author: Herman Oosthuysen

subject: Re: where to find lowpass filter code written in c

text:
[email] (Bruins) wrote in message news:<[email]>...

Hmm, look for a little program called DSPlay by Prof Roger Cattin on
Google.

It will teach you the basics and it can generate the filter code too,
in a number of dialects, including C.

Cheers,

Herman
http://www.AerospaceSoftware.com


author: Dan Ash

text:
The filter, or the coefficient calculation too?  The filter, may be FIR or IIR,
and if IIR, second order sections, direct or canonic form, so you should be
more specific.

A good practical $40 (new) book (with code), is DSP Filters by Lane, Datta,
Karley, and Norwood, Prompt Publications (SAMS), ISBN 0-7906-1204-6.

Good luck,

Dan Ash


author: Maurice Givens

text:
You need to narrow it down more than this.  Are you looking for LC
filter, RC filter, RLC filter, active filter (multiple feedback,
Salen-Key, etc), butterworth, elliptical, bessel, and on and on and on
...........

All of these can be found by doing a search in google or the local
library.

Maurice Givens

[email] (Bruins) wrote in message news:<[email]>...


author: Keld Hammerum

text:
I guess that we are talking digital filters here - terms like LR, RC,
RLC, active/passive are not really relevant here, are they? To me,
writing an RC filter in C would mean something like simulating the
behaviour of an analog circuit - and I believe that is NOT what the OP
wanted.

Moreover, it is important to know the difference between terms
describing transfer function characteristics (Butterworth, Bessel,
Elliptical, etc.) and different ways of implementing these (RC, RLC,
active/passive, etc.).

Regards

Keld Hammerum

[email] (Maurice Givens) wrote in message news:<[email]>...


text:
Yes, and this difference is part of the and so on.  I work in both
analog and digital filters.  I also have software for both analog and
digital filters.  Just asking for software in C for low pass filters
does not make a differentiation.  The point I wanted to make is that
the poster needed to amplify his request.

Maurice Givens

[email] (Keld Hammerum) wrote in message news:<[email]>...


author: Dan Green

subject: Re: Which is better?  Sound Blaster 32 or GUS PnP

text:
In article <49lf3o$[email]>, [email] (Atro Kajaste) writes:

The problem is that no tracker supports modplaying through the EMU just the D/A.

/Dan


author: Keith Instone

subject: Intercepting deleteCard message

text:
I can keep the user from sorting my stack with this simple little
handler:

        on sort
        end sort

but this doesn't work for the deleteCard message (that is, the empty handler
doesn't keep the card from getting deleted).

I tried adding the 'exit to Hypercard' command (among other things),
but that didn't work either.

Saving the card information and doing a 'new card' after the deletion
won't work very well because I am using card id's a lot.

All I REALLY want to do is ask "Are you sure you want to delete this card?"
and abort if the user says NO.

Any suggestions?

Keith [email]
Thanks in advance, HyperTalk-style:
   put "Advance" into adv
   put "Thanks" after char 3 of adv
   put adv


author: Charles Moore

subject: Re: Intercepting deleteCard message

text:
In article <[email]>, [email] (Keith Instone) writes:

The deleteCard message is NOT the message that causes HyperCard to delete
the card.  Rather, deleteCard gets sent to a card that is about to be
deleted just prior to its deletion.  This allows some handler to recognize
that a deletion is about to occur and do something appropriate.  The
HyperCard Script Language Guide explains this and other purely informational
system messages.

What you want is:

on doMenu theCommand
  if theCommand is "Delete Card" then
    answer "Are you sure you want to delete this card?" with "OK" and "Cancel"
    if it is "OK" then
      pass doMenu
    end if
  else
    pass doMenu
  end if
end doMenu

Note: The "else pass doMenu" part is VERY important.  If you don't include
it, you will suddenly discover that none of your menu commands work.

Charles Moore


author: Jonathan King

subject: Re: Intercepting deleteCard message

text:
[email] (Keith Instone) writes:

This works because you have redefined the sort *command* to do
nothing, and the command does not pass further up the hierarchy to
hypercard, which would cheerfully shuffle your stack if it received it.

And that's because deleteCard is not a command, but a message that
gets sent to a card just before it disappears.  In effect, Hypercard has
*already* pulled the trigger, but the victim gets the chance to have a
few last requests...

Nope, this doesn't forestall the death sentence either.

(Which is one reason I use card names a lot, but, hey, I use card names
to hold up to 31 characters worth  of neat card properties;
too bad that user-definable properties of objects aren't yet a feature.)

But this you *can* do, even though the direct approach you tried
doesn't work.  The trick is to intercept the command to delete the
card before it pulls the trigger.  Note that you don't have to assume
that the user would be deleting the card by using the menu item, since
the only way to delete cards (in HC 1.2) is to to go through the
"domenu" command.  So if you had a button that deleted a card, you
would just send 'domenu "Delete Card"' to the appropriate card.  Then
in that card's script you would put something like:

on doMenu menuChoice
  if menuChoice is "Delete Card" then
    answer "Are you sure?" with "Delete" or "Cancel"
    if it is not "Delete" then exit doMenu
  end if
  pass do Menu  --THIS IS A KEY LINE OR YOU'LL BE LOCKED OUT
end doMenu

That's it!  This is essentially identical to the script on p. 86 of
the apparently-soon-to-be-obsolete Hypercard Script Language Guide
published by Addison Wesley.

Hope this will work for you.

Or you could just replace adv with the omnipresnet it...

jking

[But seriously:  is there going to be a new official Hypertalk Script
Language Guide (HSLanG) for HC 2.0?  If there is, will it appear
pretty soon or next summer?]


author: Ed Howe

subject: Re: Intercepting deleteCard message

text:
In article <[email]> [email] (Keith Instone) writes:
        <portion deleted>

Try putting this in your stack...

on domenu what
  if what is "delete card" then
    answer "Are you sure?" with "Yes" or "No"
    if it is "Yes" then pass domenu
    else exit domenu
  end if
  pass domenu
end domenu

The routine can be easily modified to trap for other menu options as well.
(Note that it is important to PASS DOMENU if WHAT isn't what you were trapping
for...otherwise you'll totally disable menu commands...)
ELH


author: bill coderre

subject: Re: Intercepting deleteCard message

text:
Charles Moore:
|Note: The "else pass doMenu" part is VERY important.  If you don't include
|it, you will suddenly discover that none of your menu commands work.

Right. But let's correct the misperception started by Danny Goodman
and tell everyone how to fix a broken menu handler. Danny believes
that once you've got a broken doMenu handler, you're hosed, which is
untrue.

If you accidentally mess up your menu handler and can't do any menu
commands (including, unfortunately, editing the script of the object
containing the offensive handler), you can ALWAYS type

send "edit the script of <the-containing-object>" to Hypercard

provided that either the message box is visible OR you have blind
typing enabled. This bypasses any intervening handlers. It is
therefore a very good idea to make sure you have blind typing turned
on at all times.

If for some reason you can't type, or you feel you must reboot, simply
wait a minute or so for any disk activity to finish, then reboot.
Chances are, your stack will be okay.

bill coderre
hypercard smartypants


author: aj

subject: SET INTEGRITY question

text:
DB2 v8 FP5 WSE LUW
Red Hat Linux 2.1AS

I'm like to add a new column to an existing table that will be
NOT NULL and have a WITH DEFAULT value.

The table has a huge assortment of triggers, views, FK's, and
stored procs against it, so I don't want to take the usual steps
of creating a new table with the same structure plus the new
column, then copying all the data over and renaming the table.
(I would have to identify all the dependencies, drop them, do
the copy+rename, then recreate them).

Can I just SET INTEGRITY OFF for the table, add the NOT NULL WITH
DEFAULT column, populate the column, then SET INTEGRITY ON?

Any advice appreciated.

aj


author: Serge Rielau

subject: Re: SET INTEGRITY question

text:
aj wrote:
ALTER TABLE T ADD COLUMN c1 INT NOT NULL WITH DEFAULT;
... done... no SET INTEGRITY, no going for coffee, no worries...
DB2 for LUW had online schema evolution for this scenario since it's
inception.

Cheers
Serge


subject: Re: SET INTEGRITY question

text:
Well.......don't I feel like an idiot.  I guess I can do that
with a simple:
   alter table x add column1 int not null default 0

I *think* I discovered at one point that I could not add NOT NULLness
or WITH DEFAULT to an *existing* column (correct me if I'm wrong), so
I assumed I would see the same thing when adding a new column...

Can someone set me straight here?

TIA

aj

aj wrote:


subject: Re: SET INTEGRITY question

text:
aj wrote:
You are correct that you cannot ALTER nullability.
In V8.2 you can ADD/DROP/ALTER DEFAULT for existing columns directly.

Cheers
Serge


author: David D. Dean

subject: 3.5" Disk Drive for 8-bit

text:
Hello ;-)

        I have heard that it could be done, and I would like to do so.  Is
there a possible way to set-up a 3.5" disk drive for an Atari 8-bit?  I
have an 800xl, and would like to try this.

        What all would I need, and could someone quote me a price?

Thank you for any response.

        I am also looking for a Hard Drive for the 8-bit... (I know...
"Why???")  I think that it might beneat to do this... kinda max-out mu
8-bit and make it a novelty!

David D. Dean, President       "Living in a 3-D world."
Explorer Post 891
AT&T Bell Laboratories          Columbus, Ohio
[email]

**** Any opinions are that of the author, and NOT of AT&T ****


author: Scott S Parish

subject: Re: 3.5" Disk Drive for 8-bit

text:
[email] (David D. Dean) writes:

The vendor is:

Innovative Concepts (I.C.)
31172 Shawn Drive
Warren, MI 48093 USA

Phone: (313) 293-0730
BBS: (313) 978-1685
GEnie: I.C.
CompuServe: 76004,1764

As for the current price, I don't know the kit was going for around $40 about
8-9 months ago.  I'm sure it hasn't changed.

As for the hard drive:  Read the previous post by Gary Duzan(?).


author: Craig Rothman

subject: Re: 3.5" Disk Drive for 8-bit

text:
[email] (David D. Dean) writes:
3.5"-- the way to get one of these is to somehow obtain a costly
disk drive known as the xf551. This was made by atari and its
double sided/double density. No one I know of will part with theirs,
so good luck!  Once you get one of these, youll need to buy a 3.5 mech and
have someone know knows how to mount it, put it in. Im told its not
that hard to do. (ive never done it. I dont know!).
I dont know if theres a 3.5" made by another company, but ive heard of
peripherals that allow IBM PC drives to be connected. Im sure someone
here could write more.
As for a hard drive, youll be opening pandoras box, but you could
get one hooked up.
Youd need either a black box, or MIO.
Then youd need wires.. (from ICD)
Then youd need the drive.. and the appropriate controller board.
Then a case and power supply.
Ive spent a considerable amount of time obtaining this stuff.
Its not easy.. The controller boards are hard to get.
I found a supplier though, look at the old messages Ive posted here about
it, or send me email and ill give you more info. Ive already posted it
and i dont have it handy right now.
The best thing to do is to call ICD, They have the stuff youll need
as a kit of some sort. IM told its expensive and a rip off, but its
very very hassle free.
-craig
[email] (NOTE: I can only recieve EMAIL at this address!)


author: Systems Research Supervisor

subject: Re: 3.5" Disk Drive for 8-bit

text:
In article <[email]> [email] (David D. Dean) writes:
=>Hello ;-)
=>
=>        I have heard that it could be done, and I would like to do so.  Is
=>there a possible way to set-up a 3.5" disk drive for an Atari 8-bit?  I
=>have an 800xl, and would like to try this.
=>
=>        What all would I need, and could someone quote me a price?
=>
   There exists a hack to modify an Atary XF551 5.25" drive to use a
3.5". For the most part I understand it is fairly simple, but it does
require a new EPROM to use the whole disk. I have a vendor & price,
but they are at home. :-(

=>Thank you for any response.
=>
=>        I am also looking for a Hard Drive for the 8-bit... (I know...
=>"Why???")  I think that it might beneat to do this... kinda max-out mu
=>8-bit and make it a novelty!
=>
   Easiest way is to get a Black Box and a SCSI drive. If you can
afford novelty, more power to you. :-)

=>**** Any opinions are that of the author, and NOT of AT&T ****

   Now why would AT&T be interested in Atari 8-bit hacks? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration


subject: Re: 3.5" Disk Drive for 8-bit

text:
Thanks for all the help!  I am going to check into this right away!

David D. Dean, President       "Living in a 3-D world."
Explorer Post 891
AT&T Bell Laboratories          Columbus, Ohio
[email]

**** Any opinions are that of the author, and NOT of AT&T ****


subject: Re: 3.5" Disk Drive for 8-bit

text:
[email] ([email] (Systems Research Supervisor)) writes:

Thanks for the help!  I have recieved the address for the 3.5" drive, and
will be checking up into it.  The Black Box and SCSI drive might have to
hold off... I can't seem to locate any dealer with them.

And AT&T probably FORGOT about the Atari 8-bit!  :-)

David D. Dean, President       "Living in a 3-D world."
Explorer Post 891
AT&T Bell Laboratories          Columbus, Ohio
[email]

**** Any opinions are that of the author, and NOT of AT&T ****


subject: Re: 3.5" Disk Drive for 8-bit

text:
[email] (David D. Dean) writes:

Let me know what you find out about the xf551 mod.
Ive got one of the buggers and its messed up.
IT wont do double sided double density, just single sided single density.
ITs still useful, but if i replaced the mech with a 3.5" it would
be a great thing to have. Ive held off because it would be too costly
for the drive mech, and I didnt have directions about how to do it.
If its just a mere $40 I want it!!!!
let me know what it costs and how difficult it is to do it.
-craig
[email]


author: Bill Marcum

subject: Re: 3.5" Disk Drive for 8-bit

text:
In article <[email]> [email] (Craig Rothman) writes:
What DOS are you using?  Atari sold a lot of XF551s with DOS 2.5, which
treated the drive as if it were just a 1050.  The rest were sold with DOS XE,
which recognizes the drive as DSDD, but is incompatible with a lot
of other programs.  Either Mydos, Spartados, or Spartados-X will work with
the 551 in DSDD mode.

You need more than just the 3.5 inch drive mechanism.  You also need a new
ROM for the drive.  Upgrade kits are available from Innovative Concepts in
Michigan, or from CSS (who also make the Black Box.)  CSS has a new
deluxe upgrade that lets you use the 5.25 and 3.5 inch drives as different
drive numbers, and they claim it can even read and write IBM or ST disks.
The price is something like $139.95, including 3.5 inch drive.  (Not sure
if that's the exact price--check their ad in STart.)

Bill Marcum
[email]
Compuserve:72750,476
Genie:B.MARCUM


subject: Re: 3.5" Disk Drive for 8-bit

text:
[email] (Bill Marcum) writes:

I use Spartados, and I was using the correct format.
I had someone who owned a xf551 over here to check it out
and its the drive.
THe previous owner tinkered with it or something.
It wont do DD on either side.
I suspect upgrading the drive will solve it.


author: Matthew Wilson

subject: Re: 3.5" Disk Drive for 8-bit

text:
The Percom disk drive for my 8-bit has double sided/double density
ability as well.  I would definately appreciate any hints on attaching
a 3.5" drive to the disk controller.  Please post any response.


author: Mayleen G Snyder

subject: Re: 3.5" Disk Drive for 8-bit

text:
To: Matthew Wilson
Subject: Re: 3.5" Disk Drive for 8-bit
Newsgroups: comp.sys.atari.8bit
In-Reply-To: <[email]>
References: <[email]> <[email]>
Organization: University of Delaware

In article <[email]> you write:

it should just go right on....need the righT connect but with SpartaDOS it should give you 720k per disk....but i
 have an ATR 8000 for my atari....it will handle 5-1/4 in single/double sided or density...(will not do dual density tho') it will handle 3.5 drives in the same...
 (720k max for a DS/DD 3.5 drive) if you or anyone is interested in buying send me some mail i will trade it for a 40 SCSI or ST-506 drive or $200...
(it includes everything to hook up a 3.5 720k drive and a 5-1/4 360k drive
 EXCEPT power supply for the floppys...(standard +5,+12 but i do have the connector to hook the 3.5 to the standard power connector)...
you can run CP/M on the ATR i can give you the name and number of the guy who
has the software to run CP/M on it...it also has a print and Serial port (i have the cable to hook up a standard modem to it...(i am currently using it now wit
a Supra modem and Kermit (for the Atari) and have used DeTerm,Express,a term prg i wrote in Action! and several others...) it does have ONE bad side....size...
it is as wide as my 1200xl and 2 1/2 inches high and about foot deep....)

(p.s. you can hook it up to a terminal and use it alone to run CP/M....)
(it will support up to 4 drives of any config.....)

Sloopy X. Malibu                                       [email]
(chris luckey)                                         [email]


author: @Glue.umd.edu (David T. Wang

subject: Re: Would MS Make A Good World Government?

text:
Nathan Hand ([email]) wrote:
: [email]@Glue.umd.edu (David T. Wang) writes:

: > Nathan Hand ([email]) wrote:
: > : [email]@Glue.umd.edu (David T. Wang) writes:
: >
: > : > Compiling to bytecodes, then JIT to native, combined with the garbage
: > : > collection guarentees, and the pointer chasing nature of OO programming,
: > : > C will probably always be faster. Java sells you on the universality of
: > : > execution platform, not on speed.
: >
: > : Compiling directly from Java to native is what I'm talking about. And
: > : garbage collection is demonstrably *faster* in some cases. OO doesn't
: > : make code slower in all cases, either. Especially not for tight loops
: > : where no OO is performed, and the majority of the work is done.
: >
: > Compiling directly from Java to Native, then what is the point of Java?
: > Why wouldn't you just use C++?

: Because Java will compile without modification on all platforms and
: retain the native "look and feel". Ever wonder why the Macintosh vs
: of Word takes an extra 3 months to be released? Ever wonder why the
: UNIX version of Netscape is always behind? It's because C++ doesn't
: abstract things like sizeof(int) and endianess, and the widget sets
: are all different, and even networking code isn't the same.

: Using the Java language avoids all the porting problem. If you have
: the need for using the same binary on multiple platforms (like with
: a web applet, or shared resource in a heterogenous network) then it
: is possible to use the bytecode and get portability. But you do not
: need to do it this way, if speed is such a concern. You can go back
: to the Tried And True Method of pre-emptive compilation.

me thinks that you are glossing over a few things here.  Don't you
still have to access native methods to get at some of the resources?
without the native methods, Java, by itself, in its incarnation,
probably isn't very good for the kind of cross-platform development
work which you've described. (i.e. MS Word)   IMO, when the native
methods get involved, and you're compiling to Native code anyways,
with the performance typically less than C/C++, Java would still
come out a bit short.

: And you can always convert bytecode into native code, and then it's
: going to be almost as fast as source into native code, but with the
: added benefit of you not needing access to the source.

: > : > Even with JIT, IMO, java code will never be as fast as C for general
: > : > purpose stuff.  you might be able to come up with 1 very specialized
: > : > thing in which writing in Java, then JIT, makes it run faster than C,
: > : > but I can't think of one right now.
: >
: > : The Cygnus Java compiler isn't a JIT. It's a JBT (just before time).
: >
: > What is JBT?

: Just Before Time :-)

So what is "Just Before Time"? Before what time?

: --
: The idea that an arbitrary naive human should be able to properly use
: a given tool without training or understanding is even more wrong for
: computing than it is for other tools (eg automobiles, airplanes, guns
: or power saws).


author: Pavel Shtemenko

subject: PSD

text:
I read in SMP.INF from latest DDK about DosCallPSD. I write PSD driver
and export PSD_APP_COMM. PSD driver load and work. Where I can to find
LIB for make R3 APP program,  which can to use DosCallPSD ?


author: Lars Erdmann

subject: Re: PSD

text:
Pavel Shtemenko wrote:
DosCallPSD was never implemented. You won't find it anywhere.

Lars


subject: PSD

text:
New trouble. I link my PSD as 32 bit DLL.  if I insert "DESCRIPTION
"xxx" to link, then OS/2 can't load this PSD. If I remove - load. Why?
In os2boot I set  this and it work. os2boot load before PSD.


subject: Re: PSD

text:
Hi Pavel,

by the way, you should have a look here:

http://www.mail-archive.com/[email]/

There has been a lengthy discussion about ACPI on OS/2 and you might get
some additional info. Daniela Engert had started on a ACPI PSD for OS/2.
Unfortunately the work stopped but maybe she had achieved something that
she would be willing to pass on to others ...

About DosCallPSD: Scott Garfinkle should know for sure.

Lars

Pavel Shtemenko wrote:


subject: Re: PSD and DESCRIPTION strings - I found a solution !

text:
Hallo Pavel,

I found a workaround for adding a description string to the PSD:

if you are using VAC (and you said you did) add this line to the
beginning of any source file (as an example, of course adjust the text
to your needs):
#pragma comment(copyright,"@#Shtemenko:1.0.0#@My Test PSD driver")

Then you

1.) will be able to build the PSD
2.) bldlevel.exe will report the description string
3.) the PSD will NOT trap on bootup

I have no explanation for this apart from that the PSD file load kernel
routine SYIReadFile fails on a PSD with a description string added
through the .def file.

Lars

Pavel Shtemenko wrote:


subject: Re: PSD

text:
Pavel Shtemenko wrote:

To come back to your question:
could you please also list the DESCRIPTION string you intend to use.
Maybe,maybe,maybe you can also influence success by linking without
debug info, packing code segments and data segments, linking with
EXEPACK or without and the like.
What compiler and linker and what settings are you using ? Maybe it's
easier if you show us the makefile :-)
Also, the function names including '@' might indeed be a problem in
connection with the DESCRIPTION string that will likely also include
this symbol but that's just a guess.

By the way: what has OS2BOOT to do with it ? Or are you just referring
to the fact that OS2BOOT also has a DESCRIPTION string defined so that
bldlevel.exe can return some info ?

Lars


author: Daniela Engert

subject: Re: PSD

text:
Lars Erdmann wrote:

All of my stuff *was* passed to others - most notably Pavel.
I had a discussion with Scott regarding DosCallPSD more than a year ago.
I'd rather "inject" a fake device driver header into the device chain
dangling off the system anchor segment (SAS).

Ciao,
   Dani


subject: Re: PSD

text:
On Sun, 13 Mar 2005 00:44:37, Lars Erdmann <[email]>
wrote:

 LE> Pavel Shtemenko wrote:
"DESCRIPTION
Why?
 LE> How does you .def file look like ?

for Link386.exe
---------------------------------------------------------
$(O)\acpi.def: makefile
         rem creating def file<<$@
LIBRARY ACPI
EXPORTS
   PSD_INSTALL          = _Install@4
   PSD_DEINSTALL        = _DeInstall@0
   PSD_INIT             = _Init@4
   PSD_GET_NUM_OF_PROCS = _GetNumOfProcs@0
   PSD_PROC_INIT	= _ProcInit@0
   PSD_APP_COMM         = _AppComm@4
   PSD_START_PROC       = _StartProcessor@4
   PSD_GEN_IPI          = _GenIPI@4
   PSD_END_IPI          = _EndIPI@4

<<keep
----------------------------------------------------------------------
-----

if I insert DESCRIPTION -> psd can't load


subject: Re: PSD

text:
On Sun, 13 Mar 2005 22:25:36, Lars Erdmann <[email]>
wrote:

 LE> Pavel Shtemenko wrote:
"DESCRIPTION
Why?

 LE> To come back to your question:
 LE> could you please also list the DESCRIPTION string you intend to
use.
 LE> Maybe,maybe,maybe you can also influence success by linking
without
 LE> debug info, packing code segments and data segments, linking with

 LE> EXEPACK or without and the like.
 LE> What compiler and linker and what settings are you using ? Maybe
it's
 LE> easier if you show us the makefile :-)
 LE> Also, the function names including '@' might indeed be a problem
in
 LE> connection with the DESCRIPTION string that will likely also
include
 LE> this symbol but that's just a guess.
  I think - it has't problem. PSD load and working.

 LE> By the way: what has OS2BOOT to do with it ? Or are you just
referring
 LE> to the fact that OS2BOOT also has a DESCRIPTION string defined so
that
 LE> bldlevel.exe can return some info ?
 It is def for FAT32 MiniIFS which I make and test. But it write in
ASM, so '@' is absent ;-) linking Link.exe as usialy.  Linking switch
- by default. exepack 2 by default.
----------------------------------------------------------------------
---
LIBRARY OS2BOOT
EXETYPE os2
DESCRIPTION "@#Netlabs:1.00.1#@ FAT32 Boot. (c) Pavel Shtemenko 2002"
DATA PRELOAD MOVABLE
CODE PRELOAD MOVABLE
PROTMODE
EXPORTS
;   FS_ALLOCATEPAGESPACE             ; Optional
    FS_ATTACH
    FS_CHDIR
    FS_CHGFILEPTR
    FS_CLOSE
    FS_COMMIT
    FS_COPY
    FS_DELETE
    FS_EXIT
    FS_FILEATTRIBUTE
    FS_FILEINFO
    FS_FILEIO                        ; Optional
    FS_FINDCLOSE
    FS_FINDFIRST
    FS_FINDFROMNAME
    FS_FINDNEXT
    FS_FINDNOTIFYCLOSE              ; Obsolete in OS/2 WARP
    FS_FINDNOTIFYFIRST              ; Obsolete in OS/2 WARP
    FS_FINDNOTIFYNEXT               ; Obsolete in OS/2 WARP
    FS_FLUSHBUF
    FS_FSCTL
    FS_FSINFO
    FS_INIT
    FS_IOCTL
    FS_MKDIR
    FS_MOUNT
    FS_MOVE
    FS_NEWSIZE
    FS_NMPIPE
    FS_OPENCREATE
;   FS_OPENPAGEFILE                 ; Optional
    FS_PATHINFO
    FS_PROCESSNAME
    FS_READ
    FS_RMDIR
    FS_SETSWAP
    FS_SHUTDOWN
    FS_WRITE

    FS_ATTRIBUTE
    FS_NAME
;;    FS_MPSAFEFLAGS2
;
; MINI FSD entry points
;
    MFS_CHGFILEPTR
    MFS_CLOSE
    MFS_INIT
    MFS_OPEN
    MFS_READ
    MFS_TERM


subject: Re: PSD

text:
Hallo,

Daniela Engert wrote:

Oops, didn't know that. But now I understand why Pavel is working on an
ACPI driver (very good).

0.) DosCallPSD therefore doesn't exist. That would just have been too
easy :-)

1.) I don't yet see how a device driver header could be injected. PSDs
are loaded first or will the driver loading always append to the current
end of the device driver header chain ? Also how can I tie PSD_APP_COMM
routine address to that device driver header ? After all I can only
specify a 16-bit offset for the strategy routine.

2.) How about usable IRQs ? PSDHELP_SET_IRQ allows to hook IRQs up to 31
(and even bind to arbitrary interrupt vectors so that seems to be the
way to map ACPI IRQs > 15 to "normal" IRQs <= 15) but will
DevHelp_SetIRQ allow to specify values > 15 (and what about the Resource
Manager) ? Did Scott answer this question ?

3.) Are there more specs than the lean SMP.INF ? Pavel specified flag
values for PSD_INIT that I didn't even find mentioned in the SMP.INF
first edition from 1994.

Maybe we can better take this to the os2ddprog group in Yahoo.

Lars


subject: Re: PSD

text:
On Mon, 14 Mar 2005 16:33:39, Daniela Engert <[email]>
wrote:

 DE> Lars Erdmann wrote:
might get
for OS/2.
something that
 DE> All of my stuff *was* passed to others - most notably Pavel.
 DE> I had a discussion with Scott regarding DosCallPSD more than a
year ago.
 DE> I'd rather "inject" a fake device driver header into the device
chain
 DE> dangling off the system anchor segment (SAS).
  I think what method OpenJFS/Bootable (in CVS) is better ;-) I had to
use it in boot from JFS. This subroute find loaded 32bit dll in kernel
and get address of export function. I can to get PSD_APP_COMM from it.
But it only for R0.


subject: Re: PSD

text:
Looks ok to me, but what is this @... at the end of the function names ?
Are these supposed to be ordinals for the functions ?
If yes, they have to be unique.

Lars

Pavel Shtemenko wrote:


subject: Re: PSD - Load of DESCRIPTION string failing

text:
Hi Pavel,

I just hacked a "Hello world" PSD.

There is NO problem with the description string.
Currently the PSD traps before even the first function in the PSD is
called but funny enough, the system then continues to boot successfully
(and calls a couple of functions in the PSD). I am currently working to
nail the problem down.

When I am done, I can send you the sources and makefile if you want.

The tools that I used:
VAC 3.08 compiler:
IBM VisualAge C++ for OS/2, Version 3
(C) Copyright IBM Corp. 1991, 1995.
- Licensed Materials - Program Property of IBM - All Rights Reserved.

VAC 3.08 linker:
IBM(R) Linker for OS/2(R), Version 01.08.r1a_CTC308cEuro
(C) Copyright IBM Corporation 1988, 1997.
(C) Copyright Microsoft Corp. 1988, 1989.
  - Licensed Material - Program-Property of IBM - All Rights Reserved.

I have fixpak 8 for VAC 3.0 installed and additionally the "Euro" fix
(eurofix.zip).

Lars

Pavel Shtemenko wrote:


subject: Re: PSD

text:
On Mon, 14 Mar 2005 17:27:34, Lars Erdmann <[email]>
wrote:

 LE> Hallo,

might
PSD for
something
year ago.
chain
 LE> Oops, didn't know that. But now I understand why Pavel is working
on an
 LE> ACPI driver (very good).
 LE> 0.) DosCallPSD therefore doesn't exist. That would just have been
too
 LE> easy :-)
   I have the way to resolve it.
 [ Skipped ]
 LE> 2.) How about usable IRQs ? PSDHELP_SET_IRQ allows to hook IRQs
up to 31
 LE> (and even bind to arbitrary interrupt vectors so that seems to be
the
 LE> way to map ACPI IRQs > 15 to "normal" IRQs <= 15) but will
 LE> DevHelp_SetIRQ allow to specify values > 15 (and what about the
Resource
 LE> Manager) ? Did Scott answer this question ?
  As I remember, IDT in OS/2 for 15 IRQ only. It isn't a big problem,
IDT changable from R0 .Problem can be in Dev_Hlp_SetIRQ

 LE> 3.) Are there more specs than the lean SMP.INF ? Pavel specified
flag
 LE> values for PSD_INIT that I didn't even find mentioned in the
SMP.INF
 LE> first edition from 1994.
  It Flag specified in psd.h.


subject: Re: PSD

text:
Lars Erdmann wrote:

I didn't say I was easy ...

DevHelp_SetIRQ is probably a show stopper regarding exploiting
up-to-date interrupt delivery (message signalled interrupts, APIC
interrupts)

AFAIK no.

There are the sources of PSDs, and there's other info.

This rather belongs to the ACPI related discussions on Netlabs.

Ciao,
   Dani


subject: Re: PSD

text:
Pavel Shtemenko wrote:

Great! Either way that works is fine :-)

Ciao,
   Dani


author: Ruediger Ihle

subject: Re: PSD

text:
On Tue, 15 Mar 2005 11:44:54 UTC, [email] (Pavel Shtemenko)
wrote:

So you will either need another device driver to establish
communication with R3 applications or you integrate this
driver directly into the PSD itself. IMHO, the latter case
would basically resemble Daniela's proposal.


subject: Re: PSD

text:
On Sun, 13 Mar 2005 10:24:56, Lars Erdmann <[email]>
wrote:

 LE> Looks ok to me, but what is this @... at the end of the function
names ?
 LE> Are these supposed to be ordinals for the functions ?
 LE> If yes, they have to be unique.
  It is standard naming function in VAC:
   _FunctionName@LengthOfParameterInBytes.


text:
On Thu, 17 Mar 2005 23:51:08, Lars Erdmann <[email]>
wrote:

 LE> I just hacked a "Hello world" PSD.
 LE> There is NO problem with the description string.
 LE> Currently the PSD traps before even the first function in the PSD
is
 LE> called but funny enough, the system then continues to boot
successfully
 LE> (and calls a couple of functions in the PSD). I am currently
working to
 LE> nail the problem down.
  I today go from link386 to ilink /nofree. DESCRIPTION is work ;-)
This was problem link386, as I mean.


text:
Hi Pavel,

I have to correct myself. You are 100% correct in saying that defining a
  DESCRIPTION string will break the PSD.

If I have it specified the system will trap when the PSD is loaded.
If I remove if from the DEF file, the driver will load just fine.

Lars


subject: Re: PSD

text:
Cannot find PSD_KERNEL_PIC (0x10000000) in psd.h (as it is listed in
Appendix A in the OS/2 2.11 SMP.INF that I have).

Lars


subject: Re: PSD

text:
Sources for PSDs ? Where ? I haven't found anything in the DDK ...

Is that group still alive ? How can one register ?

Lars


subject: Re: PSD

text:
On Wed, 16 Mar 2005 14:52:16, "Ruediger Ihle" <[email]>
wrote:

 RI> So you will either need another device driver to establish
 RI> communication with R3 applications or you integrate this
 RI> driver directly into the PSD itself. IMHO, the latter case
 RI> would basically resemble Daniela's proposal.
  For ACPI need more drivers, then only PSD ;-) In driver I can create
place for call DosDevIOCtl, which will to call PSD over my stuff


author: Michal Necasek

subject: Re: PSD

text:
Pavel Shtemenko wrote:

  It is certainly not. The default in VAC is _Optlink calling
convention, which doesn't decorate names in any way. What you have there
looks like __stdcall, ie. the Win32 API convention.

  I believe the PSDs were initially(?) built with cl386, but I don't
have it at hand to check what calling convention it used by default.

  Since the callee is apparently removing arguments from the stack in
PSDs, it could be _Pascal or __stdcall. I would advise to double check
which one it really is, as the saved/modified register set differs
between calling conventions. If you get it wrong, you'll waste lots of
time tracking down why register xyz is getting trashed.

         Michal


subject: Re: PSD

text:
On Sun, 13 Mar 2005 12:39:28 UTC, [email] (Pavel Shtemenko) wrote:

Really ?  This kind of name decoration is normally used for a pascal - alike
calling convention (i.e. one that goes crazy, when the number of arguments
doesn't  match). I don't think that the "optlink" convention normally used by
VAC belongs to this category. But maybe this depends on the VAC version...

BTW, the PSD document says:
"The PSD functions must conform to the C calling convention."

So I suspect, it's not a good idea anyway to use some compiler's default
convention. Instead' you should specify "CDECL" or "APIENTRY" for your
entry points, which will most likely remove these @xyz from the names.


text:
Pavel Shtemenko wrote:

No, I was using ILINK.EXE all the time and it trapped. I rather think it
is a matter of how long the object module is, where in the binary the
description string ends up, if you have debug info in your binary etc.

But see my other post:
#pragma comment(copyright,"@#PS:1.00.1#@ACPI PSD Driver. Pavel Shtemenko
2005")

in one of your source files seems to work reliably.

Lars


text:
On Sat, 19 Mar 2005 23:44:03, Lars Erdmann <[email]>
wrote:

 LE> Hi Pavel,

 LE> I have to correct myself. You are 100% correct in saying that
defining a
 LE>   DESCRIPTION string will break the PSD.
  ;-)
 LE> If I have it specified the system will trap when the PSD is
loaded.
 LE> If I remove if from the DEF file, the driver will load just fine.
  Now I have next:
----------------------------------------
LIBRARY ACPI
DESCRIPTION "@#PS:1.00.1#@ACPI PSD Driver. Pavel Shtemenko 2005"
PROTMODE
DATA PRELOAD SINGLE SHARED MOVABLE
CODE PRELOAD MOVABLE
EXPORTS
   PSD_INSTALL          = _Install@4
   PSD_DEINSTALL        = _DeInstall@0
   PSD_INIT             = _Init@4
   PSD_GET_NUM_OF_PROCS = _GetNumOfProcs@0
   PSD_PROC_INIT	= _ProcInit@0
   PSD_APP_COMM         = _AppComm@4
   PSD_START_PROC       = _StartProcessor@4
   PSD_GEN_IPI          = _GenIPI@4
   PSD_END_IPI          = _EndIPI@4
--------------------------------------
 It work if use ILINK and not work if use LINK386


subject: Re: PSD

text:
On Wed, 16 Mar 2005 01:47:07, Lars Erdmann <[email]>
wrote:

specified

 LE> Cannot find PSD_KERNEL_PIC (0x10000000) in psd.h (as it is listed
in
 LE> Appendix A in the OS/2 2.11 SMP.INF that I have).
  I know 4 different version of SMP.INF. What the versionyou are mean?


subject: Re: PSD

text:
Lars Erdmann wrote:

Sources are sitting on a CD somewhere in a pile of stuff on my desk.

Well, it's as alive as "Dead or Alive"...  ;-)
You have to ask Adrian.

Ciao,
   Dani


subject: Re: PSD

text:
SMP.INF says that all registers are preserved except EAX.
So this is not an issue.

The only issue is with routines with > 1 parameters (as the parameters
are pushed differently for _Pascal and for __stdcall) but the only
routine affected is PSD_APP_COMM but the API routine to call that
(DosCallPSD) was never implemented in OS/2 so Pavel is free to choose
the calling convention as he will make a more or less huge effort to
attach to that entry point from a user application.

I have written a PSD as a test and tried both (_Pascal and __stdcall)
and it didn't make a difference.

P.S.: Yes, seems that PSDs were written with cl386.exe. At least the
sample code in SMP.INF gives this indication. And not only Win32 uses
__stdcall but also Borland for OS/2 as its default calling convention.

Lars

Michal Necasek wrote:


subject: Re: PSD

text:
On Sun, 13 Mar 2005 13:40:03, "Ruediger Ihle" <[email]>
wrote:

 RI> On Sun, 13 Mar 2005 12:39:28 UTC, [email] (Pavel
Shtemenko) wrote:

 RI> Really ?  This kind of name decoration is normally used for a
pascal - alike
 RI> calling convention (i.e. one that goes crazy, when the number of
arguments
 RI> doesn't  match). I don't think that the "optlink" convention
normally used by
 RI> VAC belongs to this category. But maybe this depends on the VAC
version...
 It is listing with /Fa
	public _Init@4
_Init@4	proc
	push	ebp
	mov	ebp,esp

; 172         pinit->flags = PSD_KERNEL_PIC;
	mov	eax,[ebp+08h];	pinit
	mov	dword ptr [eax],010000000h

; 173         pinit->version = VERSION;
	mov	eax,[ebp+08h];	pinit
	mov	dword ptr [eax+04h],01h

; 174         return(NO_ERROR);
	mov	eax,0h
	pop	ebp
	ret	04h
_Init@4	endp

  I look HIEW to os2apic.psd. It's same Only _Init@4 called _Init in
sym file..

 RI> BTW, the PSD document says:
 RI> "The PSD functions must conform to the C calling convention."
  PSD document say:
   DosCallPSD - ... e.t.c. ;-)
 RI> So I suspect, it's not a good idea anyway to use some compiler's
default
 RI> convention. Instead' you should specify "CDECL" or "APIENTRY" for
your
 RI> entry points, which will most likely remove these @xyz from the
names.
  Export from PSD has rigth names. Names inside need only for my
debug.


author: Bob Eager

subject: Re: PSD

text:
On Sun, 13 Mar 2005 13:40:03 UTC, "Ruediger Ihle" <[email]>
wrote:

Nothing to with with VAC itself. If you are writing a function where al
call involves a ring transition, you use this syntax to specify the
number of bytes to be copied from one stack to another.

It doesn't change the calling convention.


subject: Re: PSD

text:
Lars Erdmann wrote:

  Preserved by whom? By the caller?

  You're right. That is bizarre, as __stdcall does not allow functions
with variable arguments. Moreover, Borland does not decorate function
names with trailing '@xxx'.

       Michal


subject: Re: PSD

text:
On Sun, 13 Mar 2005 14:15:21 UTC, [email] (Pavel Shtemenko) wrote:

Including the "ret 04h"  ?


subject: Re: PSD

text:
On Sun, 13 Mar 2005 14:32:51 UTC, "Bob Eager" <[email]> wrote:

No, the number of words to be copied is not preceeded by an '@'.
The syntax is:

EXPORTS
  entryname [=internalname] [@ordinal [RESIDENTNAME]] [numwords]


subject: Re: PSD

text:
Michal Necasek wrote:

Yes. I didn't worry and it worked right away except for this bizarre
problem that any PSD will trap if you add a DESCRIPTION string. But this
obviously is a problem of the PSD file load/read done by kernel routine
"SYIReadFile".
PSD has a real strange file format as it is marked to be LIBRARY but no
_Init_Term routine is allowed so there is no chance to use subsystem
library from VAC for example. In fact, the source files have to be
compiled with /Ge+ (compile for executable).

Variable argument lists: why not ? __stdcall pushes from right to left
just like _Cdecl does. That should allow for variable arguments lists,
shouldn't it ?

Lars


subject: Re: PSD

text:
On Sun, 13 Mar 2005 14:58:29, "Ruediger Ihle" <[email]>
wrote:

 RI> On Sun, 13 Mar 2005 14:15:21 UTC, [email] (Pavel
Shtemenko) wrote:

 RI> Including the "ret 04h"  ?
Yes


subject: Re: PSD

text:
Lars Erdmann wrote:

  Yeah... but how exactly is the called function supposed to know how
many bytes to pop off the stack?

        Michal


subject: Re: PSD

text:
On Sun, 13 Mar 2005 18:03:10 UTC, [email] (Pavel Shtemenko) wrote:

Interesting. Looking a some PSD disassembling myself it appears
that they are using a 32-bit pascal calling convention. Next thing,
that doesn't match the docs, because at least my copy of SMP.INF
says otherwise.

Anyway, if the '@' are really the problem you might try to either put
the names in hyphens like this:

PSD_INIT = '_Init@4'

or try to declare your Init() as __pascal.


subject: Re: PSD

text:
Michal Necasek wrote:
Oops, you're right. Overlooked that.

Lars


subject: Re: PSD

text:
Ruediger Ihle wrote:

Your copy says the same as mine. Well we learned to mistrust IBM's docs,
don't we ?

Very good idea. I have the bad feeling that this might negatively
interact with the DESCRIPTION string that likely also uses the '@' symbol.

Also, I get different results. This function (the only keyword that
works for VAC is _Pascal):

ULONG _Pascal shit(ULONG m1,ULONG m2)
{
     if (m1 > 4000)
     {
         return m2+m1;
     }
     else
     {
         return m2-m1;
     }
}

results in this assembler code:
; 5 ULONG _Pascal shit(ULONG m1,ULONG m2)
        align 04h

        public SHIT
SHIT   proc
        push    ebp
        mov     ebp,esp

; 7     if (m1 > 4000)
        cmp     dword ptr [ebp+0ch],0fa0h;      m1
        jbe     @BLBL3

; 8     {
; 9         return m2+m1;
        mov     eax,[ebp+0ch];  m1
        add     eax,[ebp+08h];  m2
        leave
        ret     08h
@BLBL3:

; 10     }
; 11     else

; 12     {
; 13         return m2-m1;
        mov     eax,[ebp+08h];  m2
        sub     eax,[ebp+0ch];  m1
        leave
        ret     08h
SHIT   endp

And this is the compiler call (VAC 3.08):
icc.exe /Q /Ti /Ft- /Fa /C filename.cpp (forcing the C++ compiler to run)

Lars


subject: Re: PSD

text:
On Sun, 13 Mar 2005 19:20:56, "Ruediger Ihle" <[email]>
wrote:

 RI> On Sun, 13 Mar 2005 18:03:10 UTC, [email] (Pavel
Shtemenko) wrote:

 RI> Interesting. Looking a some PSD disassembling myself it appears
 RI> that they are using a 32-bit pascal calling convention. Next
thing,
 RI> that doesn't match the docs, because at least my copy of SMP.INF
 RI> says otherwise.
 RI> Anyway, if the '@' are really the problem you might try to either
put
 RI> the names in hyphens like this:
 RI> PSD_INIT = '_Init@4'
  It has't problem. All function called by kernel and work as write.
all function has 1 parameter or below, so calling different between C
and other.

 RI> or try to declare your Init() as __pascal.
 Or _stdcall ? ;-)


subject: Re: PSD

text:
Pavel Shtemenko wrote:

Good question: this only becomes relevant for more than 1 parameters as
the parameter pushing is just the opposite for pascal and for stdcall
(while the stack cleanup is the same).
The only routine that is affected is PSD_APP_COMM as it takes 2 parameters.
Maybe that's why they dropped that routine, they never could agree on
the calling convention :-)

Lars


subject: Re: PSD

text:
On Tue, 15 Mar 2005 12:16:03 UTC, [email] (Pavel Shtemenko)
wrote:

But unlike _stdcall _pascal should upcase the name, not
prepend a '_' and not append '@LengthOfParameterInBytes'.

But anyway, looking a the orginial OS2APIC.PSD, I can see
that it doesn't have a description either. So maybe, you
are hitting another one of these obscure 'features' some-
times called bugs...


subject: Re: PSD

text:
On Wed, 16 Mar 2005 01:20:00, Lars Erdmann <[email]>
wrote:

 LE> Pavel Shtemenko wrote:

 LE> Oh, are you using Borland ?
   VAC 3.6.5


subject: Re: PSD

text:
On Wed, 16 Mar 2005 01:39:13, Lars Erdmann <[email]>
wrote:

 LE> Pavel Shtemenko wrote:
appears

SMP.INF
either
write.
between C
 LE> Good question: this only becomes relevant for more than 1
parameters as
 LE> the parameter pushing is just the opposite for pascal and for
stdcall
 LE> (while the stack cleanup is the same).
 LE> The only routine that is affected is PSD_APP_COMM as it takes 2
parameters.
 LE> Maybe that's why they dropped that routine, they never could
agree on
 LE> the calling convention :-)
  But you say, what this function not implemented? Then I make call as
I want.


subject: Re: PSD

text:
Hi Pavel,

True. However, I would think it's good design practice that PSD_APP_COMM
at least has the same calling convention as all the other exported entry
points.
If a newer version of SMP.INF states, that all entry points use the
__stdcall calling convention, I would then use the __stdcall calling
convention.
But of course, you are making the decisions.

As far as the version of SMP.INF is concerned, I have this version:

10.06.96  16.38     111052           0  smp.inf

It's entitled "OS/2 SMP V2.11 Reference" and the Notices page states
that it is "First Edition (June 1994).
It was part of the "IBM Developer Connection Device Driver Kit for OS/2
Version 4" from 1996.

I would be really happy if you could send me a newer version of that
document.

Lars


subject: Re: PSD

text:
On Wed, 16 Mar 2005 21:25:06, Lars Erdmann <[email]>
wrote:

for
takes 2

call as
 LE> True. However, I would think it's good design practice that
PSD_APP_COMM
 LE> at least has the same calling convention as all the other
exported entry
 LE> points.
 LE> If a newer version of SMP.INF states, that all entry points use
the
 LE> __stdcall calling convention, I would then use the __stdcall
calling
 LE> convention.
 LE> But of course, you are making the decisions.
 I like __stdcall too ;-)

 LE> As far as the version of SMP.INF is concerned, I have this
version:

 LE> 10.06.96  16.38     111052           0  smp.inf
 LE> It's entitled "OS/2 SMP V2.11 Reference" and the Notices page
states
 LE> that it is "First Edition (June 1994).
 LE> It was part of the "IBM Developer Connection Device Driver Kit
for OS/2
 LE> Version 4" from 1996.
 LE> I would be really happy if you could send me a newer versio
n of that
 LE> document.

  1. smp.inf              О©╫    983712    has't DosCallPSD
  2. SMP.INF          О©╫    111052   has DosCallPSD

entitled same. 1 I don't remeber where, 2 from latest DDK (before
today)


author: John Pettigrew

subject: GnuPG query

text:
I've just installed GnuPG to use with MessengerPro 2. It seems to work fine -
it will verify PGP sigs and has generated a key for me with no problem.
However, I then tried to submit my public key to a key server. Exporting the
key and submitting it caused the server to complain that it wasn't a valid
key ("didn't decode correctly" or something like that). Can anyone tell me
how to get the public key out there? (it's currently displayed on my web
page, see below).

TiA,

John


author: Stefan Bellon

subject: Re: GnuPG query

text:
John Pettigrew <[email]> wrote:

[snip]

Another point which I've seen just right now: You've embedded your
public key on your web page into HTML. This means it looks like this:

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.0.6-sb1 (RISC OS)

Comment: For info see http://www.gnupg.org

mQGiBDsxuMwRBADF2bGiZx+mf/MEDpXatZEmeO/QhHzgwrlYj8eX9LUT8jEUApM8

l/o7xbLfm6OlOGcsw/+wQhTp55PmEa9brm2ViK4O0r5DN0UZN06sTHIcxcEENAxU

UnnpC0mOoZR8ea5I3oN+87WBMXKkXY4LCTvXvB5oNm3uxzkwcYTbuy7jUwCgoa6D

P4q9NSCPstouDEM/QA7mHo0EAKuZHBV6J/ohA4GBuw+xmXvcpSksR9FrXIdkHGgO

uiSAdtQ/Z1nl7OpXGKegHV8dH2uvGDrz8Kqv/V6xOZMo0SnM2LE+xaOW7NEfFpX0

g2CZ2ApYQMGAzL0fRIpsmLUAeA7wb9bFesRfJeV7Rd8jpzmuFbmVfgwfcyVCHDgp

knX6BACyDyUw+79IuSMviH52zE/KtZEnPk4v3qqexhuee/FNXnDPay2oXwkS0C6d

xsVBxBVJvEwNYzd7hwV78auh5vv88KoVuqetFMeDS+cJvI3vyQsHxfWXmp2utF5a

[...]

Which is not really a Good Thing.

Just calling the file 'pgp.asc', placing it in the root directory of
your web space and refering to it as
http://www.xl-cambridge.com/pgp.asc instead of
http://www.xl-cambridge.com/pgp/ would be one solution.

Greetings,

Stefan.


subject: Re: GnuPG query

text:
John Pettigrew <[email]> wrote:

Good step! ;-)

Of course. ;-)

Nice to get some positive feedback. :-)

If I read your sentence correct, then you exported the key and then
tried to send this exported key to the server. That is not the way it
is intended. It is sufficient to do:

   *gpg --keyserver <your_keyserver_of_choice> --send-keys <key_id>

No need to export the key first. Exporting keys is for sending them to
friends by email, publishing it on a web site, ...

See above. Hope this helps.

Greetings,

Stefan.


subject: Re: GnuPG query

text:
In a previous message, Stefan Bellon wrote:

[snip]

Well, it lets people copy and paste it from the web page. Or would this not
work properly?

I've also included it as a .txt file linked from that page. However, my web
address is currently forwarded to the real host, and the forwarding doesn't
allow named files in this way.  :-(   Hence the subdirectory, which it does
allow.

BTW, is there any advantage to using .asc rather than .txt?

Thanks,

John


subject: Re: GnuPG query

text:
In a previous message, John Pettigrew wrote (sorry, following up my own post)

I've now changed this so that the key is linked from my front page. Thanks
for the advice, though.

I'd still like to know this, though  :-)


subject: Re: GnuPG query

text:
John Pettigrew <[email]> wrote:

[snip]

You're welcome. :-)

[snip]

Right, --send-keys without an key id sends all keys in the keyring to
the server (IIRC).

That's good.

Perhaps you could mention this on the MPro list? I'm open with whatever
information Mark Sawle needs in order to make use of GnuPG's full
capabilities if he wants to.

It should work this way, yes.

It is correct this way. The last line will always contain such a four
character thing. You can as well see this with my key blocks on my home
page. They're a checksum for the ascii armoured key block. This way
transmission errors can be spotted more quickly.

You can test this in the following way:

* Remove the last line containing the "=dviw" (in your case)
* Do an gpg -nv <file_with_modified_key_block>
  This will complain about the wrong checksum
* Then do the same with the --ignore-crc-error and it should work again

NB: This checksum has no cryptographic value. It's just for testing the
correctness of the armoured block in a fast way. There are other ways
of finding out manipulations in the key block itself.

You're welcome.

Greetings,

Stefan.


subject: Re: GnuPG query

text:
John Pettigrew <[email]> wrote:

[snip]

To answer a question from your last posting: if those HTML tags are in
the key, people can't just copy it from your web site and import it.
That's why I suggested to let them download a text version.

Nothing more than convention. PGP 2 only accepted the file as a key
block if it had a "known" ending.

Greetings,

Stefan.


author: Jura

subject: ISDN PRI dialout call problem

text:
Hi,

I have problem when I need to make dialout call over ISDN PRI interface.
Dialin calls work just fine, but when I need to make a callback or initiate
dialout call there is a problem.
One confusing thing is that dialout/callback calls work fine for local
numbers (on our local PBX) but problem is for remote numbers.
Platform: AS5300, 12.1.9 IOS

telnet ethernet_ip 2061
atd4151 (works fine)

telnet ethernet_ip 2061
atd0611111 (doesn't work)

Here is a sample from debug when initiating local and remote call.
I suspect it some sort of problem with signalization on D channel.

This is a local number call and it works (although it seems to have some
problem with ETSI
...)===============================================================
Feb 28 13:15:26: ISDN Se1:15: TX ->  SETUP pd = 8  callref = 0x001F
Feb 28 13:15:26:         Bearer Capability i = 0x8090A3
Feb 28 13:15:26:         Channel ID i = 0xA9839B
Feb 28 13:15:26:         Called Party Number i = 0x81, '4151', Plan:ISDN,
Type:Unknown
Feb 28 13:15:26: ISDN Se1:15: RX <-  SETUP_ACK pd = 8  callref = 0x801F
Feb 28 13:15:26:         Channel ID i = 0xA9839B
Feb 28 13:15:26: ISDN Se1:15: RX <-  CALL_PROC pd = 8  callref = 0x801F
Feb 28 13:15:26: ISDN Se1:15: RX <-  ALERTING pd = 8  callref = 0x801F
Feb 28 13:15:26:         Facility i =
0x91AA068001008201008B0100A11C02010106042B0C090180116D6F64656D2D46726967616E
6F76696320
Feb 28 13:15:26:        - ETSI Supplementary Service, Unknown component,
Unsupported operation
Feb 28 13:15:26:         Progress Ind i = 0x8088 - In-band info or
appropriate now available
Feb 28 13:15:26:         Progress Ind i = 0x8082 - Destination address is
non-ISDN
Feb 28 13:15:26:         Shift to Codeset 5
Feb 28 13:15:26:         Codeset 5 IE 0x32  i = 0x81

Remote number dialout (this doesn't work)
================================================
Feb 28 13:14:59: ISDN Se0:15: TX ->  SETUP pd = 8  callref = 0x001E
Feb 28 13:14:59:         Bearer Capability i = 0x8090A3
Feb 28 13:14:59:         Channel ID i = 0xA9839E
Feb 28 13:14:59:         Called Party Number i = 0x81, '009845161',
Plan:ISDN, Type:Unknown
Feb 28 13:14:59: ISDN Se0:15: RX <-  SETUP_ACK pd = 8  callref = 0x801E
Feb 28 13:14:59:         Channel ID i = 0xA9839E
Feb 28 13:14:59: ISDN Se0:15: RX <-  PROGRESS pd = 8  callref = 0x801E
Feb 28 13:14:59:         Progress Ind i = 0xA090 - Reserved value
Feb 28 13:14:59: ISDN Se0:15: TX ->  STATUS pd = 8  callref = 0x001E
Feb 28 13:14:59:         Cause i = 0x80E41E - Invalid information element
contents
Feb 28 13:14:59:         Call State i = 0x02
Feb 28 13:14:59: ISDN Se0:15: RX <-  RELEASE pd = 8  callref = 0x801E
Feb 28 13:14:59:         Cause i = 0x80E57D - Message not compatible with
call state
Feb 28 13:14:59: ISDN Se0:15: TX ->  RELEASE_COMP pd = 8  callref = 0x001E
Feb 28 13:14:59:         Cause i = 0x80E4 - Invalid information element
contents

cheers,
Jura


author: Dave Phelps

subject: Re: ISDN PRI dialout call problem

text:
I'm just taking a stab here.

I don't know about your country, but in the USA, we typically have to
dial an outside access code, usually 9, from a PBX. So a callout on the
same setup in the USA would be 9+1234567, where 9 is the outside access
code, and 1234567 is the destination phone number.

In article <[email]>, [email]
says...


subject: Re: ISDN PRI dialout call problem

text:
On our local PBX, 0 is for outside access.
I also have one IBM router wirh PRI card and it works just fine on that
router. Obviously, there is something wrong on Cisco, but I don't see why.
I forgot to mention but that Cisco router worked just fine for a long time
and our PBX guys have introduced caller-id on our PBX (now, when someone
calls us from outside, we see real number on our telephone displays) and
after that Cisco stopped working correctly and IBM still works just fine.
Of course, PBX guys swear that they didn't change anything that would mess
out setup and their proof is that other equipment still works. That sort of
caller ID messed up Cisco config.
Small excerpt from AS5300 config is:

isdn switch-type primary-net5
isdn voice-call-failure 0
!
controller E1 0
 clock source line primary
 pri-group timeslots 1-31
!
interface Serial0:15
 ip unnumbered FastEthernet0
 encapsulation ppp
 no logging event link-status
 dialer idle-timeout 600
 dialer-group 1
 isdn switch-type primary-net5
 isdn incoming-voice modem
 no peer default ip address
 no cdp enable
 ppp callback accept
 ppp authentication chap pap

"Dave Phelps" <[email]> wrote in message
news:[email]...
initiate
Plan:ISDN,
0x91AA068001008201008B0100A11C02010106042B0C090180116D6F64656D2D46726967616E
is
element
with
0x001E


author: YKhan

subject: New DOS shell for Windows coming

text:
Called the Monad shell, or MSH. It's supposed to be similar to BASH on
Unix environments.

http://www.tomshardware.com/hardnews/20050609_170105.html


subject: Re: New DOS shell for Windows coming

text:
A Jones wrote:

There hasn't been a Bourne Shell script that can't run in bash or ksh.
That's mainly because bash and ksh are descendents or upgrades of
bourne, of course. You can either write to the lowest common
denominator standard which is bourne, or write to one of its upgrades,
giving up on some portability for some extra features.

Yes, csh won't run bourne stuff very well, but it wasn't meant to, it's
a completely different language. Tcsh is csh's descendent.

Whatever.

   Yousuf Khan


subject: Re: New DOS shell for Windows coming

text:
Robert Redelmeier wrote:

I always liked 4DOS too, but I got into a few bad habits with it, like
using the file descriptions, which turned out not to be portable once I
moved from the DOS environment to the Windows one.

  Yousuf Khan


author: A Jones

subject: Re: New DOS shell for Windows coming

text:
On Thu, 09 Jun 2005 17:34:10 -0700, YKhan wrote:

I just hope Monad isn't as bad as bash.  Granted,  it's taken Microsoft
over 20 years to come up with a command line any better than DOS,  so
there's no reason to expect anything much from them,  but Holy crap, let
it not be as bad as bash.  It's been 30 -- count 'em -- 30 years that Unix
has given us this fragmented,  forked,  standards uncompliant,
horrifically architected,  spaghetti coded,  unformalized,  unspecified,
poorly documented,  parade of the goofiest,  most totally inept and inane
command shell/scripting languages imaginable.

Sorry,  the frustration of living with bash,  sh, csh, ksh, tcsh, etc. for
30 years just caused me to convulse and vomit forth the aforementioned
flames ...

Please,  Microsoft,  not another sh variant.  I beg you.


author: Grumble

subject: Re: New DOS shell for Windows coming

text:
YKhan wrote:

I can't help but read Gonad shell. (The shell real men use.)


subject: Re: New DOS shell for Windows coming

text:
On Sun, 12 Jun 2005 02:29:27 -0600, A Jones wrote:

I just wonder if M$ will keep all their arcane dos commands, you know how
annoying it is to move form a *nix to windows platform and have all the
goofy commands not work. You know how many times I have typed ls -l, in
dos just to remember its dir instead.

Man maybe you need some medical counseling, if you hate shells that
much, how did you put up with Windows for this long, especially Windows 98?

I dread to ask the question, of what specifically do you hate about the
bash shell, I find it well documented as well as any GNU software, just go
to gnu.org read up on it.  I know that some people just hate CLI, but then
again I don't have a problem with it, but then again I think using emacs,
and vim are pretty cool, I don't know what I would do without xterm.

As the old joke goes what is Xwindows used for? It used to switch between
xterms!  That kind of sums up what kind of a user I am, I love pipes,
find, and grep if M$ has a decent implementation of that then it might be
useful.

As far as feeding the trolls, I am sorry! I just find that gnu.org has
some fine decent documents.

Gnu_Raiz


author: Franc Zabkar

subject: Re: New DOS shell for Windows coming

text:
On Sun, 12 Jun 2005 14:26:57 -0500, Gnu_Raiz
<[email]> put finger to keyboard and composed:

Yeah, DIRectory makes a lot less sense that ls -l.

- Franc Zabkar


subject: Re: New DOS shell for Windows coming

text:
On Sun, 12 Jun 2005 14:26:57 -0500, Gnu_Raiz wrote:

Who cares?  The DOS batch language is one of the few programming languages
in use that's actually worse than Bash.  I'm sure MS will either maintain
backwards compatibility or keep the DOS interpreter around.  MS gets
routinely assaulted for its supposed neglect of backwards compatibility,
but all I can say is it's pretty hard to do worse than the fragmentation
under Unix,  with a half dozen or more shells,  all incompatible,  and
all equally bad.

I've always found DOS close to unusable,  so I just use a cygwin bash
shell or something else.  Bash is bad,  but it's usable,  just barely,
to do simple things.

The problem with Unix users is that they're almost all advocates,  so
they're unable to view the technology critically.  That's partly why
Unix systems have fallen so far behind in technology over the past 15
years or so,  while competing systems continued to progress.  I seem
to be one of the few Unix users who is willing to speak honestly about
the limitations and the great need for improvement.

There's a tiny minority of people who fall in love with typical Unix
technologies X Window, Emacs,  and Bash,  and are unable or unwilling to
see how much need they have for improvement.  This rare kind of person
likes technology,  likes being able to tweak their system, and likes being
able to do things in a quick and dirty way. But this kind of person
usually has little appreciation for theoretical issues, abstractions,
soundness, elegance,  or even good programming practices.

If you want to understand what's wrong with Bash,  all you need to do
is to compare it,  with its brief,  imprecise,  and amateurish
man documentation,  its murky semantics,  its wacky syntax,  its
spaghetti code implementation,  with almost any other language in
existence.  There is no evidence that the designers and maintainers of
Bash even know much of what's been learned about programming languages
in the past 30 or 40 years.  Check out the documentation and specifications for
languages like Java,  C#, OCaml,  Haskell,  Scheme,  ...,  even
something as purely commercial as Visual Basic,  if you want to
see the contrast with more competent efforts.  Also,  you might want to
visit the scsh web site.  Scsh is the only attempt at a shell I know
of by a competent computer scientist.

The other technologies you mention,  like X Window,  Emacs -- and I'd
add a number others to this list -- are all equally aimed at quick and
dirty use,  but are very poorly designed,  specified,  documented, and
implemented.


subject: Re: New DOS shell for Windows coming

text:
Franc Zabkar wrote:

Can't we all just get along? :-)

-rwxr-xr-x  1 root root 80972 Jul 25  2004 /bin/ls
-rwxr-xr-x  1 root root 80972 Jul 25  2004 /usr/bin/dir


author: Robert Redelmeier

subject: Re: New DOS shell for Windows coming

text:
A Jones <[email]> wrote:

You don't seem to make any distinction between a
programming language and a scripting language.

That would apply to many MS-Windows and Apple users moreso.

Progress is not a scalar, it is a vector.  There are many
different desireable attributes and different products weigh
them differently.  Even MS-Windows has a place.

I can see many improvements possible for Unix.  `bash` in
particular seems to have overworked the scripting language and
underworked interactive usability features.  4DOS.EXE has some
nice features, as does `tcsh`.

I love none of these, yet I like Unix and other Linux-like systems.

I have never heard anyone describe the bash manpage as "brief"!

`bash` also has the burden of backwards compatibility
and is a _scripting_ language.  I would hate to use any
one of these programming languages interactively.

I did.  Sorry, but it uses too many parentheses for quick CLI work.

-- Robert


subject: Re: New DOS shell for Windows coming

text:
On Thu, 16 Jun 2005 15:18:08 +0200, Grumble <[email]> put
finger to keyboard and composed:

To some extent you can define your own macros using DOSKEY:

 doskey ls=dir

Actually I intend to migrate to Linux when Win98se no longer cuts it.
I'm also a big user of the command line and I welcome any move to make
it more powerful and user friendly. In the past I've used several
minicomputer OSes, all with intuitive English CLIs. I've also used
Coherent, but it involved a *lot* of learning, more than I was
prepared to put in at the time. Unix (and its variants) has always
struck me as a cliquey, non-intuitive, boffin's language. I believe
that computing should be an extension of one's normal thought
processes. (That's why I've always avoided calculators that used RPN,
such as those made by HP, preferring calculators that supported
standard algebraic notation.)

Anyway, whether or not you like Bill, at least he has made computing
accessible. Any platform that perpetuates the old elitist us-and-them
relationship should die, IMHO.

FYI, 4DOS has recently become freeware, so a powerful replacement for
command.com and cmd.exe is already available.

- Franc Zabkar


subject: Re: New DOS shell for Windows coming

text:
On Thu, 16 Jun 2005 14:35:09 +0000, Robert Redelmeier wrote:

A scripting language is a kind of programming language.
Bash is reminiscent of BASIC.  I think of it sort of as
BASIC's crazy uncle.  It's got a weird and limited set
of data structures,  weird and limited looping constructs,
a weird and limited notion of function,  etc.  BASIC itself
is pretty mediocre,  but writing for its crazy uncle Bash
is pretty unpleasant.

The sad thing about Unix is that the technical incompetence
of its developers not only makes for lousy technology,
but also blinds its users to the need for improvement.  They think
weird things,  like a scripting language isn't a real programming
language,  so you don't need to know anything about programming
languages to create it.  They think they can write things like
that by the seat of their pants,  knowing nothing about computer
science,  or even being that good at programming.  And they end up
congratulating themselves for the superb job they've done, because they
don't know enough to realize that they should be working within the
framework of 4 decades of programming language research.  In that
tradition,  the crazy uncle of one of the lousiest languages to
survive from the 1960's wouldn't count for much,  but in the
Unix world,  it's treated with reverence,  like it's some
powerful and ingenious invention.  So you've got these technically
incompetent folks,  who know nothing about computer science,
who are even more clueless about usability and marketing,
calling each other gurus and congratulating themselves for
knowing more than the folks in Redmond.

And what you end up with,  is the Unix people let BASIC's crazy uncle
out of the attic,  and made him run a big part of the Unix
show.  And the other parts of the show are run by the other
loony systems,  like X Window and Emacs,  which are designed
with equal technical incompetence.


subject: Re: New DOS shell for Windows coming

text:
Franc Zabkar wrote:

Have you ever tried the *unoffical* Win98SE Service Pack?
http://exuberant.ms11.net/98sesp.html


subject: Re: New DOS shell for Windows coming

text:
Franc Zabkar <[email]> wrote:

Or the `bash` builtin `alias`.  Even my retro Slackware comes
configured with `dir` as an alias to `ls` [list], and `ls` itself
to `/usr/bin/ls $LS_OPTIONS` so you can fix whatever options
you want in the env.

It is until you know why things evolved the way they did.
Hint:  it was designed for paper teletypes at 110 baud.

Is this flamebait?  I always prefered HP RPN calculators for
_precisely_ the same reason.   I find multiple nested brackets
a necessary linear convention, but otherwise unintuitive.
I understand equations in terms of what must be grouped
together, often because of units.

Entirely true.  His bloatware has driven hardware ever
bigger and faster.

Good.  I always liked 4DOS.  Tell me, is the source also
available?  I'd like to replace `bash`, although I'm sure
it will need mods to do the filename expansion that the unix
shells do, but MS-DOS passes to pgms.

-- Robert


author: Tony Hill

subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 08:28:02 +1000, Franc Zabkar
<[email]> wrote:

Wow.. talk about a blast from the past.. I haven't used Doskey in
ages!  Just tested it though, still works in WinXP SP2 though!

Uhh.. did Win98se *EVER* cut it? :>

I've used a number of command lines over the years and never found any
of them to be intuitive.  Usable and sometimes very useful, yes, but
definitely not very intuitive.

Now that's even more of a blast from the past!  I haven't used 4Dos in
at least 10 years!

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca


author: Alexander Grigoriev

subject: Re: New DOS shell for Windows coming

text:
Well said, bro!

"A Jones" <[email]> wrote in message
news:[email]...


subject: Re: New DOS shell for Windows coming

text:
A Jones <[email]> wrote:

Yes, but it has _very_ different design objectives from
traditional [compiled] programming languages.  Fundamentally
designed for easy automation of command sequences by the typers
(not traditional programmers).  No large memory structures.
It is meant for very short programs.  A long script is as
much a misuse as "Hello, World" is in `c`.

Wierd to you.  Not necessarily to everyone.  I think of BASIC much
the same as I think of MS-Windows.  Seductively easy to learn,
but very limited (or contortions required) and not really to be
used beyond an introductory course or for very limited needs.

You are not the only person to dislike the Bourne shell.  Many
people did, and starting very early on.  `csh` was developed and
is the "primary" shell of *BSD systems.  Others went in direction
of the Korn shell.  Nothing stops you from working in the Scheme
shell if your work is original and valuable enough.

Flamebait.  Please moderate your language if you wish me to respond.

-- Robert


subject: Re: New DOS shell for Windows coming

text:
On Tue, 21 Jun 2005 14:24:27 +0200, Grumble <[email]> put
finger to keyboard and composed:

Looks interesting. I'm loathe to try it on my system, though, because
I've already applied a lot of the security patches. In any case the SP
doesn't provide a proper "undo" feature, so I'd only apply it to a
newly built machine. I did apply several of the tweaks, though. One
that had a dramatic effect was the addition of
"ConservativeSwapfileUsage=1" to the system.ini file. That alone was
worth the look.

Thanks.

- Franc Zabkar


subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 00:43:30 GMT, Robert Redelmeier
<[email]> put finger to keyboard and composed:

IIRC TI calculators used a 9-level stack, albeit a hidden one. In fact
one could access the stack on a TI-59 using undocumented instructions.
So it's clear that TI machines *evaluated* the expressions in the same
way as HP calculators, it's just that TI calculators *accepted*
expressions as they were written. No mental gymnastics were required.
Furthermore, the often touted claim that HP calculators were much more
economical with keystrokes was a myth which I disproved many a time.

In any case, whether or not RPN is better than algebraic is
irrelevant. My contention is that a person should not have to adapt to
technology, but that technology should adapt to him. For example, I
should be able to pick up any unfamiliar calculator and key in "1+2=",
not the counterintuitive "1 Enter 2 +". The inner workings should be
transparent to the user interface.

Not AFAIK, although this page suggests that it may go open source
someday:
 http://www.4dos.info/v4dos.htm

The actual v7.50 binaries are here:
http://www.4dos.info/4dvers/4dos750b130.exe

... or here:
ftp://jpsoft.com/4dos/files/

- Franc Zabkar


subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 00:43:30 GMT, Robert Redelmeier
<[email]> put finger to keyboard and composed:

IIRC TI calculators used a 9-level stack, albeit a hidden one. In fact
one could access the stack on a TI-59 using undocumented instructions.
So it's clear that TI machines *evaluated* the expressions in the same
way as HP calculators, it's just that TI calculators *accepted*
expressions as they were written. No mental gymnastics were required.
I certainly didn't have to learn a new way of doing things.
Furthermore, the often touted claim that HP calculators were much more
economical with keystrokes was a myth which I disproved many a time.

Not AFAIK, although this page suggests that it may go open source
someday:
 http://www.4dos.info/v4dos.htm

The actual v7.50 binaries are here:
http://www.4dos.info/4dvers/4dos750b130.exe

... or here:
ftp://jpsoft.com/4dos/files/

- Franc Zabkar


subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 00:43:30 +0000, Robert Redelmeier wrote:

If Gates did anything,  he made software a business,  and
a profitable one at that.  He did not focus first on making
anything accessible.  Remember,  Microsoft didn't even have
a decent GUI for any of its operating systems until late
1995.  It was the last of the non-Unix vendors to get decent
GUI technology.  Of course, Linux/Unix is still struggling
to catch up to what MS had in 1995 and everyone else had
even earlier.

As far as producing bloatware that has driven hardware ever
bigger and faster,  I don't really see that.  Where do you
think hardware would be now if it weren't for Microsoft?
Where should it be?  Should we still be running 386's with
1 MB or RAM?

I think hardware and software have evolved together.  As
hardware has improved,  software developers have been able
to change their paradigms by writing less efficient but
more powerful and more easily maintainable code.  That's
basically a good thing.  Software written without high
level abstractions is nasty stuff.

I think Microsoft has been pretty on target in terms of writing
software to the hardware that would be current at ship time.
A lot of other companies have been much less successful.  One
of the reasons OS/2 faltered is that IBM was releasing versions
that needed 16MB of RAM at a time when 2 or 4 MB was the norm.
Windows 3.1 was pretty happy with 2 or 4 MB or RAM,  and Windows
95 could get by with 8MB.  NeXT was even worse.  And the OpenDoc
component system was another case.  It needed 32 MB or more
at a time when 8 and 16 MB was the norm,  and OLE (or whatever
MS was calling it at the time) required far less.  (Well,  they
never quite got OpenDoc working right either).  Too bad.  It's
been 10 or 15 years now that Microsoft has been the only
significant company with working desktop component technology.

Some companies went the other direction,  spending too much
time writing low level code.  That might have been part of
the Amiga's problem.

As far as the current situation goes,  I think it's pretty
clear that current Linux distributions are by far the most
inefficient and resource hungry systems ever created.  The system
I'm on now (Linux Fedora Core 2) just doesn't run well with
less than 512 MB of RAM,  and it needs at least 768 if I
want to avoid excessive swapping when I have a lot of Firefox
tabs and other stuff going at once.  That's a far cry from
the 8 or 16 MB Win 95 used to need,  and it's 3 or 4 times
what my Win2000 and Win XP systems need.


author: willbill

subject: Re: New DOS shell for Windows coming

text:
Tony Hill wrote:

thank you (Franc&Tony) for that.  :)  i just moved to xp and
2k (from '98/2 PCs) and it "only" took me 3/xp tries.  :(
(3 with xp sp2, 1 with 2k sp4)

JHFC, the "simple" registry has become
NOT so simple with xp!  :(

i DID learn some new stuff about the registry
for *all* of the windows versions (98&up).  :)

i'm not holding my breath on Longhorn

yes, 98se has and contines
to be (!) a real option

too many focus on the BSOD
and not on the essence

i'll grant that a real issue
with current mobos is that they
are flakey with their software
support of an old OS like 98se
(AMD especially, Intel less so;
  at least in my limited experience)

i'm still using 98se as well as
recently 2k and xp (triple boot
on both pc's with 98DOS/98GUI/2k
on one, and 98DOS/98GUI/xp on
the other; via System Commander8.
i'll grant that how much longer i'll
use 98se in any serious way is a very
open question

fwiw, i like command line.  :)

i'm a mainframe guy (ibm '67) with
nix (Sun/cmd line and later gui)
experience since '89

interesting ref to 4DOS.  :)

bill


subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 02:42:41 -0400, Tony Hill
<[email]> put finger to keyboard and composed:

Give me a break. It took me ages to move on from Win95B. :-)

Some that come to mind include DOS, CPM, PRIMOS, KRONOS, RSX-11M,
CGOS. I found all of them relatively easy to learn. In fact Primos is
so intuitive that I was able to connect a Prime mini (an unfamiliar
machine) to a DG mini and perform file transfers merely by referring
to Prime's online help. And I did this within a couple of hours, using
only edit and copy commands, via an RS232 interface.

- Franc Zabkar


author: chrisv

subject: Re: New DOS shell for Windows coming

text:
Franc Zabkar wrote:

It's irrelvant how TI handled the calculator evaluated the
expressions.  It's the UI which is under discussion, here, and Robert
(and many others, including myself), prefer the RPN UI.

Are you implying the more "mental gymnastics" are required to use an
RPN calculator?  Because that would be false.

"Much more economical" sounds to me like a straw-man argument.  "At
least as, and often more, economical" is the truth, not a "myth", in
every case I've compared the two methods.

A superior (or even only preferred) tool is quite often worth the
investment in how to use it.  It's ludicrous to discount RPN
calculators because they may take a couple days getting used-to.

True, but many of us feel the RPN UI is vastly superior, especially
when used in conjunction with multi-line displays.


author: Nate Edel

subject: Re: New DOS shell for Windows coming

text:
A Jones <[email]> wrote:

You could try a more efficient distribution - or, if you use KDE on Fedora,
even try switching to Gnome... or a lightweight Window manager, for that
matter.

KDE on Gentoo seems to run OK on 384 and well on 512 (w/ a P4-1.7ghz machine).
Gnome on Gentoo seems to run OK on 256 and well on 384 (ditto).
blackbox on Gentoo seems to run OK on 128 and well on 256 (ditto).

blackbox on Gentoo (using kdrive as a X server rather than XOrg) with a 2.4
kernel runs OK (on a 96mb Pentium MMX 233 system, no less!)


subject: Re: New DOS shell for Windows coming

text:
A Jones <[email]> wrote:

Of course not.  But he wanted ever-more sales, and the
Invisible Hand forced him in the direction of accessibility.

An interesting speculation.  How many PCs would be sold at
$5000 today.  If attractiveness (eye candy) and mass marketting
hadn't driven the price down to one-tenth?  Perhaps only one
tenth.  That would then have justified far less development.

News to me.  I thought the main reason OS/2 faltered was
Billy got in a huff and left with the UI with him.  He
split the project, and took the market.

Maybe 4 without many apps open.  Not 2.

Very badly.  It was designed for 16, and ran much better in 32+.

I don't know what your problem is.  I run Slackware fine on
an old 486sx laptop with 8 MB (no GUI).  My main machine
has an excessive 512 MB, I run it swapless and I still get:

$ free
             total       used       free     shared    buffers     cached
Mem:        515376     480772      34604          0      28904     199236
-/+ buffers/cache:     252632     262744
Swap:            0          0          0

with Mozilla, Citrix & bash running under KDE.  It ran fine
swapless with 256 MB, and I'd expect it to run OK at 128 or
maybe 64 MB with swap.

-- Robert


author: Jason Gurtz

subject: Re: New DOS shell for Windows coming

text:
On 6/28/2005 17:59, willbill wrote:

This is an interesting statement.  What do you find so much more complex
about the WinXP registry when compared to the Win98 registry?

I find that they're nearly identical in their organization.  In fact,
significant swaths are exactly the same!

~Jason


subject: Re: New DOS shell for Windows coming

text:
On Tue, 28 Jun 2005 16:59:57 -0500, willbill <[email]>
wrote:

Hmm.. was that doing clean installs or upgrades?  I've never really
had any trouble doing clean-installs of WinXP (or any OS for that
matter), but upgrades are VERY hit and miss.

Anyone holding their breath for Longhorn will suffocate LONG before it
even hits store shelves, me thinks..

My experience with Win9x is that BSODs WERE the essence of it!
Actually, to be fair, I very rarely blue-screened Win9x, maybe only
once ever 10-20 crashes.  Unfortunately the damn thing would become so
horribly unstable, with applications crashing and locking up, that I
would have to reboot on a VERY regular basis.  I could rarely get a
day's worth of work done without being forced to reboot when using
Win9x, and it was not at all abnormal for me to have to reboot 4 or 5
times in a day.  And despite popular belief, this had NOTHING to do
with hardware or drivers, it happened on EVERY PC I used.

I wouldn't know.  I installed Win2K back in March of 2000 and have had
absolutely no desire to look back.  Maybe I'm just unlucky, but my
experience with Win9x was abysmal to say the least.  As soon as I
tried stretching the legs of the system the least little bit (ie
running three whole applications at the same time! :> ) the system
would start causing all kinds of troubles.  Applications would cease
getting processor cycles, the various sections of memory would get
filled up, explorer would crash, or any number of other possible
problems.  The only common denominator was that the OS was totally
incapable of recovering from such situations.

I like command lines for some things because, as mentioned above, they
can be very useful to accomplish some tasks.  GUIs can also be very
useful for accomplishing other tasks.  Different tools for different
jobs.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca


subject: Re: New DOS shell for Windows coming

text:
On Sun, 19 Jun 2005 09:04:02 +1000, Franc Zabkar
<[email]> wrote:

The fact that it took you a couple of hours and required using the
on-line help means that this interface was definitely not intuitive.
Easy to learn, maybe, but definitely not intuitive.

As someone more famous than myself once said:

"The only "intuitive" interface is the nipple. After that it's all
learned."

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca


subject: Re: New DOS shell for Windows coming

text:
On Wed, 22 Jun 2005 12:54:27 -0500, chrisv <[email]> put
finger to keyboard and composed:

One's *preference* for certain UIs is not at issue here. I'm merely
claiming the obvious, namely that algebraic calculators have an
intuitive UI, whereas RPN does not. Take a kid who has never heard of
RPN, give him a HP calculator without a manual, and then see how long
he takes to work out what to do.

FWIW, I'm not averse to using non-intuitive interfaces, especially
when they provide powerful features. An example is the teco character
editor which I have used extensively in the past.

As for my preference for certain UIs, these days I prefer the Windows
GUI for many tasks, and the DOS CLI for others. My current calculator
is a scientific, statistical, hex/bin/oct, algebraic one. It cost me
$5 about 15 years ago.

Algebraic calculators allow me to enter an expression exactly as it is
written. The machine decides the order of processing. OTOH, RPN
calculators require that I pre-process the expression and submit it in
a form which the machine can digest.

In my day HP's marketing was making such claims. It seemed like their
mantra. Personally I've never experienced a difference of more than
about 10%. In any case, TI calculators had twice the memory, twice the
features, and cost half as much, so the UI did not affect my
purchasing decision.

I would never discount them for that reason.

- Franc Zabkar


author: keith

subject: Re: New DOS shell for Windows coming

text:
On Wed, 22 Jun 2005 12:54:27 -0500, chrisv wrote:

So do I.  It took me about four hours to master RPN when I got my HP45,
and I never looked back.  Since, I have had a difficlut time with
arethmetic calculators.

Of course there are more "mental gymnastics".  Learning something new does
take a certain abount of mental capacity. ;-)

When the TIites saw how I did vector sums they shut up about the
superiority of TI's UI.

Even with a single line. I've never used a calculator with multiple lines
and I much prefer RPN.


subject: Re: New DOS shell for Windows coming

text:
One of design objectives of Windows 95 Gold was running in 4 MB. Of course,
it's not quire happy with it. But I've run it with 8 MB and it was not bad
at all. 8 MB Compaq-branded DIMM then costed 300.
When (around 1990?) I was told that I need 8 MB to run NT 3, I thought:
that's a big system!

I've seen Windows 2000 booting with 32 MB. Like watching paint dry.

"Robert Redelmeier" <[email]> wrote in message
news:w2Xse.2199$[email]...


subject: Re: New DOS shell for Windows coming

text:
On Sat, 18 Jun 2005 15:26:20 +0000, Robert Redelmeier wrote:

The story of OS/2 is a long one.  IBM and MS were working on it
together,  but MS was responsible for "advanced kernel development,"
so they were doing all the kernel stuff.  IBM was doing the GUI.

What happened is that MS continued working on the DOS/Windows line
more or less behind IBM's back.  Then,  when Windows 3.1 hit the scene,
it was an unexpected smashing commercial success.  The technology
was terrible,  much worse than OS/2.  The success was because it could run
in,  let's say,  4 MB RAM,  and it could run a lot of DOS software without
too much fuss.  Bill didn't get in a huff,  he just realized he was
holding all the cards.  He decided to take the Windows 3.1 market,  which
was in his hands, and shepherd it to Windows 95 and Windows NT,  and dump
IBM.

OS/2 had a very nice GUI.  It was a little drab in appearance,  but
functionally it was powerful and slick.  I would say the OS/2
GUI was more advanced 10 or 12 years ago than Gnome is today,
and OS/2 could run happily in 16 MB RAM rather than 512 or whatever
you think Gnome needs.

I generally have Gnome,  Firefox,  Thunderbird (or Evolution),  XEmacs,
some terminals, and maybe a newsreader open.  With 512MB,  I could squeak
by most of the time,  but too many Firefox tabs, or opening a pdf viewer,
or something, and bang,  I was swapping like crazy.  In my
experience,  Windows 2000 and XP take a lot less memory for a similar
setup.  In fact,  I can get by with Windows 2000 running on 128 MB of
RAM.  There's no way on earth I could ever get a RH system with Gnome
to run decently in that,  or even 168 MB RAM -- not even close.  Nor
will I ever waste the hours and hours of my life fiddling around trying
to get it to.  If you've had better success,  good.  Enjoy.


subject: Re: New DOS shell for Windows coming

text:
Jason Gurtz wrote:

you are right in that the registry itself
doesn't seem to have changed that much

my frustration is showing; i got carried away.
sorry

otoh, my 2nd failed try with XP (error 633 when
atempting to use my extermanl modem with the
dialer) was likely due to flakey s/w installation
screwing up the XP registry.  not sure if it was
trying a newer modem driver (US Robotics v.92)
or a failed installed of MSI video capture drivers
(for a VIVO board).  when i went to the MS
knowledgebase, i was amazed at all of the screwy
stuff that can mess up the registry (with 95 thru
XP and 2003)

then too, there's XP Pro, XP Home, and oem XP;
each with their own set of problems!

the other factor is how do you fix XP (NTFS
file system) if Windows won't start in safe mode?
i've easily been able to do that with 98SE by
booting into DOS (98SE DOS), and restoring the
registry from backups i do in the autoexec.bat
(today, yesterday, this week, last week; using a DOS
do once program).  then too, 98 keeps reg backups
for the last 5 days in the sysbckup directory

KB 307545 (How to recover from a corrupted registry
that prevents Windows XP from starting) may get
me some insight into the NTFS problem (i've not
read thru it yet)

one other note is that my current compressed 98SE
reg backups (rb00x.cab) are 1.5 MB.  in XP Pro a
backup of the "system files" gives a file (compressed?)
that is 443 MB in size!

that size difference suggests to me that XP
has more complexity; meaning it isn't all bloat

fwiw, in XP i now keep a written log of my installs,
registry backups, and backups of my boot drive
(to other hard drives (using 2003 DOS Ghost) that
i only plug in when i do boot drive backups)

i mean i hate it when a drive dies, or the system
goes belly up

what i do like about XP is that 3rd party
s/w companies focus on making their s/w
work with XP, whereas with 98SE that is
no longer true.  my MSI (NVidia) video
board is a good example: in 98SE i get
a lot less video performance than i do in XP
(same machine; triple boot via System Commander8:
  98SE-DOS, 98SE-gui, XP)

bill


subject: Re: New DOS shell for Windows coming

text:
Tony Hill wrote:

correct.  i loaded XP Pro, then ran the sp2 upgrade

i had/have 98SE on the machine but nothing
from 98 was taken into the XP install.
HD#1 (250GB) has c: d: and e: (all fat32);
f: is the dvd/cd, g: is the last partition
on HD#1 and is NTFS.  mobo is Tyan 2875
with an AMD Opty 142.  HD#2 is a raid1 array

  <smiling>

geez tony, you're never gonna touch any of my PCs.  :)

fwiw, i likely caused my 1st xp install failure
(it didn't fail during the install, only later
when i was loading 3rd party s/w).  i wasn't very far
into it, so it was an easy decision to start from
scratch again.  (i booted from my system commander cd
and ran their partition commander (a freebie included
on the cd) to delete the NTFS g: partition), and the
3 files on the c: root, and then installed xp again

the 2nd xp failure was painful coz i'd put a lot of
time into installing 3rd party software

after the 3rd install, the key things i've done
differently are: i only loaded the Intel Ethernet
drivers (and not the software; from the Tyan cd),
i didn't load any video board drivers (from
the MSI cd), i didn't load any modem drivers
(from the US Robotics cd)

i 1st loaded 2000 in early '01 and was similarly impressed.
now that it's got sp4 i'm even more impressed

bill