AppleCommander 1.3.5.2
John B. Matthews
now available. It includes several new features and bug fixes from 1.3.5:
1. Handle multiple disks on command-line for -i, -ls, -l, -ll.
2. Added lock, unlock and volume rename options.
3. Fixed broken links in web site; added guide to release candidate.
4. Fixed a bug in which 2IMG disks with optional comments were
being misread.
5. Fixed a bug in which DosFormatDisk.getFiles() was iterating
tracks instead of sectors.
6. Fix a bug in which file and volume names were truncated.
7. Added MS DOS script example to command line guide.
You can download the current release candidate, here:
<http://sites.google.com/site/drjohnbmatthews/applecommander>
You can check out the latest sources from CVS, here:
<http://sourceforge.net/cvs/?group_id=67414>
For more information, visit the AppleCommander home page on SourceForge:
<http://applecommander.sourceforge.net/>
--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
Bill Buckels
"John B. Matthews" <nos...@nospam.invalid> wrote in message
news:nospam-2F1050....@news.motzarella.org...
>AppleCommander 1.3.5.2, the Java based Apple II disk image utility, is now
>available. It includes several new features and bug fixes from 1.3.5:
I am still trying to find time to incorporate this into the various Aztec C
Apple II distributions. I may do it as a separate interface (command line of
course) and call ac at the end of the build cycle using a disk template.
Still thinking on it and not ignoring you:)
If you are familiar with WinVice, the c1541 utility supports this sort of
thing and my ClipShop utility writes scripts that use it. I would do
something a little more advanced than that tho' and pehaps use syntax like
Ciderpress to store filetypes and load adresses etc.
Gotta run.
Bill
John B. Matthews
"Bill Buckels" <bbuc...@mts.net> wrote:
> "John B. Matthews" <nos...@nospam.invalid> wrote in message
> news:nospam-2F1050....@news.motzarella.org...
> >AppleCommander 1.3.5.2, the Java based Apple II disk image utility, is now
> >available. It includes several new features and bug fixes from 1.3.5:
> Dr. John,
> Still thinking on it and not ignoring you:)
[...]
No problem. I _think_ I fixed the file/volume name bug you reported.
(FLW :-) Keep me posted.
Bill Buckels
>Keep me posted.
I started this tonight, and as I had said before I wanted to get a 32 bit
MAKE utility in place for the Aztec C cross-compilers. However, it seems
that gnu make wants tabs instead of white-space indentation in make files
and further wants double dos slashes for DOS pathnames coming from
environments. Yich!.
Nmake works fine with either-or... and so does the good old 16 bit make.
These gnu boys seem to have their butts up their bum. This definetly is not
interop, it's unix. I gotta go wash my hands to get the extra slashes off
them and then rewrite the make files to work with this fussy thing.
Then I'll put ac in place and see how Aztec C and AC behave together.
Bill
Bill Buckels
news:UAGwk.47885$4s1....@newsfe06.iad...
>I started this tonight, and as I had said before I wanted to get a 32 bit
>MAKE utility in place for the Aztec C cross-compilers. However, it seems
>that gnu make wants tabs instead of white-space indentation in make
After sleeping on it, it got worse. This requirement by GNU make for tabs as
an indent ("seprator according to the GNU boys) is a real problem for a
Windows programmer who may not have hard-tabs set in their programmer's
editor or who may wish to use Windows notepad to create MAKEFILEs. I'll need
to look at the MAKE that comes with cygwin and see if it can be distributed
without the rest of the package.
You can always tell the GNU boys by their Green Plaid Pants.
<code>
#!/usr/local/bin/perl
# ---------------------------------------------------------------------
# Script Name : SNOT.pl (Say NO to Tabs)
# Author : bill buckels
# Date : June, 1997
# Purpose : Simple perl script to strip tabs from text files
#
# This program strips tabs from text files. It is especially useful for
# program source files.
#
# You may wonder why anyone would want to do such a thing, since the use
# of tabs to replace blocks of whitespace actually reduces the reported
# file size of most text files. Read on.
#
# Tab Wise, WhiteSpace Foolish - a not too serious synopsis of this program
# ----------------------------
#
# In case you haven't noticed, while the cost of disk space continues
# to fall through the floor, the slack a file uses on a dos machine
# has soared through the roof.
#
# In fact, the slack is greater than the size of many if not most simple
# text files, especially source code files, which out of shear
# manageability will typically waste more disk space than they occupy.
#
# Now that we have laid to rest that ancient myth of the false economy
# of tabs, I will shock you with a tale of the darker side of tabs and
# the programmers who use them.
#
# On a Clear Page You Can Tab Forever
# -----------------------------------
#
# Tabs seem to follow me everywhere, on every group project that
# I have participated in, where code is typically maintained, enjoyed,
# and mangled by different text editors with different tabstops and
# different preferences, like indent.
#
# If you have ever shared code with other unlike minded programmers,
# you may already have been introduced to the programmer in the green
# plaid pants.
#
# At the end of the day, all good source files need to go into a repository
# (like rcs) where they can be shared and stored and otherwise put to
rest.
# IMO they should also be cleaned and tabs removed.
#
# Tabstops can result in every line being reported as different, or
# looking quite different, just because somebody on the project uses
# hard tabs and somebody else doesn't.
#
# It is not very much fun looking for changes in code that has been
# altered in these various editors, some with tabs, some without, and
# some with both.
#
# Such a dilemma can put a large strain on a repository.
#
# It can also put a large strain on my eyes when one programmer uses
# tabstops of 8 characters and another uses 2 in the same source file.
#
# The combined effect is about as easy to look at as green plaid pants.
# In the ensuing distraction, it can be quite difficult to even read
# the code, let alone spot an error and fix the bug.
#
# If you wouldn't wear plaid pants to the job interview, why would you
# use hard tabs to do the job?
#
# White Power (Never Wear Green Plaid Pants)
# -----------
#
# My solution is to not use hard tabs, and to strip tabs from
# sources that have tabs in them. Hence the creation of this
# script and others that I have written like it.
#
# After code has become tab-infested it must be cleansed.
#
# Although I confess in days gone by to being guilty of the
# unrestrained use of these annoying creatures, I have long since
# tried to live a tab free life. But one can't avoid tabs.
#
# Odds are that these will indeed also someday mutilate your program
# or the code of someone you program with, and creep into every
# whitespace where they can fit.
#
# And having rendered the code unreadable and unmaintainable,
# (if it ever truly was) you may need a suitable ally in the use
# of this program, to cleanse away the tab monsters and put the
# whitespace back where it belongs.
#
# If the Tab Fits Lose It!
# ------------------------
#
# Rugger's Addendum: If your tabstops are less than 8 you are
# probably nesting too deep.
#
# Buckels's Madness: If your tabstops are more than 2 your
# variable names are probably too short.
# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
# Initialized Global Vars (mostly put here for clarity).
# ---------------------------------------------------------------------
$tabstop = 2; # default tabstop is 2
$startat = 0; # assume internal globbing
$tempfile = "\$\$\$"; # ignore temp files when building a list
$workfile = 'snotwork.$$$'; # use a filename that is ignored for output
$filetotal = 0;
$foundtotal = 0;
$linecount = 0;
# ---------------------------------------------------------------------
# Main Program
# ---------------------------------------------------------------------
mainprogram: {
print "SNOT(C) \"Say NO to Tabs\" Copyright 1997 Bill Buckels\n";
&getoptions;
&process;
}
# ---------------------------------------------------------------------
# Process Files in List
# ---------------------------------------------------------------------
sub process {
# -------------------------------------------------------------------
# print banner
# -------------------------------------------------------------------
print "Tabstop = $tabstop\n";
# -------------------------------------------------------------------
# if no filename was entered on the command line
# we search all files in the current directory
# -------------------------------------------------------------------
if ($startat == 0) {
# build the list...
while (<*.*>) {
next unless -f $_; # ignore specials
next unless -T $_; # ignore binaries
$retval = index($_,$tempfile,0); # ignore perl's temporary files
if ($retval < 0) {
$TARGETS[$cnt] = $_;
$cnt++;
}
}
# process the list...
foreach $target (@TARGETS) {
&searchfile;
}
}
# -------------------------------------------------------------------
# if a filename was entered on the commandline perl parses the
# commandline and expands the wildcards if any...
# -------------------------------------------------------------------
else {
# perl globs the file search spec on the command line and
# performs any necessary wildcard expansion
foreach $target (@ARGV) {
next unless -f $target; # operate on plain files only
next unless -T $target; # ignore binaries
$retval = index($target, $tempfile,0); # ignore perl's temporary files
if ($retval < 0) {
&searchfile;
}
}
}
# -------------------------------------------------------------------
# post an additional message if unsuccessful...
# -------------------------------------------------------------------
if ($filetotal == 0) {
# if no files say so...
print "File not found... exiting.\n";
}
else {
# if nothing found say so...
if ($foundtotal == 0) {
print "no files contain tabs...\n";
}
}
}
# ---------------------------------------------------------------------
# open file and read lines
# ---------------------------------------------------------------------
sub searchfile {
$filetotal++;
if (!(-w $target )) { # change readonly to read write
chmod 0666, $target;
}
if (-w $target ) { # ignore readonly
open(OUTFILE, ">$workfile") || die ("can't open $outfile $!\n");
# don't slurp the infile... just run free in...
open(INFILE, "<$target") || die ("can't open $target $!\n");
print "Reading File : $target\n";
print " : Current Line";
$linecount = 0;
$changes = 0;
while (<INFILE>) {
if ($_ eq "\n") {
print OUTFILE "\n"; # bypass blanks
}
else {
chop($_);
$retval = index($_, "\t", 0); # ignore lines without tabs
if ($retval < 0) {
print OUTFILE "$_\n";
}
else {
&expandtabs;
}
}
$linecount++;
print "\r$linecount";
}
close(INFILE);
close(OUTFILE);
print "\n";
print "$changes tab(s) expanded\n";
if ($changes != 0) {
unlink($target) || die("unable to unlink $target: $!");
rename($workfile, $target) || die("unable to rename $workfile to
$target: $!");
$foundtotal++;
}
else {
unlink($workfile);
}
}
else {
print "Skipping read-only file $target\n";
}
}
# ---------------------------------------------------------------------
# expand tabs in a buffer
# ---------------------------------------------------------------------
sub expandtabs {
$buffer = $_; # assume default string, work on a copy
$spaces = $tabstop; # initialize spaces to a full tab
$len = length($buffer);
for ($charcnt = 0; $charcnt < $len; $charcnt++) {
$c = substr($buffer, $charcnt, 1);
if ($c eq "\t") {
# tab found, so print remaining spaces
$changes++;
for ($i=0; $i < $spaces; $i++) {
print OUTFILE " ";
}
$spaces = $tabstop;
}
else {
$spaces--; # other character found, one less space required
# until next tabstop
if ($spaces < 1) {
$spaces = $tabstop; # spaces are all used so
# reset to a full tabstop
}
print OUTFILE $c;
}
}
print OUTFILE "\n"; # print eol and outa here
}
# ---------------------------------------------------------------------
# getoptions
# - parses the command line for valid arguments
# ---------------------------------------------------------------------
sub getoptions {
$startat = 0; # default internal globbing
$tabstop = 2; # default tab stop
# -----------------------------------------------------------------
# try to get tabstop length from first commandline argument
# -----------------------------------------------------------------
if ($ARGV[0] ne '') { # assume filespec is the argument
$startat = 1; # assume glob the command line
$a = $ARGV[0];
$len = length($a); # a little overkill here
if ($len == 1 ) { # if the command line arg is 1 char
$i = ord($a); # allow tabstop lengths of 1-9
if ($i > 48 && $i < 58 ) { # if numeric arg is in range
$tabstop = $i - 48; # override default tabstop setting
if ($ARGV[1] eq '') { # if not followed by a second arg
$startat = 0; # use internal globing
}
}
}
}
}
x--- snip ---x
SNOT(1) SNOT(1)
NAME
snot.pl - Say NO to Tabs
SYNOPSIS
snot.pl [tabstop 1-9] [filespec(s)]...
if no filename was entered on the command line processes all files
in the current directory using a default tabstop of 2.
DESCRIPTION
Snot.pl is a utility written in Perl to strip tabs from text
files. It is especially useful for program source files.
You may wonder why anyone would want to do such a thing, since the
use of tabs to replace blocks of whitespace actually reduces the
reported file size of most text files. Read on.
WHY
Tab Wise, WhiteSpace Foolish
A not too serious synopsis of this program.
In case you haven't noticed, while the cost of disk space
continues to fall through the floor, the slack a file uses on a
dos machine has soared through the roof.
In fact, the slack is greater than the size of many if not most
simple text files, especially source code files, which out of
shear manageability will typically waste more disk space than they
occupy.
Now that we have laid to rest that ancient myth of the false
economy of tabs, I will shock you with a tale of the darker side
of tabs and the programmers who use them.
On a Clear Page You Can Tab Forever
Tabs seem to follow me everywhere, on every group project that I
have participated in, where code is typically maintained, enjoyed,
and mangled by different text editors with different tabstops and
different preferences, like indent.
If you have ever shared code with other unlike minded programmers,
you may already have been introduced to the programmer in the
green plaid pants.
At the end of the day, all good source files need to go into a
repository (like rcs) where they can be shared and stored and
otherwise put to rest. IMO they should also be cleaned and tabs
removed.
Tabstops can result in every line being reported as different, or
looking quite different, just because somebody on the project uses
hard tabs and somebody else doesn't.
It is not very much fun looking for changes in code that has been
altered in these various editors, some with tabs, some without,
and some with both.
Such a dilemma can put a large strain on a repository.
It can also put a large strain on my eyes when one programmer uses
tabstops of 8 characters and another uses 2 in the same source
file.
The combined effect is about as easy to look at as green plaid
pants. In the ensuing distraction, it can be quite difficult to
even read the code, let alone spot an error and fix the bug.
If you wouldn't wear plaid pants to the job interview, why would
you use hard tabs to do the job?
White Power (Never Wear Green Plaid Pants)
My solution is to not use hard tabs, and to strip tabs from
sources that have tabs in them. Hence the creation of this script
and others that I have written like it.
After code has become tab-infested it must be cleansed.
Although I confess in days gone by to being guilty of the
unrestrained use of these annoying creatures, I have long since
tried to live a tab free life. But one can't avoid tabs.
Odds are that these will indeed also someday mutilate your program
or the code of someone you program with, and creep into every
whitespace where they can fit.
And having rendered the code unreadable and unmaintainable, (if it
ever truly was) you may need a suitable ally in the use of this
program, to cleanse away the tab monsters and put the whitespace
back where it belongs.
If the Tab Fits Lose It!
Rugger's Addendum: If your tabstops are less than 8 you are
probably nesting too deep.
Buckels's Madness: If your tabstops are more than 2 your variable
names are probably too short.
WHERE
In writing this utility so, I wanted to create a utility that I
would find useful in unix as well as dos (regardless of flavor).
USAGE
Usage 1 : "snot.pl"
Usage 2 : "snot.pl [filespec(s)]"
Usage 3 : "snot.pl [tabstop 1-9]"
Usage 4 : "snot.pl [tabstop 1-9] [filespec(s)]"
OUTPUT
The output is to a temporary file. If tabs are removed, the
original file is removed and the temporary file is renamed
to the original filename.
If no args are entered, all the files in the current directory
are stripped of tabs.
If a tabstop argument is not entered, a default tabstop of 2
is used.
WILDCARDS
Perl has built-in globbing of filenames that is really nice, which
allows multiple file specs to follow the first arg or two on the
command line.
i.e. if I want to tabstrip *.txt and *.c at the same time, I just
snot.pl *.txt *.c
PROGRAM
The program is organized in my usual rather onerous and verbose
style, and anyone not wishing to make a mountain out of a molehill
may wish to skip reading the code altogether.
- Global Variables (Mostly for Clarity)
- mainprogram subroutine (for Clarity)
- call getoptions subroutine to read command line
- process
Read the source code for additional notes. 'Nuff said.
AUTHOR
Bill Buckels <bbuc...@escape.ca>
</code>
Bill Buckels
"Bill Buckels" <bbuc...@mts.net> wrote in message
news:UAGwk.47885$4s1....@newsfe06.iad...
>I started this tonight, and as I had said before I wanted to get a 32 bit
>MAKE utility in place for the Aztec C cross-compilers. However, it seems
>that gnu make wants tabs instead of white-space indentation in make
>files...
I will just use a batchfile to separate ac from the MAKE altogether and
forget this GNU nonsense.
Bill
John B. Matthews
"Bill Buckels" <bbuc...@mts.net> wrote:
> I will just use a batchfile to separate ac from the MAKE altogether and
> forget this GNU nonsense.
Having seen "snot" upthread, I agree! :-) Nothing about AppleCommander
requires make or tabs. It runs fine from sh, csh tcsh, perl, ant, etc.
Bill Buckels
In article <hmOwk.39362$9u1....@newsfe09.iad>,
"Bill Buckels" <bbuc...@mts.net> wrote:
>Having seen "snot" upthread, I agree! :-) Nothing about AppleCommander
>requires make or tabs. It runs fine from sh, csh tcsh, perl, ant, etc.
<g> Just seeing if you were awake.
Of course not thankfully. You forgot bash and ksh:)
Anyway the Java Runtime runs just about fine everywhere. A wise choice.
As for my planned revision of the DOS 3.3 and ProDOS bundles of the Aztec C
MS-DOS Apple II cross-compiler. along with tons of application samples that
I wrote over the last several months, and additional documentation that I
have aquired and digested and will regurgitate, 2 make utilities will be
available - gmake and tmake (turbo make from the borland museum). Aztec C's
make is not compatible with either...) and is mostly just around for
nostalgic reasons.
1. I am going to provide gnumake 32 bit version for Windows Users with ac
disk generation out of the MAKEFILE.32 of course. Windows users can also use
the nmake utility that comes with Visual Studio Express 2005 for free from
Microsoft if they object to a gnu make or prefer nmake. I will provide an AC
directory environment etc.in the ubiquituous aztec.bat that can be used by
the MAKEFILE.
Windows Users can use TextPad or some other programmer's editor that uses
tabs to write MAKEFILE's if they are using gnu make. I will say so in the
documentation. I will also cover in detail how I glue ac into the Windows
User's 32 bit build and test environment for Aztec C. That should do it.
2. Unix users will need to run DOSEMU in one terminal with turbo make and a
16 bit MAKEFILE.16 and a shell script in another which they can use to call
ac when they are done their build, to create their disk image. I will
provide a generic shell script for the occasion.
Multiple terminals. Reminds me of An Early Music Synthesizer:) remember the
Beagle's cartoon with the cats tails attached to the keys.
See the link below:
http://www.aztecmuseum.ca/catkey.png
That's probably about enough for now.
Bill
mdj
> After sleeping on it, it got worse. This requirement by GNU make for tabs as
> an indent ("seprator according to the GNU boys) is a real problem for a
> Windows programmer who may not have hard-tabs set in their programmer's
> editor or who may wish to use Windows notepad to create MAKEFILEs. I'll need
> to look at the MAKE that comes with cygwin and see if it can be distributed
> without the rest of the package.
If you're going to be requiring AppleCommander and thus Java, did you
consider using Ant instead? That would get around most of the make
wrinkliness (and I agree it's a royal pain) and make it dead simple to
have portable build files.
If you're lucky, someone might even write a task wrapper for
AppleCommander too ...
Matt
Bill Buckels
news:2875ff6f-846c-45a7...@b38g2000prf.googlegroups.com...
On Sep 7, 8:11 pm, "Bill Buckels" <bbuck...@mts.net> wrote:
> After sleeping on it, it got worse. This requirement by GNU make for tabs
> as
> an indent ("seprator according to the GNU boys) is a real problem for a
> Windows programmer who may not have hard-tabs set in their programmer's
> editor or who may wish to use Windows notepad to create MAKEFILEs. I'll
> need
> to look at the MAKE that comes with cygwin and see if it can be
> distributed
> without the rest of the package.
>If you're going to be requiring AppleCommander and thus Java, did you
>consider using Ant instead? That would get around most of the make
>wrinkliness (and I agree it's a royal pain) and make it dead simple to have
>portable build files.
That is a good thought, Matt. I could use <exec> commands instead of a
conventional make tool but I think that would be overkill in this case.
Still I like what Ant's creator says:
>Makefiles are inherently evil as well. Anybody who has worked on them for
>any time has run into the dreaded tab problem. "Is my command not executing
>because I have a space in front of my tab!!!" said the original author of
>Ant way too many times. Tools like Jam took care of this to a great degree,
>but still have yet another format to use and remember.
I do think that as long as I provide a decent choice of support for make
utilities for MS-DOS emulation under unix, and for Windows native mode
supporting GNU make and Apple Commander in the samples that I am bundling, I
will have gone as far as I should go with Aztec C's "out-of-the-box"
configuration.
Bill
mdj
> That is a good thought, Matt. I could use <exec> commands instead of a
> conventional make tool but I think that would be overkill in this case.
> Still I like what Ant's creator says:
>
> http://ant.apache.org/
>
> >Makefiles are inherently evil as well. Anybody who has worked on them for
> >any time has run into the dreaded tab problem. "Is my command not executing
> >because I have a space in front of my tab!!!" said the original author of
> >Ant way too many times. Tools like Jam took care of this to a great degree,
> >but still have yet another format to use and remember.
>
> I do think that as long as I provide a decent choice of support for make
> utilities for MS-DOS emulation under unix, and for Windows native mode
> supporting GNU make and Apple Commander in the samples that I am bundling, I
> will have gone as far as I should go with Aztec C's "out-of-the-box"
> configuration.
Understood. Having the requirement of supporting windows is the hard
part here. I'd mostly forgotten how annoying Makefiles were to write
be hand; automake and autoconf have hidden it away as a 'low level'
tool for years now. But supporting those on Windows requires Perl and
M4. It's considerably simpler to switch to Java based tools.
For the ultimate in build tool elegance, check out Rake - Rubys
equivalent of Make, where the 'Rakefile' is simple, clean, elegant
Ruby code - no more having to remember yet another syntax, well,
assuming you're a Ruby programmer ;-)
Matt
Jeff Blakeney
On Mon, 8 Sep 2008 08:37:25 -0700, mdj wrote:
> Understood. Having the requirement of supporting windows is the hard
> part here. I'd mostly forgotten how annoying Makefiles were to write
> be hand; automake and autoconf have hidden it away as a 'low level'
> tool for years now. But supporting those on Windows requires Perl and
> M4. It's considerably simpler to switch to Java based tools.
>
> For the ultimate in build tool elegance, check out Rake - Rubys
> equivalent of Make, where the 'Rakefile' is simple, clean, elegant
> Ruby code - no more having to remember yet another syntax, well,
> assuming you're a Ruby programmer ;-)
This thread is making me even gladder that I don't program in C or some
of those other languages. My make files for my Orca/M projects are
simply batch files to generate my macro file, compile my program and, if
needed, copy the resource fork I created with Genesys to my newly
created executable and possibly change the filetype of my executable.
In Windows, I use a language called PowerBASIC and I just click a button
in the toolbar or pick a single menu item to either compile, compile and
execute or debug my program.
BluPhoenyx
This is primarily a cross compiler issue. Aztec C on the real (or
emulated) hardware uses batch (aka script) files in similar fashion.
Likewise HyperC and I believe Kyan Pascal also. Although I have the
tools, I haven't delved into the Orca system enough to say whether it
does though.
Cheers,
Mike T.
Bill Buckels
news:48C5AF21.1050....@a2central.com...
>This is primarily a cross compiler issue.
That's for sure. And as a matter of fact my original Aztec C Cross-Compiler
environment just used batch files back in late 80's - early 90's. I added
the makefiles when I started the Aztec C website. That was the right thing
to do I think.
It isn't really as hard as all that (is it Mike?) and this is much to-do
about nothing really except getting some automation in place.
I know, I know, you were too polite to say it, so I did:)
I also dare say I could also have used a2tools and ignored Apple Commander
altogether but that is not the challenge here... the challenge is to make an
old MS-DOS cross-compiler work with the new stuff, if can put it so bluntly.
(I always do anyway:)
Dr. John has done the ultimate cross-platform Apple Toy. Why not play with
the durned thing??? right?
>Aztec C on the real (or emulated) hardware uses batch (aka script) files in
>similar fashion.
As you know (if anyone does) all this Aztec C stuff still works great and
it's easy as pie to use.
Most of this thread is just thinking-out-loud and wondering how far I want
to take the automation part. That's all.
And of course it's not really about Aztec C at all, but about using Apple
Commander's command line to make diskimages that coincidently I want to
create as Aztec C makefile targets. If someone was paying me money to do
this is would be out the door in a batch file in a New Jersey minit...
But hey a guy wants to play with Apple Commander and other new toys, right?
As far as writing in BASIC in Windows, try writing a VB.NET application in
Windows and running it under mono in Linux for a fun day or two. Writing the
application is dead simple. Running it in the mono runtime in Linux is a
little like running AppleCommander in Windows... it is a deployment issue.
How can we best deploy such a thing is the problem, and so many solutions
are available, that I just wanted to kick-around a couple or so.
>Likewise HyperC and I believe Kyan Pascal also. Although I have the tools,
>I haven't delved into the Orca system enough to say whether it does though.
Likewise, and here is what I once wrote Bill Garber when we were discussing
Aztec C.
>Orca C is WAY NICER than Aztec C. Slicker too. Aztec C is more fundamental
>in the flavour of the day. Two different generations. Think C for the MAC
>is cool too, but that was the next generation.
So many programs, so little time. I gotta get the GS set-up. I don't much
like KEGS.
Bill
Bill Garber
"Bill Buckels" <bbuc...@mts.net> wrote in message news:3hjxk.1977$f43....@newsfe02.iad...
That is absolutely true, but remember that back in the day, there
was only a few compilers for "C", Aztec being one, so like Bill B.
says, it's more of a 'if we're going to write for the vintage box,
why not use a vintage compiler', although Orca"C" is a much better
system.
> So many programs, so little time. I gotta get the GS set-up.
> I don't much like KEGS.
Kegs is ok, and I use it, the ActiveX version, for some things,
IE.; testing disk images, compiling ASM code (Merlin runs very
fast at 80-110 MHz on the emulator), and initial trial of the
BIN, or SYS finished program. Then the real IIgs is definitely
necessary to ensure that your code is right. Of course, a IIe
is better if you're not coding for the 65C816, per se.
Did I say all that? ;-)
Bill Garber from GS-Electronics
http://www.garberstreet.com
Bill Buckels
news:1f2dnQ7pcqckW1jV...@comcast.com...
>That is absolutely true, but remember that back in the day, there was only
>a few compilers for "C", Aztec being one
In 1989 while still collecting as many 8086 based C compilers as I could get
my hands-on, I had no idea as I purchased Microsoft C version 5.1 and
scrapped my Mix C and Aztec C for commercial work, that the days of Aztec C
were numbered.
It didn't dawn on me until last year when I discovered my old floppies from
the Apple II and C64 stuff that I once did that they were gone. Then I
rediscovered the comp.sys.apple2 groups who have provided so much over the
years... remembered all about emulators and all that, etc. Longed for
simpler times.
>it's more of a 'if we're going to write for the vintage box, why not use a
>vintage compiler', although Orca"C" is a much better system.
I bought-into this as well. I did the same to some degree over at
comp.sys.cbm which is still going-strong too and started remembering the
times that were much funner (if there is such a word).
>Kegs is ok, and I use it, the ActiveX version, for some things, IE.;
>testing disk images, compiling ASM code (Merlin runs very fast at 80-110
>MHz on the emulator), and initial trial of the BIN, or SYS finished
>program.
I missed the GS mostly because I was intent on making money on the IBM-PC. I
can't believe that I gave mine back to the guy who gave it to me. Dis the
same with my Mac IIci as well. It's time to refocus back on what I forgot
The new tools facilitate all that, but I find myself getting hooked on the
real thing.
>Then the real IIgs is definitely necessary to ensure that your code is
>right.
Or just to make sure your fun is optimal:)
>Did I say all that? ;-)
Don't worry. You were very reserved:) Are you tired? Time for some BB King
and Lucille I think.
Bill
mdj
blz-this> wrote:
> To: mdj
>
> On Mon, 8 Sep 2008 08:37:25 -0700, mdj wrote:
> > Understood. Having the requirement of supporting windows is the hard
> > part here. I'd mostly forgotten how annoying Makefiles were to write
> > be hand; automake and autoconf have hidden it away as a 'low level'
> > tool for years now. But supporting those on Windows requires Perl and
> > M4. It's considerably simpler to switch to Java based tools.
>
> > For the ultimate in build tool elegance, check out Rake - Rubys
> > equivalent of Make, where the 'Rakefile' is simple, clean, elegant
> > Ruby code - no more having to remember yet another syntax, well,
> > assuming you're a Ruby programmer ;-)
>
> This thread is making me even gladder that I don't program in C or some
> of those other languages. My make files for my Orca/M projects are
> simply batch files to generate my macro file, compile my program and, if
> needed, copy the resource fork I created with Genesys to my newly
> created executable and possibly change the filetype of my executable.
The batch/shell script approach is fine for very small projects, but
as things get larger the time taken to do a scratch rebuild can become
unwieldy. So, make and friends allow regeneration of just the files
that have changed, which in the case of a typical C program is:
"rebuild changed source file and relink". The process gets
considerably more complex when one starts using code generators (for
example, lex and yacc) and Make utilities become essential to project
management.
As others have mentioned, the key problem here is because of cross
compilation. Very few build utilities (with the except of Java's Ant
and Maven) provide a level of abstraction high enough to have
identical behaviour across multiple platforms.
> In Windows, I use a language called PowerBASIC and I just click a button
> in the toolbar or pick a single menu item to either compile, compile and
> execute or debug my program.
It's certainly less of a hassle with higher level languages. That
said, my Merlin projects on the Apple II have a considerable number of
PUT and USE directives at the top of each main project.
Matt
John B. Matthews
"Bill Buckels" <bbuc...@mts.net> wrote:
[...]
> Dr. John has done the ultimate cross-platform Apple Toy.
[...]
If I may clarify, Apple Commander is Rob Greene's creation and he wrote
the vast majority of the code. He even did UML diagrams:
<http://applecommander.sourceforge.net/uml/index.html>
I fixed a few bugs and wrote the command line driver. The latter's
relative simplicity is due to Rob's clean, polymorphic design. The
credit goes to him; the errors are mine.
> Why not play with the durned thing??? Right?
Hear, hear!
Michael J. Mahon
> It's certainly less of a hassle with higher level languages. That
> said, my Merlin projects on the Apple II have a considerable number of
> PUT and USE directives at the top of each main project.
That's how I handle the several different configurations of NadaNet:
for ProDOS, DOS, AppleCrate, Message Server, and boot ROM.
The program is divided into a dozen or so "modules" of various related
functions. Each module contains conditional assembly to allow finer
grain selectivity (in come cases down to substitution of a single
instruction).
Each version is produced by a small source program that sets up the
conditional assembly variables and then does a sequence of appropriate
USEs and PUTs. There is no actual code in these files, they are just
"scripts" to build the appropriate versions.
-michael
AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Bill Buckels
>If I may clarify, Apple Commander is Rob Greene's creation and he wrote the
>vast majority of the code. He even did UML diagrams:
<http://applecommander.sourceforge.net/uml/index.html>
I remember the days before UML when RUP was young and we all wanted it. We
called it OMG back then and the notation was similar.
http://en.wikipedia.org/wiki/Unified_Modeling_Language
I gave up Saturday Mornings and Tuesday and Thursday evenings for over half
a year to attend my Object Oriented Analysis and Design courses at out local
university and invariably drew my static and dynamic models The year was
1997. I was invariably called-upon to draw my static and dynamic models,
message traces, etc. from our assignments as the rest of the class, mostly
my peers led by my instructor discussed all in great detail. We approached
all the Grady-Booch-Rumbaugh stuff and Ivar Jacobson had just come into the
fold with his use cases back then. When Ivar Jacobson spoke at the Rational
Symposium in Toronto a year or so later, I was able to ask him direct
questions about Use Cases. It was there that he talked about the software
industry's evolution and said "We used-to build doghouse, now we build real
houses." His picture of the doghouse reminded me of my first BASIC
program:) We roared with laughter!
The following year (1998) as Manager of Product Development and ISO 9000
Team Leader I was working for a Java and C/C++ shop. Our methodlogy was RUP.
From Requisite Pro and Rose to completion, we used with varying degrees of
succession this NWO that had really started back in the '60's.
Having said that, I appreciate the dedication and planning that has gone
into this.
I would also like to say that anyone familiar with UML should know what Ivar
told me. Even the most significant system has no more than about 20 USE
cases.
This is "one less reason" that we all have not to use UML:) to clarify and
communicate our designs.
And having said that, all of my programming that I have resurrected was done
in my pre-UML days and I don't have time in my wretched life to be objective
about all of this for hobby-stuff and redo the programs and diagram them
etc. It would be nice for the rest of the world and a royal pain for me. I
choose me:)
And I admire the dedication of one who does take the time and make the
effort...
Hat's off to Rob Greene.
Bill
Bill Buckels
news:ELWdnfk_nbN4gFvV...@comcast.com...
>The program is divided into a dozen or so "modules" of various related
>functions.
The following MAKEFILE is the existing MAKEFILE for my METOO sample project
that will be distributed with the AppleX Aztec C ProDOS target
cross-compiler. The ac calls etc. still need to be added of course and the
bloadable header for the ac portion of the make will be left intact to
facilitate proper placement on disk images (like waht Dr. John is suggesting
for CC65).
When we get beyond "Hello World" we probably all need to organize ourselves
with function libraries and modular design at the very least.
Bill
x--- snip ---x
# ------------------------------------------------------------------
# (C) Copyright 2008 Bill Buckels
#
# note: I am copying ovld.r and samain.r to the current directory
# to avoid linker commandline exceeding maximum length.
# note: the libraries are listed twice on the linker line
# this ensures that LN65 resolves routines in libraries
# that have dependencies on other libraries.
# note: my utility MAKEPRO2 is required to strip the BLOADable header
# from the linker output in the root module and to embed the
# the raw bitmap flip-flop screen in the memory hole in the
# root module.
#
# Have Fun!
# Bill Buckels
# bbuc...@mts.net
#
# ------------------------------------------------------------------
me2.sys: me2.r cinit.r plogo.r mainmenu.r me20.r me21.r me22.r me23.r me24.r
me2r.r
copy $(CR65)ovld.r ovld.r
copy $(CR65)samain.r samain.r
LN65 -t -r +s +H 4000,6004 me2.r +C E00 +D 980 ovld.r
samain.r -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me2.r
MAKEPRO2 me2 baggage\flip\EFLOP.BOT
copy me2 moi2
MAKEPRO2 moi2 baggage\flip\FFLOP.BOT
del me2
del moi2
@echo me2.sys now created!
LN65 -t cinit.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del cinit.r
@echo cinit.ovr now created!
LN65 -t plogo.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del plogo.r
@echo plogo.ovr now created!
LN65 -t mainmenu.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del mainmenu.r
@echo mainmenu.ovr now created!
LN65 -t me20.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me20.r
@echo me20.ovr now created!
LN65 -t me21.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me21.r
@echo me21.ovr now created!
LN65 -t me22.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me22.r
@echo me22.ovr now created!
LN65 -t me23.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me23.r
@echo me23.ovr now created!
LN65 -t me24.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me24.r
@echo me24.ovr now created!
LN65 -t me2r.r $(CR65)ovbgn.r
me2.rsm -lSYSIO -lg2 -lc -ls -lm -lSYSIO -lg2 -lc -ls -lm
del me2r.r
@echo me2r.ovr now created!
del me2.rsm
del me2.sym
del cinit.sym
del plogo.sym
del mainmenu.sym
del me20.sym
del me21.sym
del me22.sym
del me23.sym
del me24.sym
del me2r.sym
del samain.r
del ovld.r
copy *.ovr ENGLISH\*.ovr
copy *.ovr FRENCH\*.ovr
del *.ovr
copy me2.sys ENGLISH\me2.sys
copy moi2.sys FRENCH\moi2.sys
del *.sys
cls
@echo Done!
me2.r: me2.c
c65 me2.c
cinit.r: cinit.c
c65 cinit.c
plogo.r: plogo.c
c65 plogo.c
mainmenu.r: mainmenu.c
c65 mainmenu.c
me20.r: me20.c
c65 me20.c
me21.r: me21.c
c65 me21.c
me22.r: me22.c
c65 me22.c
me23.r: me23.c
c65 me23.c
me24.r: me24.c
c65 me24.c
me2r.r: me2r.c
c65 me2r.c
Oliver Schmidt
>The batch/shell script approach is fine for very small projects, but
>as things get larger the time taken to do a scratch rebuild can become
>unwieldy.
Thanks for pointing out. Comparing batch scripts with makefiles is
like comparing apples and oranges...
Best, Oliver