informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/messages/ALANWESTON/1994/DLPH12_14.txt

1352 lines
52 KiB
Plaintext
Raw Blame History

read new nonstop follow
90936 10-DEC 17:13 New Uploads
RE: PowerBasic for OS9/68000 ships! (Re: Msg 90935)
From: FHOGG To: ALL
I need some feedback from you guys.
Mike and I have been talking about a demo version of PowerBasic that
would be restricted in some way but would allow compiling. Our
discussion ranged from limiting the size of a source file to
eliminating some functions. After playing with PowerBasic to write
the date program I uploaded today I can see how having a demo version
would enhance interest and sales. The concern about having a demo
that was 100% but restricted the size of a source program is the fear
that some clever bloke would figure out how to 'fix' the demo so it
would work like the regular PowerBasic. This fear makes a restricted
demo (with some features totally removed) attractive. The question then
becomes which features can be removed that would allow a useful demo
while not stealing sales by being too useful?
If we decide to go the restricted route we could include a group of
demos in source form plus compiled versions of the demos that will
not compile on the restricted compiler.
What do you think.
Frank
-*-
90937 10-DEC 18:14 Programmers Den
RE: _gs_rdy() Question (Re: Msg 90878)
From: DBREEDING To: JEJONES
PAGAN said:
> > > From now on, just about everything I post will be compiled with UCC.
> > > I'm porting most of my G-Windows stuff for recompilation to OS9000.
> > Sounds like a good testimonial. Might just see if I can go with it.
> Well...for what it's worth, here's an additional piece of data.
> Remember gifshow for the MM/1? Long ago, when I first got my MM/1, with
> Mike Haaland's permission I did some work to speed it up. I did about
> all I could short of rewriting in assembly language.
> About a week ago, when I finally got around to installing Ultra C on
> my MM/1 (blush...I'm a fairly serious procrastinator), I recompiled
> gifshow with no particular knobs twisted to speed it up. The resulting
> program runs about 22% faster.
It would appear that UCC is definitely the way to go if one one wants to
get something besides 3.2. I had thought that the GNU package was the
way most were going, but from the posts here, if one is writing code for
distribution, there might be too many strings attached.
-- David Breeding --
CompuServe : 72330,2051
Delphi : DBREEDING
*** Sent via CoCo-InfoXpress V1.01 ***
^^^^ ^^^^^^^^^^
-*-
90939 10-DEC 20:04 Programmers Den
RE: _gs_rdy() Question (Re: Msg 90892)
From: DBREEDING To: EDELMAR
> > ... Are there any restrictions on distributing software compiled under
> > GCC, or 3.2, for that matter? ...
>
> There are no restrictions distributing and/or selling code compiled with
> and using the libraries provided with either 3.2 or Ultra-C. Indeed, MW
> gives permission to distribute, at no charge, 'csl', the replacement for
> 'cio' and the math module with the code if it is compiled with Ultra-C.
> To the best of my knowledge, this type of policy is universal regardless
> of what software house sells you their compiler.
Hmm.. It was my understanding that some of the compilers for the PC's did
have licensing requirements.. I was unclear on that, maybe for some that
required run-time packages? This understanding or misunderstanding was
what prompted me to write the letter referred to below.
> To the best of my
> knowledge, there are no restrictions on code distribution for code
> compiled with the GNU compiler if you _don't_ use their libraries.
Well, it still sounds complicated with them <G>
> > I contacted Tandy regarding the CoCo compiler, and they sent me a
> letter > stating that all that code could be considered PD in regard to
> distributing > compiled code.
>
> Can you clarify that? Are you saying programmers cannot charge for
> software if they use the CoCo C-Compiler and libraries? (PD would imply
> that.)
I guess I mis-phrased that statement. No, I just looked up the letter and
they DID use the word "pd", but said you could sell the code.. Here is
the direct quote from the letter.
"Please be assured that both the library files and the "root.a"
module in the Tandy C COMPILER are considered to be public domain
and as such can be included in code to be distributed for sale or
release."
Maybe they misused the term "pd", but at any rate, from the letter, you're
free to do with the compiled code whatever you will.
-- David Breeding --
CompuServe : 72330,2051
Delphi : DBREEDING
*** Sent via CoCo-InfoXpress V1.01 ***
^^^^ ^^^^^^^^^^
-*-
End of Thread.
-*-
90938 10-DEC 20:02 General Information
RE: 2nd Hard Drive (Re: Msg 90931)
From: DBREEDING To: CHARLESAM
> and I believe my Ids are straightened out but there is also a jumper to
> the left of the control cable and I'm not sure about the placement of
> that. Also, I substituted my new drive for the existing drive as H0, but
> os9 refuses to recognize it. I get Unit not ready ERROR. I believe now
> that there is some problem with the drive. I'll keep working on it.
One note: Have you tried removing the extra jumper? This might be the
PARITY jumper. I went through a hair-pulling fit when installing my ST-1096N
on my system. Seagate DID have a BBS where you could d/l technical specs
for any of their drives. It was some time ago, but here is the # as it
was then. You might give it a shot.. The file for my drive contained
a schematic for the pinouts in IBM graphics. You can either "type" it
on a PC, or list it to a printer having IBM emulation.
SEAGATE TECHNOLOGY, INC.
Technical Support Bulletin Board
408/438-8771 [300-9600 HST, MNP 3/5, N-8-1]
(C)opyright 1990
-- David Breeding --
CompuServe : 72330,2051
Delphi : DBREEDING
*** Sent via CoCo-InfoXpress V1.01 ***
^^^^ ^^^^^^^^^^
-*-
90942 10-DEC 23:37 General Information
RE: 2nd Hard Drive (Re: Msg 90931)
From: WA2EGP To: CHARLESAM
The id must be different in the software and the hardware. If you have one
drive and you set the software for an ID of 1, the jumpers on the drive better
be set for 1 or the drive will think it is something else and will not
recognize stuff sent to it. Almost as bad as having two drives trying to read
the same stuff (grin).
-*-
90945 11-DEC 12:45 General Information
RE: 2nd Hard Drive (Re: Msg 90938)
From: CHARLESAM To: DBREEDING
Thanx Dave, I'll check it out(Seagate).
-*-
90946 11-DEC 12:48 General Information
RE: 2nd Hard Drive (Re: Msg 90942)
From: CHARLESAM To: WA2EGP
As I stated, I made the new(2nd) drive H0 just to see if it would be
recognized,that is I removed my existing drive and substituded the new drive.
Alas, Os9
came back with "DRIVE NOT READY". Go figure. Thanx Charlie
-*-
90955 12-DEC 00:28 General Information
RE: 2nd Hard Drive (Re: Msg 90945)
From: AJMLFCO To: CHARLESAM (NR)
Here is a little lesson I learned the hard way concerning
Seagate 3.5" N-series hard drives:
The universal installation handbook incorrectly labels the
SCSI jumper positions in figure 4.
It should be P NC 1 2 4
Rather than P NC 4 2 1
as shown in the figure. You probably should have no jumper
in the P (parity position). Most likely your host or host
adapter card is SCSI ID=0. Your first drive could be set to
SCSI ID=1. You can set the second drive to SCSI ID=2. Be
sure that your device descriptor is set correctly. I haven't
had time to follow this entire thread, so I hope I am addressing
at least part of your question. I have used the scsi47.ar drivers
on my CoCo with two Seagate 157N's. It's been a few years since
I have played with them, but I recall a little
"strangeness" in the addressing in the device descriptors. If you
are using these drivers on a CoCo, you may be able to get some help
from Ken Scales, the author, or I could fire up the old CoCo and
check my settings. I have also run two SCSI drives on the Kix\30.
That system was provided with the necessary descriptors so I
did not need to patch one to make the second on like I did on
the CoCo. One other thing I have learned is that the SCSI bus
really likes to have the terminators installed on the drive
furtherst from the host. Some resistor packs have a pin #1
dot on them. These dots line up with corresponding dots screened
onto the printed circuit board. I am not sure if resistor packs
installed backwards really "terminate". This could lead to erratic
performance.
hope this helps,
Allen Morgan
-*-
90956 12-DEC 00:32 General Information
RE: 2nd Hard Drive (Re: Msg 90946)
From: WA2EGP To: CHARLESAM (NR)
OK. I assume you had the jumper set right (or none at all). Was it formatted?
Or should I ask, did a previous owner low level format it? I have picked up
SCSI drives who had that done and if LSN 0 gets formatted, all the info about
the drive is gone. The hardware looks there to determine how large it is.
If it ain't there, there is nothing you can do except get it "fixed". They
put that info back on LSN 0. Outside of putting the cable on upside-down
(which is darn near impossible), I can't think of anything else. I hope you
get your problem solved. Let me know how it works out.
-*-
End of Thread.
-*-
90940 10-DEC 22:24 System Modules (6809)
RE: CC3IO Patches (Re: Msg 90922)
From: MIKE_GUZZI To: GREGL
Good messages like that I always save! <grin>
-*-
90941 10-DEC 22:29 Applications (6809)
Need program
From: MIKE_GUZZI To: ALL
Who Sells the basic09 decompiler? or is that company out of business?
I have a need for it and need to get a copy of it.
-*-
90943 10-DEC 23:53 General Information
RE: Install program (Re: Msg 90933)
From: WA2EGP To: TEDJAEGER
Well, a couple of thoughts I had....
Will it install programs to their own directories and use "standard"
directories like SYS? I tend to like to put a cmds subdirectory in a directory
so all my word processor stuff including utilies in under WORDPROCESSOR (as
an example).
I like the idea of source drive/target drive. I can your point in assuming
that all the parts of a program are in the same directory on the installation
disk. Some one might put SYS stuff in a SYS directory on it. Almost sounds
like your working on what I would call a directed version of dsave. It sort of
dsaves but sends it where you want it to go.
Best of luck on the project. It's something that I think is needed.
-*-
90960 12-DEC 19:35 General Information
RE: Install program (Re: Msg 90933)
From: NIMITZ To: TEDJAEGER
Ted, I suggest you have the program query the user for his desired installation
directory, and then use information obtained from the programmer to
interactively generate a script file. If you use dsave after creating the
users directory, you should have
no problem. Your program would simply create the initial directory, and then
execute dsave -e from the appropriate drive and directory.
-*-
90966 13-DEC 21:21 General Information
RE: Install program (Re: Msg 90934)
From: TEDJAEGER To: JOHNREED (NR)
> Have you considered using the `oddjob' program? You can do things
> that the fancy UNIX shells do, and everyone with an MM/1 should have
> it..
Absolutely forgot about it! I'll take a look. Thanks for reminding me..
> Warning. I have found (on my MM1/a) that files copied to a named
> pipe, then back to a disk file have a few characters tacked on to them
> at the end - mostly on larger (over 15k ) files.
Yup, Joel mentioned that in his article. Another headache with the
pipe method.
Bests
---TedJaeger
-*-
90967 13-DEC 21:21 General Information
RE: Install program (Re: Msg 90943)
From: TEDJAEGER To: WA2EGP
> Will it install programs to their own directories and use "standard"
> directories like SYS? I tend to like to put a cmds subdirectory in a
> directory
> so all my word processor stuff including utilies in under WORDPROCESSOR
> (as an example).
Yes, but at the discretion of the script that the programmer has to
provide. My program is a graphical front end to the script which
collects from the user the source and target drives as well as the
name of the script it is to run. So if the script includes:
makdir /dd/WORDPROCESSOR
copy neatprogram /dd/wordprocessor/neatprogram
it will install to WORDPROCESSOR directory. Here you see the reason
for my ambivalence: the programer still has the work of writing the
install script and the user can still get into the script and
change it to muck.
> that all the parts of a program are in the same directory on the
> installation disk. Some one might put SYS stuff in a SYS directory on it.
Yes, exactly. I invision DeskTamer being distributed that way.
> Almost sounds like your working on what I would call a directed version
> of dsave. It sort of
Thanks, for that insight! I may be able to pass the variables for source
and target drives and program name to dsave and have the install program
run the dsave procedure file. That may be the best way to do the whole
thing. It would save the programmer having to write an installation
script as dsave would do that for them. Interesting.......
Bests
---TedJaeger
-*-
90970 14-DEC 01:18 General Information
RE: Install program (Re: Msg 90967)
From: WA2EGP To: TEDJAEGER (NR)
I hope it works out. Would be nice to have some type of install program.
BTW, would it have some sort of default values in case the user is a newbie
and really doesn't know where to put things (like we have standards on that
type of thing - like UNIX). Obviously, there would have to be some kind of
standard "place" to put things beyond SYS and command stuff. I have gotten
programs which dumped a whole mess of stuff in root...very ugly. Anyway,
this would be a plus for those of us out there who have trouble changing
directories. I guess that is the hardest thing to do....write something that
a person new to the OS can use without frustration and a more experienced
user can "play" with it a bit to get what they want.
-*-
End of Thread.
-*-
90944 11-DEC 11:25 General Information
palm22.lzh?
From: JEJONES To: ALL
Has anyone had any luck downloading palm via the gopher section of this SIG?
It seems to think that "palm22.lzh" on chestnut is a subdirectory rather than
a file.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
90947 11-DEC 13:35 General Information
RE: palm22.lzh? (Re: Msg 90944)
From: MITHELEN To: JEJONES
Why not just download it from the Telcom Database here at Delphi?
--
Paul
-*-
90949 11-DEC 18:26 General Information
RE: palm22.lzh? (Re: Msg 90947)
From: JEJONES To: MITHELEN
> Why not just download it from the Telcom Database here at Delphi?
I went looking for it one evening; guess I didn't use the right keywords
to search. In any case, the menu entry for palm22.lzh under
chestnut/osk/telecom really should be corrected.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
90951 11-DEC 21:28 General Information
RE: palm22.lzh? (Re: Msg 90949)
From: MRGOOD To: JEJONES
James,
Palm 2.2 is in the Coco database, not OSK.
Hugo
-*-
End of Thread.
-*-
90948 11-DEC 16:27 Programmers Den
powerbasic vs. Ultra C
From: PAGAN To: ALL
Out of curiosity I downloaded the benchmark programs that Frank Hogg offered
for his new PowerBasic compiler. I converted these programs to "C" and
compiled with Ultra C. I used no optimization (-o=0) and used the "csl"
trap library (-i). In each case, I tried to faithfully duplicate the
function of Frank's original code rather than use any slick tricks to speed
things up. Where C doesn't have an equivalent function, I used the nearest
I could think of. For example in "bench6" below, Basic has the "str$"
function for which I substututed the C "sprintf()".
The codes sizes for UCC listed below do not include the 47K overhead of the
"csl" trap library and the execution times should be considered for
information only; The test programs are do nothing loops that, in my
experience, don't reflect the real world performance of a complex
application. Also, benchmarks don't account for development and maintenance
time nor for "intangibles" like personal preference.
Test were done on a Delmar System IV with G-windows and screen saver
deactivated by putting the mouse cursor in the lower right corner.
Execution Time Code Size
(in seconds) (in bytes)
PB UCC PB UCC
-- --- ---- ----
bench2 10 6 1362 1766
bench2m 8 -- 1350 ----
bench3 14 8 1380 1758
bench4 24 3 1462 1744
bench5 20 6 1404 1774
bench6 34 95 1432 1796
bench7 40 18 1534 1842
bench8 15 8 1384 1780
bench9 11 4 1346 1760
bench10 75 5 1352 1768
bench11 24 4 1446 1762
bench12 12 6 1370 1772
I am uploading the C source and makefile for the comparisons to the
databases for anyone who is interested.
Stephen (PAGAN)
-*-
90950 11-DEC 18:26 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90948)
From: JEJONES To: PAGAN
> Out of curiosity I downloaded the benchmark programs that Frank Hogg
> offered for his new PowerBasic compiler. I converted these programs to
> "C" and compiled with Ultra C. I used no optimization (-o=0) and used the
> "csl" trap library (-i).
<grin> If you had used the default options, the intermediate code optimizer
would probably have nearly eliminated the code on most of those programs.
These days one has to be pretty determined to keep optimizers from noticing
code that doesn't really make any difference to the result and deleting it,
or even just transforming it into something that is completely different
from what you *think* you're testing.
> The test programs are do nothing loops that, in my
> experience, don't reflect the real world performance of a complex
> application.
That's true of many benchmarks. IMHO everyone should read the chapter on
benchmarks in Hennessy and Patterson's book on computer architecture.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
90952 11-DEC 21:39 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90950)
From: PAGAN To: JEJONES
><grin> If you had used the default options, the intermediate code
>optimizer would probably have nearly eliminated the code on most of
>those programs. These days one has to be pretty determined to keep
>optimizers from noticing code that doesn't really make any
>difference to the result and deleting it, or even just transforming
>it into something that is completely different from what you *think*
>you're testing.
Don't I know it. At first look I could see several places UCC would
take liberties if given the opportunity. I just rewrote the code as
faithfully as I could but I know that the values are the more the
result of the difference in compilers rather than any difference in
the languages.
<I figure you already know this stuff but not everybody here does.>
For example, bench10.b assigns a constant to a variable in a loop:
dim a:byte
dim i:integer
Start
shell "date -j"
for i=1 to 10000000
a=100
next i
shell "date -j"
In C this becomes:
#include <stdio.h>
#include <time.h>
main()
{
char a;
int i;
printf("%d\n",time(0));
for(i=0;i<1000000;i++)
a=100;
printf("%d\n",time(0));
}
Though they may seem equivalent, the complier/optimizer can play
some games with this. Compiled with -o=0 (no optimization) the loop
in assembler looks like:
bra _$l4be
_$l4bb
move.b #0x64,-6(%a5) assign value
move.l %d0,-8(%a5) put into storage
addq.l #1,-4(%a5) increment counter
_$l4be
cmpi.l #0xf4240,-4(%a5) check it
blt _$l4bb branch back if not done
But, compiled with -o=7 the loop looks like:
_$l4ba
addq.l #1,%d0
cmp.l #0xf4240,%d0
blt _$l4ba
Are you wondering where the assignment went to? Well, the UCC
compliler is "smart" enough to figure out that the variable is not
used anywhere in the program so, given the chance, it ignores it!
Some of the other benchmarks Frank uploaded would suffer similar
changes if compiled with UCC. In bench4, there s a simple integer
calculation repeated each time thru the loop. UCC will recognize
that, if forced to use it, the value only needs to be calculated
once and never changes. So the compiler will precalculate it and
store it with the program constants.
Stephen (PAGAN)
-*-
90961 12-DEC 23:18 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90948)
From: FHOGG To: PAGAN
Stephen (PAGAN),
While you did state that you were curious how CDL Basic
(formally PowerBasic) compared to UUC you are missing the
point and perhaps moving this discussion in the wrong
direction. I admit I was surprised at first that a C guy
would bother about Basic but then I realized that it was
indeed just curiosity on your part. I welcome the comparison
you have made especially the syntax comparison that showed
more clearly than I, how much easier Basic is to read than
C.
Perhaps I should state our goals or rather Mike Smiths goals
for CBL Basic. First some brief history. MW Basic for OSK
came out about 10 years ago and has not changed much in the
past decade. It appears that MW is commited to C while the
rest of the world goes in different directions. I recently
talked to a former OSK user whose company has switched to
Visual Basic because it is easier to work with. I think that
a good argument could be made that MW missed the boat in not
continuing the development of their Basic. Proof of my point
is the lack of applications for OSK. We have been limited to
C and assembler for 10 years of development. That has
limited us to developers who were willing or wanted to work
with the tools that were available. I am not about to get
into the relative merits of any language. I am just stating
the obvious. If C and assembler were good enough then we
would have seen more applications for OSK. They don't exist,
point proven.
For whatever their reasons, many developers do not want to
work with C. Many would rather work with Basic and because
MW Basic is slow it has been a yoke around the neck of OSK
development. Now that has changed. CDL Basic is lots faster
than MW Basic because it is a compiler. The benchmarks were
carefully crafted to do things exactly as MW Basic does them
so users could see for themselves the speed advantage
compared to MW Basic. The goal was simply to impress upon MW
Basic users the speed advantage of CDL Basic. We did that
with the expectation that the availability of a fast Basic
compiler would attract developers for OSK who would not do
so with C. After all if speed alone was the criteria then we
would all use assembler, which is faster than any compiler.
Who wants to do serious applications in that?
I hope that you do not take this as a criticism of you, it
is not. As a matter of fact I regularly enjoy your Blackjack
game. I really want to address issues that this thread might
wander into and try to keep everyone on track about CBL
Basic. Lets not throw the baby out with the bathwater by
bashing CBL Basic solely based on it being somewhat slower
than UUC. Microware has been developing their many versions
of C for 15 years or so with a crew of programmers. Mike
started CBL Basic a year ago and we are at version 1. Newer
versions developed over the coming years will have more
features, be faster and most importantly of all will support
a continuing pool of developers creating more applications
for OSK. Applications that would not have been developed in
C.
Speaking strictly for myself I am very very happy with CBL
Basic. Programs I've written in it are by far much faster
than any program I've ever written in C. (none) I feel that
I already know how to program in it without having to take a
college course or study any of the five books I bought over
the years on C. Don't get me wrong. I would like to 'know'
C. I just don't want to go to the work to 'learn' it. In the
few weeks I have had CDL Basic I have written a handful of
neat little utilities just for the fun of it. Let me restate
that. Just for the FUN of it. I'm having FUN programming
again. I have plans to do some serious applications for G-
Windows using CDL Basic. Things I would not consider doing
under any circumstances with C. You are probably thinking
that if I just took the time to learn C I would like it etc
etc. Why bother? I LIKE Basic, I don't like C. CDL Basic is
fast enough to do serious applications with and it's fun to
work with.
Again I don't mean to jump on you for this and I'm sorry to
be so long winded but let me just finish with this... In my
mind comparing C to Basic is like comparing a helicopter to
a airliner. It makes no sense so why do it? They are tools
that serve different masters.
CDL Basic is a tool that will encourage development of
software for OSK and that is something we all want.
Thanks again for Blackjack. BTW I would love solitaire if
you feel so inclined.
Frank
-*-
90963 13-DEC 02:37 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90961)
From: PAGAN To: FHOGG
Frank,
I fully support your effort to bring a good compiled Basic to OSK. I wasn't
trying to say that UCC is better or worse than CBL Basic and I won't get
argument down in an argument over which is "best". I explained in a later
post that the differences in execution time are the results of the
optimizations available with UCC.
I can agree that, for certain things, Basic would be preferable to C. Not,
IMO, most things but certain things. I also agree that MW may have flubbed
it by not continuing to develop Basic09. It had a lot of capability and,
and you've pointed out, is easier to learn than C. I do not agree that
Basic is nearly as powerful a language as C but for many applications this
would not be a problem. Since OSK applications are still at the single
developer or small team stage the choice of a language is influenced more by
familiarity than anything else.
Regarding the syntax differences, I usually find C to be easier to read than
Basic. Since I'm intimately familiar with both languages I attribute this
to personal preference.
Now for some questions. Since I work in G-Wndows a lot, I've had to develop
techniques for handling it's event driven environment. So to see if it
could work well for me does CBL Basic:
1. support pointers to functions?
2. allow pointers to be passed between modules?
3. support dynamic memory allocation/reallocation?
4. support pointers to structures?
5. Will it be compatible with G-View created windows?
Re solitare: It's on the list of things to do. I've just completed
upgrading and porting Blackjack to Ultra-C (now testing for OS9000) and
have a new game called "CyberWar" which should be ready soon for both OSK
and OS9000 with G-Windows.
Stephen (PAGAN)
-*-
90964 13-DEC 03:10 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90961)
From: JOELHEGBERG To: FHOGG
Frank,
I felt the need to reply to your recent message. Let me say I'm always
pleased to see new, powerful software development tools (such as CDL
Basic) arrive for OS-9. I wish you and Mike the best with the project.
> First some brief history. MW Basic for OSK
> came out about 10 years ago and has not changed much in the
> past decade. It appears that MW is commited to C while the
> rest of the world goes in different directions.
I do not understand how you can say this. If the world is moving in
another direction other than C it may be to C++. While I agree, there
has been a recent resurgence of BASIC amateur programmers with the
arrival of Visual Basic, VB is used mostly by novice programmers whose
main career usually isn't programming. From my understanding, VB is
used in corporations and small businesses to handle simple programming
needs. No large commercial applications are written in VB, to my
knowledge.
> I think that
> a good argument could be made that MW missed the boat in not
> continuing the development of their Basic. Proof of my point
> is the lack of applications for OSK. We have been limited to
> C and assembler for 10 years of development. That has
> limited us to developers who were willing or wanted to work
> with the tools that were available. I am not about to get
> into the relative merits of any language. I am just stating
> the obvious. If C and assembler were good enough then we
> would have seen more applications for OSK. They don't exist,
> point proven.
That is a tremendous leap to a highly speculative conclusion. I very
much doubt the lack of a good Basic compiler has thwarted OS-9's
application base. For a long time now, many people in OS-9 have
declared reasons why we have a lack of applications. Some have blamed
it on Microware, some have blamed it on the lack of development tools,
some have blamed it on a lack of skilled programmers, some have blamed
it on the lack of support for our programmers, some on lack of
marketing, some on the fact that OS-9's major base is industrial, etc.
You cannot flippantly state 'point proven' just because applications
don't exist. That condition makes everyone else's 'point proven' as
well, so which point really has been proven? I would imagine it's a
combination of many factors.
> We did that
> with the expectation that the availability of a fast Basic
> compiler would attract developers for OSK who would not do
> so with C.
I'm hopeful you are right. Again, I'm always excited to see more
development opportunities become available for OS-9.
> Don't get me wrong. I would like to 'know'
> C. I just don't want to go to the work to 'learn' it.
I would suggest to you that the people who "don't want to go to the work
to learn" C are not the programmers who will be writing the types of
application programs needed to bring OS-9 out of the shadows.
> Again I don't mean to jump on you for this and I'm sorry to
> be so long winded but let me just finish with this... In my
> mind comparing C to Basic is like comparing a helicopter to
> a airliner. It makes no sense so why do it?
I'm amused by your comparison, Frank! It occurs to me that a helicopter
can go many places that an airliner could not possibly go. But you are
correct... you really cannot compare the two.
> CDL Basic is a tool that will encourage development of
> software for OSK and that is something we all want.
I whole-heartedly agree, and please extend my congratulations to Mike
for his work! I certainly hope it becomes a best-seller.
-- Joel Mathew Hegberg
PS: I can't help myself... my curiosity gets the better of me. May I
ask what language Mike wrote the CDL Basic compiler in? ;)
-*-
90968 14-DEC 00:43 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90963)
From: FHOGG To: PAGAN
Steven
I do not disagree nor have many arguments with most of your comments
except...
> I do not agree that Basic is nearly as powerful a language as C but
> for many applications this would not be a problem.
CDL Basic is powerful enough to write a Basic compiler. In this case
CDL Basic itself is written in CDL Basic! Does that count as
'powerful enough'?
> Regarding the syntax differences, I usually find C to be easier to
> read than Basic. Since I'm intimately familiar with both languages
> I attribute this to personal preference.
I would also attribute that to your knowledge of C. Only if you knew C
could you have a preference about it. And in order to know it you had
to learn it.
> Now for some questions. Since I work in G-Wndows a lot, I've had to
> develop techniques for handling it's event driven environment. So to
> see if it could work well for me does CDL Basic:
> 1. support pointers to functions?
This is not fully defined as yet but it probably will. I should have
the details by this weekend.
> 2. allow pointers to be passed between modules?
Yes
> 3. support dynamic memory allocation/reallocation?
YES
> 4. support pointers to structures?
YES and to structure sub-elements as well
> 5. Will it be compatible with G-View created windows?
I am not aware of any differences from standard G-Windows windows.
We are perhaps making a wild assumption here but we 'assumed' that
having the C library interface which allows calling all of the
G-Windows C library calls would also allow the compatibility you
ask about. Is this a valid assumption? Are G-View created windows
different that standard G-Windows windows?
> have a new game called "CyberWar" which should be ready soon for both
> OSK and OS9000 with G-Windows.
GREAT! I'm looking forward to it.
Thanks for your help.
Frank
-*-
90969 14-DEC 00:45 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90964)
From: FHOGG To: JOELHEGBERG
Joel
>Visual Basic, VB is used mostly by novice programmers whose
>main career usually isn't programming. From my understanding, VB is
>used in corporations and small businesses to handle simple programming
>needs.
The fellow I talked to is the chief engineer at a company that makes
large commercial washing machines for hospitals etc. The computer
controls a whole bunch of robot carriers that shuttle the linen from
washer to dryer etc. Very impressive operation. Programming in this
case is probably not full time but my impression of his job was to
integrate all this odd hardware and write support software
modifications to their main overall application. Maintaining this for
all their different customers is probably their main reason for going
to something simpler like Visual Basic. When they were still using
OSK they were looking for software help with C. MW lost them as a
customer because of the difficulty they had working with MW C. This
is not the first time I've heard this sort of thing. It was knowledge
on my part of people like this that made me encourage Mike with CDL
Basic.
>No large commercial applications are written in VB, to my
>knowledge.
You could be right. But CDL Basic is intended to be able to write
large applications easier than in C.
>I would suggest to you that the people who "don't want to go to the
>work to learn" C are not the programmers who will be writing the types
>of application programs needed to bring OS-9 out of the shadows.
Ah but this infers that C is the only solution. An old axiom goes
something like... "It is a poor craftsman who blames his tools" means
that it is the craftsman not the tools that will create the
applications. If said craftsman chooses CDL Basic then that choice
should not condemn the job that is done. Hey computers are supposed
to make life easier, shouldn't computer languages do this too?
>PS: I can't help myself... my curiosity gets the better of me. May I
>ask what language Mike wrote the CDL Basic compiler in? ;)
Here is where I get to prove the point of my last paragraph. CDL Basic
is written in CDL Basic! A crude bootstrap version was first written in
MW Basic. Then CDL Basic was used to enhance itself. It is written
entirely in Basic BTW. Although it has assembler support built in it
was not used in the main coding of CDL Basic. The reason is that we are
looking toward doing a OS9000 version. But back to the point. CDL Basic
is powerful enough to write itself. The only other two languages I am
aware of that do this are C and assembler. There is no reason it cannot
be as powerful or even more powerful than C.
Thanks for the response.
Frank
-*-
90971 14-DEC 02:17 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90969)
From: JOELHEGBERG To: FHOGG (NR)
Frank,
> >I would suggest to you that the people who "don't want to go to the
> >work to learn" C are not the programmers who will be writing the types
> >of application programs needed to bring OS-9 out of the shadows.
>
> Ah but this infers that C is the only solution. An old axiom goes
> something like... "It is a poor craftsman who blames his tools" means
> that it is the craftsman not the tools that will create the
> applications. If said craftsman chooses CDL Basic then that choice
> should not condemn the job that is done. Hey computers are supposed
> to make life easier, shouldn't computer languages do this too?
Oops, maybe that didn't come out right. I meant to imply that a true
programmer in the ever-evolving field of computer science can never
become completely satisfied... s/he must always continue to expand
his/her horizons and learn new ideas, techniques, etc. If a
professional programmer says, "I don't want to go to the work to
learn..." [anything] then I don't believe that programmer will be the
one to write any breakthrough software. You are right, though...
choices in computer languages are very important which is why I'm so
excited about the availability of CDL Basic for OS-9.
> >PS: I can't help myself... my curiosity gets the better of me. May I
> >ask what language Mike wrote the CDL Basic compiler in? ;)
>
> Here is where I get to prove the point of my last paragraph. CDL Basic
> is written in CDL Basic!
Very impressive, Frank! I'm glad I asked... very interesting to know.
-- Joel Mathew Hegberg.
-*-
90973 14-DEC 04:29 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90968)
From: PAGAN To: FHOGG (NR)
Frank,
>CDL Basic is powerful enough to write a Basic compiler. In this case
>CDL Basic itself is written in CDL Basic! Does that count as
>'powerful enough'?
Beats me, I have no idea what's involved in writing a compiler.
They're just magic boxes to me :-)
>> 1. support pointers to functions?
>This is not fully defined as yet but it probably will. I should have
>the details by this weekend.
Pointers to functions like: void (*DoThis)() which can be changed on
the fly depending on user generated events may not be absolutely
positively necessary but make the event handling in a complex
program _much_ easier to track and debug.
>> 5. Will it be compatible with G-View created windows?
>I am not aware of any differences from standard G-Windows windows.
>We are perhaps making a wild assumption here but we 'assumed' that
>having the C library interface which allows calling all of the
>G-Windows C library calls would also allow the compatibility you ask
>about. Is this a valid assumption? Are G-View created windows
>different that standard G-Windows windows?
Gview handles windows via the same calls as a "regular" program but
making the calls is not what I'm concerned about. I'm concerned
about the event reporting and handling.
G-Windows provides three different ways to report a window or mosue
event to a program. First is to define a signal to be sent when a
particular event occurs. I'm assuming that CDL Basic can handle
asynchronous events so this shouldn't be a problem. Second is to
define an esacpe sequence - like a printf() format string - that
wfm will put in stdin so the program can read it via the normal
_os_readln() call.
The most flexible method and the only one avilable from Gview is to
define a callback function to be put in the event packet which is
created whenever a defined event occurs. GView takes care of
setting up these up for you with the Window_Set() function. The
call might look something like this:
Window_Set(path,0,
W_Event,0,MEV_LB_up,0,0,MouseClick,0,
W_Event,WEV_BlockRedraw,0,0,0,RedrawScreen,0,
W_EventSignal,WEV_SIG,
0);
"MouseClick" is the name of a function that wfm will store in the
event packet when ever the left mouse button is released inside the
window. Similarly, "RedrawScreen" is a function that will be stored
whenever a part of the screen is exposed. Will CDL recognize that
MouseClick and RedrawScreen are function names and inform the linker
appropiately? If not, Gview and CDL Basic will not work together.
Gadgets also require that callback functions be defined and the
names are passed when the gadget is initialized. For example (from
my gadget library):
GADGET_ID *SetupButton(path,text,fontid,press_func,down_func,up_func)
int path; /* path to window */
char *text; /* text to draw in button */
int fontid; /* font to draw text in */
int (*press_func)(); /* callback functions - */
int (*down_func)(); /* set to 0 if not required */
int (*up_func)();
Here again, GView takes care of this automagically but the process
is the same.
I hope you can understand just how important function pointers are
in G-Windows and why I'm conerned with them. Frankly, without them,
I would consider CDL as useless for anything but the most trivial
G-Windows programs.
Stephen (PAGAN)
-*-
90974 14-DEC 07:28 Programmers Den
RE: powerbasic vs. Ultra C (Re: Msg 90968)
From: JEJONES To: FHOGG (NR)
> > I do not agree that Basic is nearly as powerful a language as C but
> > for many applications this would not be a problem.
>
> CDL Basic is powerful enough to write a Basic compiler. In this case
> CDL Basic itself is written in CDL Basic! Does that count as
> 'powerful enough'?
Strictly speaking, if you can write a Turing machine simulator in it,
you can do anything, so in that sense practically every programming
language is "equally powerful" (some spreadsheets might even manage).
OTOH, that's sort of like the Popeil ads--"you could even cut a tin
can with it, but you wouldn't want to." The real question is how easy
is it to do what you want. (Does CDL BASIC support recursion?)
> > Regarding the syntax differences, I usually find C to be easier to
> > read than Basic. Since I'm intimately familiar with both languages
> > I attribute this to personal preference.
>
> I would also attribute that to your knowledge of C. Only if you knew C
> could you have a preference about it. And in order to know it you had
> to learn it.
I'm not sure what the point of that is--your preference is probably due
to your knowledge of BASIC. What difference does that make?
As far as ease of learning--if natural languages are any indication, I
doubt that one can classify languages as "easy" or "hard," save maybe
relative to what you learned first. Surviving songs of Roman soldiers
would get an A from a high school Latin teacher--all the cases, number,
tenses, etc. are right. Why do we have to beat our heads against the
wall to learn Latin?
The advantages of Color BASIC and other BASICs of the sort that Kemeny
and Kurtz, BASIC's inventors, called "gutter BASIC," are that with the
exception of FOR/NEXT, it's purely line-oriented, and you can get by without
any declarations for the most part. That makes it easy to get started...
but also makes life far more obnoxious when it comes time to write a
nontrivial program, or to maintain or modify a program.
I'm no worshipper of C; I agree with many of the criticisms of it that
have been made over the years. But I know people who have yet to, and
probably never will, make the transition from Color BASIC to BASIC09,
despite BASIC09's advantages. It's not clear to me that learning the
extensions of CDL BASIC are that much easier than learning C.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
End of Thread.
-*-
90953 11-DEC 23:33 OSK Applications
CDL Basic for OS9/68000
From: FHOGG To: ALL
PowerBasic for OS9/68000 has a new name.
CDL Basic for OS9/68000
It was brought to our attention that the name PowerBasic was in use in the PC
world and this confused many people. In order to avoid confusion (and avoid
spending far too much time with lawyers) we decided to change the name. Hope
this doesn't confuse too
many people.
Frank
PS CDL Basic comes from 'Computer Design Labs', the creators of the compiler.
-*-
90954 11-DEC 23:34 OSK Applications
PowerBasic files in da new
From: FHOGG To: MISAL (NR)
Please delete all the files in da new that refer to PowerBasic. I will upload
new files with the new name CDL Basic.
Sorry for the trouble.
Thanks
Frank
-*-
90957 12-DEC 02:18 Games & Graphics
CD-i titles...
From: MITHELEN To: ALL
Welp, pick up two new CD-i titles today. Mutant Rampage: Bodyslam, and
Dragons lair II: Timewarp. Both are excellent.
Mutant Rampage is a fast paced, knock 'em, sock 'em, beat the heck outa
the Mutant bad guys game... It has 4 levels, the first 3 have 3 different
scenes (citys), the last just one (New York, the roughest/tuffest place in the
world). This is a real action game! and quite challengeing. The graphics are
supurb, along with the background music and sound effects. This is by far
my favorate game so far, really gets the heart pumping!
Dragons Lair II, is, of course the sequeal to the famous Dragons Lair
game. I haven't played it in depth yet, but it definately starts out much
harder then the original. Once again the graphics/sound and action are great.
I noticed several more new titles in the local Best Buy(s) this weekend. They
must have finally got their XMas releases in... Hall of Fame Football,
Earth Control (or something like that) and one other game struck my interest
but I didn't want to drop too much $$$ all at once... And I saw Dances With
Wolves there too, which I definately will get next time I have a chance
and some extra $$$... Looks like there will be lots of good stocking
stuffers for poeple with CD-i players!
--
Paul Jerkatis - SandV BBS (708)352-0948: OS-9 Support
UUCP: amiserv.xnet.com!vpnet!sandv!mithelen ...or... mithelen@sandv.chi.il.us
Internet: MITHELEN@Delphi.com
-*-
90958 12-DEC 10:57 General Information
Downed Hard Drive! :-(
From: 01GEN40 To: ALL
Hello All, and Happy Holidays!
Quite unfortunately, my CoCos hard drive crashed yesterday 12/11. What
a bummer. I do not know how long it will be before I am back on-line with
my Trusty Little CoCo. I still have on-line access with the 486 non-Intel
PC at work so I can read the forum just before I have to start slaving. I
would like to know some tid-bits of info from anyone who has logged on with
a PC. I am using a program that emmulates ProComm, it came with a modem I
had bought for my CoCo. If anyone is familiar with the OS-9 program,
TelStar, it works similar. I have these wierd characters that precede dis-
plays such as these forum messages. There is a total of 10. I do not know
how to replicate a "right arrow" so I will use this <-. These are the char-
acters: <-[1;1H<-[2H I have gone into "Using Delphi" and cannot find any-
thing that would help me there. The only thing that I can think of is term-
inal emmulation. I cannot figure out how to change it in this program. Any
help will be most appreciated. See ya.
LONG LIVE OS-9! <FOREVER> ** In whatever form it is in!
-= 01GEN40 =-
-*-
90959 12-DEC 18:05 General Information
RE: Downed Hard Drive! :-( (Re: Msg 90958)
From: MIKE_GUZZI To: 01GEN40 (NR)
those weird characters are ansi escape codes, telstar doesn't understand them
you have to go to your profile settings and disable ansi
-*-
End of Thread.
-*-
90962 13-DEC 00:12 General Information
OS-9 Late Night Schedual
From: THETAURUS To: ALL
OS-9 Late Night
Conference Schedual
For December AND January
Date Time(EST) Topic
-------------------------------------------------------------
December 5, 1994 10:00 PM Open Forum
December 12, 1994 10:00 PM Open Forum
December 19, 1994 10:00 PM OS-9: The Year in Review
What exactly was
accomplished in '94 and
what can we improve on?
With CD-I hitting the
mainstream with good
success and Personal OS-9
Software starting to come
of age, it gives us
plenty to talk about!
December 26, 1994 10:00 PM Open Forum
January 2, 1994 10:00 PM OS-9 in '95!
What lies ahead for
OS-9 and the OS-9 User's
Group in the Coming year?
January 9, 1994 10:00 PM Open Forum
January 16, 1994 10:00 PM Countdown to Chicago!
Come join members of
the Glennside Color
Computer Club as we
discuss the upcoming
Chicago Cocofest, which
takes place on April
29,30 1994!
January 23, 1994 10:00 PM Open Forum
January 30, 1994 10:00 PM Open Forum
>Chris<
-*-
90965 13-DEC 17:07 General Information
RE: RiBBS/FidoNet Message Formats (Re: Msg 90932)
From: GREGL To: DGANTZ (NR)
That number could be a checksum of sorts, but it appears to have been aded
y e mailer and may not be required. As I stated previously, if the
header line isn't documented, it is either optional and has been added by
the mailer or you need better (more up-to-date) documentation. As a guess,
I'd say that line is probably optional so you can probably ignore it.
In fact, I'd say everything following the subject up to the body of the
message is optional and is probably treated by the board as part of the body.
One question, though. Are you using RiBBS or Fido documentation?
-- Greg
-*-
90972 14-DEC 03:34 Tutorials & Education
Termcap Programming
From: JOELHEGBERG To: ALL
In my 68'Micros column for the next couple months, I'll be tackling
Termcap programming in detail and giving some routines to make life with
Termcap a bit easier. A few people mentioned a live online conference
would be beneficial, and help complement the columns. So, on Tuesday,
December 20th at 10pm Eastern, I will be giving the live, online version
of my column for those interested. I love the live online format since
it offers great feedback through questions and the participants seem to
learn a lot from live conferences.
Looking forward to seeing all those interested!
Sincerely,
Joel Mathew Hegberg
-*-
FORUM>Reply, Add, Read, "?" or Exit>
Reference in New Issue View Git Blame Copy Permalink