In the PC realm, it would be nice if we could move IF out of the DOS realm
and into a slight GUI realm without violating the sanctity of the GUI of
the typical IF format, which is--no pictures, requires typing.
Someone should standardize on a game shell that uses a Win32 GUI format. I
think menus (for save/restore/exit/game choice/preferences), a statusbar
(for room/score), scrollbar (for history) on a textbox, and background/font
color and font size would be not too much to ask. We need something like
and Inform DLL object that can be called from VB. You could write the
language in Inform, then display it in a VB form rather than a DOS console.
Oooh! <* eyes squinting as if I saw something gross *> I have seen some
ugly implementations of text adventures in VB. Most have buttons and don't
allow typing. Also, there's only an acceptable set of buttons for words,
which takes the fun out of guessing what the "acceptable words" are in a
scene. But I don't mean to say I don't want people to use VB--no no. I do
mean that the VB implementations of IF should take advantages of the OTHER
features of VB besides buttons. For instance, VB now has an excellent
object and collection portion of its language, so one could take advantage
of more advanced designs, such as a window object that remembers its state
when it is smashed, or what have you. Other drawbacks of DOS consoles
are--can't change the font beyond about 10 blocky types, can't change
background/font colors, can't scroll back on your history, can't print your
command history, and the EXE has an ugly white icon in Win 95/NT.
However, since I don't see this in effect today, I'm working on this. It's
tough to write these things, so I hope someday to use someone else's system
if it's better than mine.
Mike McKee
Raleigh, NC, USA
---Signature goes here...
>In the PC realm, it would be nice if we could move IF out of the DOS
>realm and into a slight GUI realm without violating the sanctity of the
>GUI of the typical IF format, which is--no pictures, requires typing.
>Someone should standardize on a game shell that uses a Win32 GUI format.
But then whither platform independence? I'd wager that the majority of
serious I-F fans (those on this newsgroup and rgif, let's say) are NOT
using Windows NT or Windows 95 as their operating system.
I know I'm not.
========
Steven Howard
bl...@ibm.net
"Are you a COBOL programmer?" "No, but people tell me I look like one."
: In the PC realm, it would be nice if we could move IF out of the DOS realm
: and into a slight GUI realm without violating the sanctity of the GUI of
: the typical IF format, which is--no pictures, requires typing.
I think not. I don't like bloatware.
Besides, what's wrong with typing in SAVE? You have to type in everything
else.
: Someone should standardize on a game shell that uses a Win32 GUI format. I
: think menus (for save/restore/exit/game choice/preferences), a statusbar
: (for room/score), scrollbar (for history) on a textbox, and background/font
: color and font size would be not too much to ask. We need something like
: and Inform DLL object that can be called from VB. You could write the
: language in Inform, then display it in a VB form rather than a DOS console.
Status Bar? You can implement that WITHOUT a GUI, (or if you don't want
to don't).
ScrollBar history? Why not just add a history buffer, and use arrowkeys?
Kind of like DOSKEY <G>
Colour and Font? You *CAN* do that now in Win95! You can change the font
and colours in a DOS session.
VB? You're not serious are you? VB?
God save us! VB!
Get back to me when your brain has recovered from the concussion, and
you've learned Visual C or C++ or JAVA!
Hmm, as for a GUI interface, designing one for X should be easier.
: Oooh! <* eyes squinting as if I saw something gross *> I have seen some
: ugly implementations of text adventures in VB. Most have buttons and don't
: allow typing. Also, there's only an acceptable set of buttons for words,
: which takes the fun out of guessing what the "acceptable words" are in a
: scene. But I don't mean to say I don't want people to use VB--no no. I do
: mean that the VB implementations of IF should take advantages of the OTHER
: features of VB besides buttons. For instance, VB now has an excellent
: object and collection portion of its language, so one could take advantage
: of more advanced designs, such as a window object that remembers its state
: when it is smashed, or what have you. Other drawbacks of DOS consoles
: are--can't change the font beyond about 10 blocky types, can't change
: background/font colors, can't scroll back on your history, can't print your
: command history, and the EXE has an ugly white icon in Win 95/NT.
1. You can CHANGE the Icons
2. You *CAN* modify the font
3. You can change the COLOURING
4. You if you wanted to, could add history commands to IF *without* a GUI
Does anyone remember DOSKEY, NDOS, 4DOS
Has anyone used UNIX?
These things have scrollback histories for your command prompt
And you can print out the history list
: However, since I don't see this in effect today, I'm working on this. It's
: tough to write these things, so I hope someday to use someone else's system
: if it's better than mine.
I'd rather not see them, the way you've suggested things.
> In the PC realm, it would be nice if we could move IF out of the DOS realm
> and into a slight GUI realm without violating the sanctity of the GUI of
> the typical IF format, which is--no pictures, requires typing.
> Someone should standardize on a game shell that uses a Win32 GUI format.
This is exactly what I'm addressing with my Glk proposal. Except that the
game would work equally well with a Mac GUI shell, and non-GUI shells
such as terminal windows and PDAs.
http://www.edoc.com/zarf/glk/index.html
Plug, plug, plug.
Er, there are also Windows ZIP interpreters.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
> ***In the interest of protecting my email address from being scanned and
> put on a Yellow Pages CDROM, please remove SPAM and click here
> (mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
>
> In the PC realm, it would be nice if we could move IF out of the DOS realm
> and into a slight GUI realm without violating the sanctity of the GUI of
> the typical IF format, which is--no pictures, requires typing.
>
> Someone should standardize on a game shell that uses a Win32 GUI format. I
> think menus (for save/restore/exit/game choice/preferences), a statusbar
> (for room/score), scrollbar (for history) on a textbox, and background/font
> color and font size would be not too much to ask. We need something like
> and Inform DLL object that can be called from VB. You could write the
> language in Inform, then display it in a VB form rather than a DOS console.
[snip]
Uh, I'm a Mac user and may be incorrect, but aren't WinTADS and WinFrotz
two very nice GUI interfaces for IF? I don't think they use VB, but
still...
Or are you asking about standardization? Andrew Plotkin is working on
something called Glk that everyone is fighting about and
misunderstanding that may have some bizarre relation to what you are
talking about.
--David Glasser
gla...@NOSPAMuscom.com
You can do all that stuff with WinFrotz and WinTads. I play in 10-point
Verdana, myself.
The vast majority of computer users run Windows 95 (and a further small
minority run NT). What makes you believe the IF fans are not typical
computer users?
Does the fact that I run NT automatically rule me out as being a
"serious I-F fan"? :-).
Chris
----------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com).
Visit our web site at: http://www.skymap.com
Astronomy software written by astronomers, for astronomers.
GUI software to play text games exist now so I wonder if perhaps I've
missed your point. Are you talking here about GUI software to _write_
text games? I don't know of any released software in that category.
Anyway, if you want to try some GUI text game-playing programs ...
Windows 95/NT 'runtime interpreters' exist for interactive fiction
written using the TADS and Inform systems.
You can download them from the Interactive Fiction Archive along with
some TADS and Inform games to try.
URLS:
basic if-archive info ...
ftp://ftp.gmd.de/if-archive/README
Win NT/95 Inform game player ...
ftp://ftp.gmd.de/if-archive/interpreters-infocom/frotz/WinFrotzR52.zip
Win NT/95 TADS game player ...
ftp://ftp.gmd.de/if-archive/programming/tads/executables/wintads2.zip
Inform games ...
ftp://ftp.gmd.de/if-archive/games/infocom/
TADS games ...
ftp://ftp.gmd.de/if-archive/games/tads/
--
SteveG.
(Please remove the typo from my address
if you want to send me mail.)
Thanks for the nice words. It seems like we have a lot of people on Unix in
this newsgroup who like consoles and Java. Not that I don't like to
encourage diversity, I am not a fan of either system. I am happy that
others like such stuff immensely, and that others like the DOS prompt, but
I find it too limiting, especially with the conventional RAM limitation. It
looks like it's going to be an uphill battle if I wish to remain in
rec.arts.int-fiction newsgroup.
I also want to encourage a system where there are "ports" to other
platforms for your design. So, when I hear of support for the Mac and PDAs,
I love to hear that--even though I only use NT 4 or Win 95.
Mike McKee
(Mike Smith is a fake name meant to confuse direct marketing CDROM
publishers)
Andrew Plotkin <erky...@netcom.com> wrote in article
<erkyrathE...@netcom.com>...
> Mike Smith (sup...@remedy.com) wrote:
>
> > In the PC realm, it would be nice if we could move IF out of the DOS
realm
> > and into a slight GUI realm without violating the sanctity of the GUI
of
> > the typical IF format, which is--no pictures, requires typing.
>
> > Someone should standardize on a game shell that uses a Win32 GUI
format.
>
In this case, I meant "light GUI". I meant I would like to see folks on the
PC platform get IF out of the DOS prompt and into a stretchable,
scrollable, minimizable window. Most importantly, DOS has this conventional
RAM thing that you might not have known about--the programs can only use so
much RAM before hitting their limit, even if your PC has 100MB. There are
many other inconveniences with using a DOS prompt. I don't mean to say I
want graphics, or that you could use a joystick, or that you click
buttons--not at all. I just think some simple, "light GUI" conveniences
would be nice. For instance, one could set game preferences either from
commands in a window or by clicking on the application's menu bar, choosing
Preferences, and setting them. Also, one could change the font type, font
color, and background color--something you cannot do in Win 95's DOS
window. That's all. I meant nothing else by this.
To me, it's almost sacralegious to take a console game and link it to a
joystick, or give it a button interface, or add graphics. I actually say
that in slight jest--the new graphical Zork seems neat, but I do prefer
more the console version.
Mike McKee
> Andrew,
>
> Thanks for the nice words. It seems like we have a lot of people on Unix in
> this newsgroup who like consoles and Java. Not that I don't like to
> encourage diversity, I am not a fan of either system. I am happy that
Many of the people still developing / playing IF are stuck with consoles.
As far as I'm concerned, having a text console as the lowest common
denominator is not a problem. The object of IF should surely be good
writing and compelling plots, not "lots of funky windows".
Java, whether you like it or not, is taking off. It's platform independent,
is "strongly" OO and is easy to learn (well, easier than C++, anyhow). But
It isn't supported on all systems. What are the people who use PDAs, Amigas
etc going to do if we go Java? I *like* Java, and develop in Java for a
job. But if it ain't portable, you're cutting out a significant portion of
your audience. So where does that leave VB? It's platform specific, run
by a company who change their "standard" overnight. That is one of the
reasons many companies I know refuse to have anything to do with VB. If
MS decide to break the language, you're screwed. It may work now, but when
you come to change it, it won't work.
I reckon the way to go is to stick with the Z-machine standard. Your
development environment for it may vary but the end result is the same.
Your IF is portable across all supported platforms (and name me one which
isn't). A better argument would be for a better (read "easier") Z-machine
compiler. You have some good points regarding Inform. It isn't easy to
learn or use. But it works *very* well. Ditching it to use VB or something
else would seem to be throwing the baby out with the bathwater IMHO. Not
to mention re-inventing the wheel.
The argument over "spaghetti" code is the same. If you view a computer
program as a "black box" into which you pump input and from which you expect
output, and it does that consistently, what does it matter *how* it's done?
Not that I'm suggesting writing bad code :) but it doesn't make any
difference to the person playing the game.
> others like such stuff immensely, and that others like the DOS prompt, but
> I find it too limiting, especially with the conventional RAM limitation. It
RAM limitation is only a problem with DOS machines (and with machines that
have limited ram). I'm not going to get into a "my machine's better than
yours" argument here, though (but it is =:P )
> looks like it's going to be an uphill battle if I wish to remain in
> rec.arts.int-fiction newsgroup.
I sincerely hope not. I'm sure everybody wants to see more people actually
"doing" IF. And I don't think anyone would want to discourage you.
>
> I also want to encourage a system where there are "ports" to other
> platforms for your design. So, when I hear of support for the Mac and PDAs,
> I love to hear that--even though I only use NT 4 or Win 95.
I'd rather see IF developed that's portable from the start. Rather like
the Z-machine, actually. Why invent a new standard, when there's already one?
I develop on a Mac and a Unix box. But I won't release to *just* those
machines.
Anyway. Good luck, and keep at it.
Simon
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------
I play in Courier New. (gray on blue in WinFrotz, yellow on black in
WinTADS.)
Besides, if you're in Win95, why are you using a DOS window? AGT games?
>>BKNambo
--
http://come.to/brocks.place
> Besides, if you're in Win95, why are you using a DOS window? AGT games?
Am I the only person out there who prefers DOS-window interpreters to
winfrotz, winzip and wintads?
I mean, I use 95 about 95% of the time now, and I almost never run
windows-based interpreters. I happen to think that interactivew fiction
just plain looks better in a full-screen dos console
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
I use Windows 95 at work, and wish I didn't. I'm very happy to be able
to use a friendly, fast and efficient GUI when I'm at home.
I suppose IF fans are not typical computer users because they spend so
much of their time playing these silly little out-of-date text
adventures instead of nuking lots of aliens in the latest Doom clone. I
think the point Steven Howard was trying to make is that there is much
more diversity in the IF community - Acorns, Amigas, PCs, Ataris, Macs,
UNIX machines etc.
>Does the fact that I run NT automatically rule me out as being a
>"serious I-F fan"? :-).
No... but that might make you a "seriously frustrated IF fan"... :-)
- NJB
: In this case, I meant "light GUI". I meant I would like to see folks on the
: PC platform get IF out of the DOS prompt and into a stretchable,
: scrollable, minimizable window. Most importantly, DOS has this conventional
: RAM thing that you might not have known about--the programs can only use so
: much RAM before hitting their limit, even if your PC has 100MB. There are
: many other inconveniences with using a DOS prompt. I don't mean to say I
Hmm, RAM limit, even if you have 100MB?
You mean the smashed 640kB barrier?
Gee, I wonder why SimCity 2000, DOS version said it'd need more than 640kB
to run, if it could only use 640kB because the rest is inaccessible <G>
Try DPMI, VCPI, etc.
: want graphics, or that you could use a joystick, or that you click
: buttons--not at all. I just think some simple, "light GUI" conveniences
: would be nice. For instance, one could set game preferences either from
: commands in a window or by clicking on the application's menu bar, choosing
: Preferences, and setting them. Also, one could change the font type, font
: color, and background color--something you cannot do in Win 95's DOS
: window. That's all. I meant nothing else by this.
But you can change the font, the colours of a DOS window.
: To me, it's almost sacralegious to take a console game and link it to a
: joystick, or give it a button interface, or add graphics. I actually say
: that in slight jest--the new graphical Zork seems neat, but I do prefer
: more the console version.
Why not use a Joystick interface? <G>
: In this case, I meant "light GUI". I meant I would like to see folks on the
: PC platform get IF out of the DOS prompt and into a stretchable,
: scrollable, minimizable window. Most importantly, DOS has this conventional
: RAM thing that you might not have known about--the programs can only use so
: much RAM before hitting their limit, even if your PC has 100MB.
Then use a DOS extender like GO32. Your other points are valid - the
DOS prompt is pretty horrid from the point of view of resizing windows
and scrollback - but there are lots of programs that let you access
all the PC's memory in a linear fashion.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Is this related to nostalgia, maybe? For a long time I couldn't stand
seeing Zork in more than 40 columns.
>L. Ross Raszewski wrote:
>>
>> I mean, I use 95 about 95% of the time now, and I almost never run
>> windows-based interpreters. I happen to think that interactivew fiction
>> just plain looks better in a full-screen dos console
>
>Is this related to nostalgia, maybe? For a long time I couldn't stand
>seeing Zork in more than 40 columns.
Bingo! I like to simulate a C64 display by running frotz in a DOS
window with the 12x16 font using the command line
>frotz -f 15 -b 7 -w 40 [gamefile]
and adjusting the width of the window so there's not a big empty space
on the right side.
--
Steve McKinney <sj...@bellsouth.net>
"Never let your sense of morals keep you from doing what is right."
--Isaac Asimov
I resent that a bit... if power/speed isn't an issue, VB is an ideal programming
choice. Although I work mainly in Visual C++, I've found that simple utilities
can be implemented very easily in VB and given a nicer interface with less work.
BTW, I think a language-generic virtual machine DLL would be great for Windows
platforms.
Russell
Which is? (Just curious) I'm a user of Win95 on the PC and IRIX on the SGI.
> I suppose IF fans are not typical computer users because they spend so
> much of their time playing these silly little out-of-date text
> adventures instead of nuking lots of aliens in the latest Doom clone.
Devil's advocate: I play out-of-date text adventures very seriously, but I
write really sophisticated 3d-type stuff. I use text in text-IF because it's
the appropriate for them, not because I'm in any way biased against
Doom-style technology or GUIs.
> I
> think the point Steven Howard was trying to make is that there is much
> more diversity in the IF community - Acorns, Amigas, PCs, Ataris, Macs,
> UNIX machines etc.
All these can run JAVA (actually, I'm not sure about Ataris, and I know
Amiga implementations are only minimal). A generic JAVA-based VM could run
with platform independence. And it's not as if it would be too slow...
text-IF doesn't use all that much computing power... that's one of the good
parts.
> >Does the fact that I run NT automatically rule me out as being a
> >"serious I-F fan"? :-).
>
> No... but that might make you a "seriously frustrated IF fan"... :-)
But a fan nonetheless. I can see this turning into some kind of religious
purity type of thing: let's keep generalizations about other fans out of the
discussion. Let everybody speak for themselves.
Russell
> I'd rather see IF developed that's portable from the start. Rather like
> the Z-machine, actually. Why invent a new standard, when there's already one?
> I develop on a Mac and a Unix box. But I won't release to *just* those
> machines.
>
What if the GUI standard was integrated into a new virtual machine? I mean, you
can do GUIs on consoles w/ text characters. The only "new" feature for the VM
would be mouse movement.
Russell
I do, too. Bigger text, simpler font than even MS Sans Serif.
Russell
John Elliott wrote:
> Mike Smith (sup...@remedy.com) wrote:
> : Stephen,
>
> : In this case, I meant "light GUI". I meant I would like to see folks on the
> : PC platform get IF out of the DOS prompt and into a stretchable,
> : scrollable, minimizable window. Most importantly, DOS has this conventional
> : RAM thing that you might not have known about--the programs can only use so
> : much RAM before hitting their limit, even if your PC has 100MB.
>
> Then use a DOS extender like GO32. Your other points are valid - the
> DOS prompt is pretty horrid from the point of view of resizing windows
> and scrollback - but there are lots of programs that let you access
> all the PC's memory in a linear fashion.
If I remember correctly from my DOS days, a program has to be written
specifically to use a DOS extender.
Russell
I still play games on my LA34 at 110 baud on thermal paper. How's that for
nostalgic!
Jarbigruen
If the following aren't issues:
- Power
- Speed
- Stability
- Disk usage
- Memory usage
- Portability
- Reliability
- Reusability of code
- Maintainability of code
- Expressive power of the language
- Assisting Bill Gates in his quest for world domination
...then VB is an ideal programming choice.
And I'm a banana.
mathew
--
Build a better browser @ <URL:http://www.pobox.com/%7Emeta/mozuki/>
"I have received much 'spam' mail that has led to the purchase of
products and services from very credible companies"
-- ri...@corrypub.com 404 @ <URL:http://www.pobox.com/%7Emeta/>
>In article <34de2...@news2.ibm.net>, Steven Howard <bl...@ibm.net>
>writes
...
>Does the fact that I run NT automatically rule me out as being a
>"serious I-F fan"? :-).
What about me? I'm serious SOME of the time!
Lelah
win95 user -- okay okay so i use what if find around me--
i'm supposed to--I'm an adventurer!
I used to agree with you, until I found the right font. I use WinTADS with
the default font/black on white colour scheme. WinFrotz, on the other hand,
I could never get to work right until I found the Verdana font. I believe it
was on the Project Gutenberg homepage. Now it has the right feel (colours:
white on dark blue).
Joe
Let's see:
--
>KILL TROLL WITH KNIFE
The troll sneers at your pathetic attack.
>GIVE WINTEL MACHINE TO TROLL
The troll gleefully grabs the computer and turns it on, happy to have
the most popular architecture in the world.
>Z
The troll bursts out with a string of trollish obscenities and starts
desperately typing.
>X COMPUTER
From what you can see on the monitor, it looks like half the plug 'n pray
devices didn't install correctly.
The troll continues to curse as he works in vain to make the computer work.
>KILL TROLL WITH KNIFE
Distracted by the computer, the troll succumbs to your attack.
--
Yeah, I guess a Win95 computer would be useful to an adventurer.
Josh (delurking for sillyness)
bean @ cc.gatech.edu
>>I mean, I use 95 about 95% of the time now, and I almost never run
>>windows-based interpreters. I happen to think that interactivew fiction
>>just plain looks better in a full-screen dos console
I agree. So there are at least two of us. But then I have NEVER liked the
Windows graphic screens (black on white is actually harder to read and for a
typist who spends any time at the keyboard it causes eye strain). I also prefer
the larger and better formed (with curves) built-in characters of Dos (on a pc
they are actually two systems, using different memory areas). Also it emerses
one more "in" the game with no distractions.
.>until I found the Verdana font. I believe it
>was on the Project Gutenberg homepage. Now it has the right feel (colours:
>white on dark blue).
Maybe. But then, maybe I am too "fuddy-duddy" to try it. I hate most of the
skimpy little Windows characters, they look good printed out on a laser
printer, but they are rarely easy to read on the screen.
FD Who admits to being a fuddy-duddy. Hurrrumph!
------------------------------------------------------------------------------
Femal...@aol.com "Good breeding consists in
concealing how much we think of ourselves and how
little we think of the other person." Mark Twain
Hehe.. I just gave up fuddy-duddy-ness, changing WinFrotz from a monospaced
font (Courier New) to a proportional one (Footlight MT Light, my
favorite)...
>>BKNambo
--
http://come.to/brocks.place
On NT 4, you can do this. But on Win 95, I see nothing to change the color
in the property sheet (you know, right click command EXE, choose
properties). Also, of the ability to change fonts--I can only change it to
a small set of fonts and cannot choose willy nilly any font I want. So, if
you know a way, as in registry key or what have you, then fire away! Let me
know.
Mike McKee
If you're using Frotz, you can change the colors using command line
arguments. For instance
>frotz -f 15 -b 7 [gamefile]
will run Frotz with white letters on a gray background. -f controls
the foreground color, -b the background, -F the foreground for
reversed text, -B the background for reversed text, and -e the color
of emphasized text.
Yeah, but in 40 columns Zork doesn't display the prayer in the book
properly: you can't see one of the clues.
Even so, I also prefer to play my IF in a text display instead of a GUI
window. It just seems more clean, somehow. Maybe it's because when they
first started making GUI windows for IF there seemed to be lots of redraw
problems, and the fonts were usually too thin and hard to read, and you
couldn't set the colors to white on dark blue the way I always played
older IF games. People actually seemed to think that black on white was
better, and didn't mind the harsh glare of the white screen. Ick.
Carl
The Acorn Risc-OS desktop. Currently only Risc-OS 3.11, but if the nice
finance company agree to give me a loan, I might be able to upgrade to
Risc 3.5 or 3.6 or whatever it is at the moment.
>> I suppose IF fans are not typical computer users because they spend so
>> much of their time playing these silly little out-of-date text
>> adventures instead of nuking lots of aliens in the latest Doom clone.
>
>Devil's advocate: I play out-of-date text adventures very seriously, but I
>write really sophisticated 3d-type stuff. I use text in text-IF because it's
>the appropriate for them, not because I'm in any way biased against
>Doom-style technology or GUIs.
In my silly way, I was trying to get across the point that most people
are only into Doom clones, and that we are different because we like
quality, intelligence and good fiction in our games. (That sounds so
pompous. And it is. So there.)
>> I
>> think the point Steven Howard was trying to make is that there is much
>> more diversity in the IF community - Acorns, Amigas, PCs, Ataris, Macs,
>> UNIX machines etc.
>
>All these can run JAVA (actually, I'm not sure about Ataris, and I know
>Amiga implementations are only minimal). A generic JAVA-based VM could run
>with platform independence. And it's not as if it would be too slow...
>text-IF doesn't use all that much computing power... that's one of the good
>parts.
I can't believe that JAVA will run on low-end machines. I can just
imagine the spec... to get it working at a decent speed, it'd probably
need 10Mb+ of HD, 8Mb+ of memory and a processor of 200Mhz or above...
(I have very little experience or knowledge of JAVA, so this may be
wildly inaccurate.)
>But a fan nonetheless. I can see this turning into some kind of religious
>purity type of thing: let's keep generalizations about other fans out of the
>discussion. Let everybody speak for themselves.
Grief! Chill out. I was joking.
- NJB
M> ***In the interest of protecting my email address from being
M> scanned and put on a Yellow Pages CDROM, please remove SPAM and
M> click here (mailto://shortc...@ntwrks.com) or use this
M> newsgroup to reply.***
That useless crap doesn't stop spammers from getting your email
address, but it does stop useful emailed replies.
M> In the PC realm, it would be nice if we could move IF out of the
M> DOS realm and into a slight GUI realm without violating the
M> sanctity of the GUI of the typical IF format, which is--no
M> pictures, requires typing.
Um, Winfrotz? MaxZip?
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
In the next world, you're on your own.
Hmm. I hope not, I hope we are welcoming. Note that there is a huge
range of computer opinions here. (and I doubt anyone much like dos, from
the point of view of a die-hard command line user, the command line is lousy
and as you say, the ram limitation).
But:
Mike, no offense, but have you actually looked at what is out there?
Specifically, look at WinFrotz, for instance. Or MaxTads. We already
have several "open" standards. We have, for example, the Z machine,
which is quite usuable, to the point that Andrew Plotkin wrote a
usable scheme implementation in it. The z machine is available on
gods knows how many different platforms, a hell of a lot, anyway, and
Java. What exactly would this "open standard" offer that the z machine
doesn't?
For what it is worth, BTW, I run at work or home 13 by my count different
OSs. All of them have a working z machine, some of them quite nice (like
the really nice BeOS port of frotz). Actually, I'm not sure if there is
a port to Plan 9, but I think there is. Note that dos, Windows anything
and the mac are not on this list. That, in my books, is pretty diverse.
Many of these also offer gui type things, mousing, etc etc.
I guess I'm a little confused, because I am still not quite sure what the
system you are addressing will offer, in terms of how it differs from the
existing systems.
BTW, check out http://ugrad-www.cs.colorado.edu/~crosby/ifmap/IFMap.html
for a tool I began some time ago, that lets you draw a map visually.
Someone came up with a patch that lets you generate tads from it. Is
this something like you have in mind? As it stands the tool is really
only a prototype level thing, though I do use it for mapping all my
games. I was going to expand on it, but lack of time and lack of
interest by others got in my way.
>I also want to encourage a system where there are "ports" to other
>platforms for your design. So, when I hear of support for the Mac and PDAs,
>I love to hear that--even though I only use NT 4 or Win 95.
--
Matthew Crosby cro...@cs.colorado.edu
Disclaimer: It was in another country, and besides, the wench is dead.
Sure you can. It indented the part of the line that wraps around:
This is all part of the
first line.
It did on the Apple, anyway.
Jon
Whoa! Me like very very much. If I used TADS I'd go for that
in a second. Jon
Pompous, yes, but I agree 100%.
> >All these can run JAVA (actually, I'm not sure about Ataris, and I know
> >Amiga implementations are only minimal). A generic JAVA-based VM could run
> >with platform independence. And it's not as if it would be too slow...
> >text-IF doesn't use all that much computing power... that's one of the good
> >parts.
>
> I can't believe that JAVA will run on low-end machines. I can just
> imagine the spec... to get it working at a decent speed, it'd probably
> need 10Mb+ of HD, 8Mb+ of memory and a processor of 200Mhz or above...
> (I have very little experience or knowledge of JAVA, so this may be
> wildly inaccurate.)
>
Okay... I've run it well on one of the old PCs at school: 20MB HD space
(for Netscape 3)
8MB RAM
Pentium 60Mhz
> >But a fan nonetheless. I can see this turning into some kind of religious
> >purity type of thing: let's keep generalizations about other fans out of the
> >discussion. Let everybody speak for themselves.
>
> Grief! Chill out. I was joking.
Sorry. Consider me chilled. I'm so cool you could store a side of meat in me for
a week :).
Russell
Never had a problem with this.
> - Disk usage
Never had a problem with this, either.
> - Memory usage
On the Windows machines its designed for, I've never noticed this to be a
problem.
> - Portability
Agreed. But your quick n dirty utils don't need portability. Least mine
don't.
> - Reliability
Not sure what you're talking about here.
> - Reusability of code
Seems fine to me.
> - Maintainability of code
Seems fine, once again.
> - Expressive power of the language
What? Don't quite get your drift. If you're talking about the lack of real
object orientation, I agree with you.
> - Assisting Bill Gates in his quest for world domination
As if using Visual C++ didn't do the same thing...
> ...then VB is an ideal programming choice.
For some things, as I said originally.
> And I'm a banana.
Watch out for monkeys.
Russell
> Neil said:
> > I use Windows 95 at work, and wish I didn't. I'm very happy to be able
> > to use a friendly, fast and efficient GUI when I'm at home.
> >
>
> Which is? (Just curious) I'm a user of Win95 on the PC and IRIX on the SGI.
I think he is refering to the Acorn's RISC OS.
Which has always confused me. Aren't PowerPC's the RISC chips (yes, I
know that is redundant)?
--David Glasser
gla...@NOSPAMuscom.com
Check out my new I-F website at http://onramp.uscom.com/~glasser
Or, for a waste of time almost as good as spatch.net,
http://www.geocities.com/SoHo/6028/
> > I think he is refering to the Acorn's RISC OS.
> >
> > Which has always confused me. Aren't PowerPC's the RISC chips (yes, I
> > know that is redundant)?
> RISC stands for reduced instruction set, versus CISC - complex
> instruction set. So RISC refers to a category of CPU architecture, not to
> a specific brand name or whatever.
Which is why Acorn chose "RISC OS" as a brand name for their software.
Snort. Why not "CPU OS"? Even more general...
--Z ("I run 'Computer OS'!")
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Good grief! Is this what people consider a 'low end' machine?
I can still run IF at blindingly fast speeds on my 386/25 DX.
And that's using a windows-based emulator under WFW 3.11.
Admittedly the machine has never had less than 120Mb of disk,
and nowadays has 340 (and 8Mb of RAM, instead of 2Mb).
I've been considering offering it as a prize for IFComp 98
(so those Mac-only developers can do their own PC ports),
but I don't know if the fact that is now MMPC-compliant
would put people off. I suppose I could remove the modem,
sound card, & 2x CD-ROM, but what would I do with them?
It's even good enough to compile IF (and even IF compilers)
if you have enough patience. I don't, which is why the old
machine recently got superceded. Well, that, and the fact
that manipulating 20Mb scanned-in images from my negatives
runs so much better on a somewhat faster machine :-)
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
Fast forward to present. New Acorns have fast, efficient OS and highly
powerful CPU. And schools all over the country are swapping them for
PCs. Life, eh?
--
Matthew Garrett | ca...@enterprise.net
Well, the original version (pedants please shut up, this is not an Acorn
group!) was called "Arthur"....
Actually, the name was fairly specific when it was first coined, since the
ARM chip was the only serious RISC chip out there at the time. The
PowerPC followed a *lot* later.
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... "I can't believe it's not Rutter!"
*A* Reduced Instruction Set Computer chip, yes. *The* RISC chip, my God,
no! They aren't even the first, not by a long chalk. Actually, having
just had my first look at PowerPC assembler, "Reduced" is *not* the word I
would use for it. "Not as complex as an x86" maybe, but even that's
dubious :-)
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... Intel Outside
PowerPCs are RISC chips (as is the IBM Power architecture on which they
are based). So are SPARCs (used by Sun), HP PA-RISC, Dec Alpha, Mips
M*, (used by SGI), Motorolla 88000s, and, the chip the Acorn is
based on, the ARM. And many others.
I believe Acorn called their OS Risc OS because at the time, they where
one of the first people to produce a mass-produced RISC based machine.
Not the first...The IBM PC RT definately pre-dates them, and I suspect
the SPARC (aka Sun 4) came earlier also. Of course, both of these cost
significantly more and were not really "mass market" home machines.
Interestingly, there is at least one other OS with the name RISC OS (I
remember it being spelt RISC/OS though, but it was a long time ago); that was
a port of an ancient version of SysV Unix to MIPS Magnum machines. (based
on Mips M1000/M2000 chips; SGIs use descendents of these.)
BTW, it actually isn't redundant to say RISC chip: RISC stands for reduced
instruction set computing (not chips). It implies certain architectural
ideas, not so much simpler, as cleaner, more orthagonal, and easier to
pipeline and write compilers for. I could write a few paragraphs on
the basic features that are considered "RISC", but won't.
The CISC that RISC is a reaction to is not so much the 80x86 (though that is
a horrible architecture), but machines like the IBM 360 and VAX.
These days, of course, it has become a marketing word with little or zero
actual meaning; a lot of people throw it around without really knowing what
they are talking about and just about anything is claimed to be "RISC"
these days, even the intel which definately isn't (I don't care what
performance tricks they pull below the surface; it's architecture is still
the same, and there are still not enough registers and it is still a pain
to write compilers for it.) But there are a lot of architectures (including
the one I named) that show the RISC "philosophy".
Then obviously you weren't one of the people writing for VB in the early
days, who then found out the programs stopped working in the next
release...
> > - Disk usage
>
> Never had a problem with this, either.
No? You'd have trouble even fitting that humongous run-time onto some
of the handheld systems people use to play Infocom games.
> > - Memory usage
>
> On the Windows machines its designed for, I've never noticed this to be a
> problem.
Translation: Compared to the sucking hog of an OS I'm used to, it's not
that bad.
> > - Reliability
>
> Not sure what you're talking about here.
Every VB application I've used has been flaky.
> > - Reusability of code
>
> Seems fine to me.
>
> > - Maintainability of code
>
> Seems fine, once again.
I can only assume you've never worked on 50,000 line software
engineering projects, then.
> > - Expressive power of the language
>
> What? Don't quite get your drift. If you're talking about the lack of real
> object orientation, I agree with you.
Yes, and the lack of real first-class functions. And the lack of real
lists. And the lack of... etc.
> > - Assisting Bill Gates in his quest for world domination
>
> As if using Visual C++ didn't do the same thing...
Who ever suggested using Visual C++?
mathew wrote:
> Russell "Coconut Daemon" Bailey <cctd...@erols.com> wrote:
> > > - Stability
> >
> > Never had a problem with this.
>
> Then obviously you weren't one of the people writing for VB in the early
> days, who then found out the programs stopped working in the next
> release...
>
No, I wasn't. I came in with VB 3.
> > > - Disk usage
> >
> > Never had a problem with this, either.
>
> No? You'd have trouble even fitting that humongous run-time onto some
> of the handheld systems people use to play Infocom games.
>
A) Handhelds don't have disks.B) There is no handheld-machine version of VB.
C) No one ever suggested using it for all GUIs, just those on Windows machines.
> > > - Memory usage
> >
> > On the Windows machines its designed for, I've never noticed this to be a
> > problem.
>
> Translation: Compared to the sucking hog of an OS I'm used to, it's not
> that bad.
>
Bingo. The sucking hog of an OS which happens to be the dominant OS on the
market. The vast majority of people buy Windows. I won't get into why, because
that's a whole 'nother can of worms. However, I tend to develop for OSs people
use. Call me a capitalist. And what OS would you use VB for besides Windows or
its 16-bit cousin DOS? (Although VB-DOS really sucked...)
> > > - Reliability
> >
> > Not sure what you're talking about here.
>
> Every VB application I've used has been flaky.
>
Coders' fault, not the language's. And if I'm wrong, maybe you could define
"flaky"... I assume you mean the programs have bugs.
> > > - Maintainability of code
> >
> > Seems fine, once again.
>
> I can only assume you've never worked on 50,000 line software
> engineering projects, then.
>
Not in VB. Like I said earlier, VB is good for some things. Also, at 50,000
lines, anything is hard to maintain :).
> > > - Expressive power of the language
> >
> > What? Don't quite get your drift. If you're talking about the lack of real
> > object orientation, I agree with you.
>
> Yes, and the lack of real first-class functions. And the lack of real
> lists. And the lack of... etc.
"First-class functions"? Never had trouble with the built-in functions. Not as
good as C++, but few things are.
> > > - Assisting Bill Gates in his quest for world domination
> >
> > As if using Visual C++ didn't do the same thing...
>
> Who ever suggested using Visual C++?
>
I did. That or Borland is, IMAO, the best choice for Win32. Win32 is the
dominant OS on the market. Makes sense to use the best choices for the most
popular OS.
Russell
mathew <me...@pobox.com> wrote in article
<1d47806.w8h...@d78.dial-1.cmb.ma.ultra.net>...
> If the following aren't issues:
>
[snip list of issues]
> ...then VB is an ideal programming choice.
>
> And I'm a banana.
>
Mmmmmm. Banana. I like a banana.
-Fruit Fly
It's a reduced addressing mode chip.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
> >
> > And I'm a banana.
> >
> Mmmmmm. Banana. I like a banana.
>
> -Fruit Fly
>
I've been reading this group for some time (on and off) mainly for the
free Inform tuition, and trying to skip the tedious "my system is better
than yours" arguments but just occasionally someone will post a message
like this one.
Thank you. You made my whole day worthwhile.
David Brain
London, UK
>"Mike Smith" <sup...@remedy.com> writes:
>
>> Andrew,
>>
>> Thanks for the nice words. It seems like we have a lot of people on Unix in
>> this newsgroup who like consoles and Java. Not that I don't like to
>> encourage diversity, I am not a fan of either system. I am happy that
>Many of the people still developing / playing IF are stuck with consoles.
>As far as I'm concerned, having a text console as the lowest common
>denominator is not a problem. The object of IF should surely be good
>writing and compelling plots, not "lots of funky windows".
However, a few windows help the experience immensely. The interface that
vanilla XWindows provides strikes me as the best of both worlds for
someone comfortable at a command line: graphics when you need it, but the
big advantage is easy organization of work no matter what you're doing.
Be that as it may, consoles are no big deal as long as they work.
>Java, whether you like it or not, is taking off. It's platform independent,
>is "strongly" OO and is easy to learn (well, easier than C++, anyhow). But
>It isn't supported on all systems. What are the people who use PDAs, Amigas
>etc going to do if we go Java? I *like* Java, and develop in Java for a
>job. But if it ain't portable, you're cutting out a significant portion of
>your audience. So where does that leave VB? It's platform specific, run
>by a company who change their "standard" overnight. That is one of the
>reasons many companies I know refuse to have anything to do with VB. If
>MS decide to break the language, you're screwed. It may work now, but when
>you come to change it, it won't work.
For what it's worth, you could theoretically write a clone, but I actually
have the VB5 language reference and Microsoft has screwed it up just
enough that copying would be a pain in the ass. I don't doubt that this is
intentional, or at least indicative of Microsoft's general product
quality.
>I reckon the way to go is to stick with the Z-machine standard. Your
>development environment for it may vary but the end result is the same.
>Your IF is portable across all supported platforms (and name me one which
Hell, even Java :-)
>isn't). A better argument would be for a better (read "easier") Z-machine
>compiler. You have some good points regarding Inform. It isn't easy to
>learn or use. But it works *very* well. Ditching it to use VB or something
>else would seem to be throwing the baby out with the bathwater IMHO. Not
>to mention re-inventing the wheel.
The thing with Inform is that it may be very strange-looking, but it's
great for what it's designed for. I wouldn't design a programming language
like that, but then again in a sense neither did Graham (read the
Technical Manual before you argue with that).
>The argument over "spaghetti" code is the same. If you view a computer
>program as a "black box" into which you pump input and from which you expect
>output, and it does that consistently, what does it matter *how* it's done?
>Not that I'm suggesting writing bad code :) but it doesn't make any
>difference to the person playing the game.
It can, though, if it's sufficiently confusing that bugs get lost in the
mess, never to be fixed.
>> others like such stuff immensely, and that others like the DOS prompt, but
>> I find it too limiting, especially with the conventional RAM limitation. It
>
>RAM limitation is only a problem with DOS machines (and with machines that
>have limited ram). I'm not going to get into a "my machine's better than
>yours" argument here, though (but it is =:P )
>
>> looks like it's going to be an uphill battle if I wish to remain in
>> rec.arts.int-fiction newsgroup.
>
>I sincerely hope not. I'm sure everybody wants to see more people actually
>"doing" IF. And I don't think anyone would want to discourage you.
Me too.
>> I also want to encourage a system where there are "ports" to other
>> platforms for your design. So, when I hear of support for the Mac and PDAs,
>> I love to hear that--even though I only use NT 4 or Win 95.
>
>I'd rather see IF developed that's portable from the start. Rather like
>the Z-machine, actually. Why invent a new standard, when there's already one?
>I develop on a Mac and a Unix box. But I won't release to *just* those
>machines.
I gotta agree on this one. On the other hand, if you want to write a new
language that compiles to the Z-machine standard, that might be a very
good idea...
/Coach
--
Brian "Coach" Connors conn...@bc.edu
Cinnte, ta fhios agam labhairt Gaeilge. Cad chuige?
: The vast majority of computer users run Windows 95 (and a further small
: minority run NT). What makes you believe the IF fans are not typical
: computer users?
It seems a large number of users who post to rec.arts.int-fiction run
on Acorns, Amigas, Mac, BeOS, Linux, FreeBSD, HPUX, Solaris, AIX, and
(of course) the DOS and Windows platforms. And lest I be attacked, the
Apple IIGS as well.
: Does the fact that I run NT automatically rule me out as being a
: "serious I-F fan"? :-).
Nah. I run NT at work, too. Right next to my HP9000, which I prefer
greatly... ;)
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
Purely for amusement purposes, I wrote an interpreter for the Java
virtual machine (and a really naff Java compiler to test it with),
entirely in poor-grade C code. It ran at, oh, about 50 kHz, often
for upwards of ten seconds before the lack of good enough garbage
collection imploded its sad little world.
The virtual machine is actually neat and efficient. It's the class
library that's shocking. My Hello World spent about 20000 cycles
initialising the "Character" class, as I recall, which involved
hideous amounts of messing about with Unicode definitions. The
actual printing part was then almost instant.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Acorn's ARM (Acorn Risc Machine) processor dates from about 1986,
and is a highly RISC, 32-bit processor with entirely flat memory:
it was quite a breakthrough in its day, though not entirely unique.
It long precedes the PowerPC.
Yes, well, how true. I think the next version of Risc OS is being
called "Galileo", or something like that. "CopernicOS", perhaps.
Of course, some of us actually knew the eponynous Arthur.
And there was also "Brazil", as I remember. And "Springboard"?
Thank you so very much for ignoring OS/2. :揉
--
Ciao/2, Heiko.....
>mathew wrote:
>> Russell "Coconut Daemon" Bailey <cctd...@erols.com> wrote:
>> > > - Stability
>> >
>> > Never had a problem with this.
>>
>> Then obviously you weren't one of the people writing for VB in the early
>> days, who then found out the programs stopped working in the next
>> release...
>>
>No, I wasn't. I came in with VB 3.
I've had some experience with VB. Even in version 3, it suffered from
problems. The trouble is that VB uses a large runtime interpreter system
(even non-Windows users may have heard the nightmare stories about
VBRUNx00.DLL ;-)). It only takes a single bug in the interpreter code to
cause otherwise legal code to crash in certain configurations. And this
happened all too frequently.
The fact you didn't experience the mysterious bombing of the interpreter
seems to be either a) a matter of pure luck, or b) you didn't write any
power code in any of the many configurations that would cause the interpreter
to crash.
>> > > - Disk usage
>> >
>> > Never had a problem with this, either.
>>
>> No? You'd have trouble even fitting that humongous run-time onto some
>> of the handheld systems people use to play Infocom games.
>>
>A) Handhelds don't have disks.B) There is no handheld-machine version of VB.
>C) No one ever suggested using it for all GUIs, just those on Windows machines.
You're right here... VB is a Windows only development system, which is both
a strength and a weakness. I for example, am a Delphi developer, and I
recognise that my code will not run on any system other than Windows. It's
a tragedy you just have to live with ;-)
>> > > - Memory usage
>> >
>> > On the Windows machines its designed for, I've never noticed this to be a
>> > problem.
>>
>> Translation: Compared to the sucking hog of an OS I'm used to, it's not
>> that bad.
>>
>Bingo. The sucking hog of an OS which happens to be the dominant OS on the
>market. The vast majority of people buy Windows. I won't get into why, because
>that's a whole 'nother can of worms. However, I tend to develop for OSs people
>use. Call me a capitalist. And what OS would you use VB for besides Windows or
>its 16-bit cousin DOS? (Although VB-DOS really sucked...)
You're right. Lets not start a computer flame war. Although, I've always
been impressed by the level of civility we in this group display. We very
rarely start flaming each other, which, from reading other newsgroups, I
am really amazed at (comp.sys.apple2 for instance).
>> > > - Reliability
>> >
>> > Not sure what you're talking about here.
>>
>> Every VB application I've used has been flaky.
>>
>Coders' fault, not the language's. And if I'm wrong, maybe you could define
>"flaky"... I assume you mean the programs have bugs.
Actually not really. VB is interpreted (well, at least until v 5, which
is sort of compiled in the professional version). VB's runtime interpreter,
VBRUNx00.DLL, has been notorious for crashing under all sorts of
configurations... which generally left the programmer none the wiser on what
caused it, and meant he had to try and rewrite all his code to try and
avoid doing whatever it was that bombed the interpreter.
>> > > - Maintainability of code
>> >
>> > Seems fine, once again.
>>
>> I can only assume you've never worked on 50,000 line software
>> engineering projects, then.
>>
>Not in VB. Like I said earlier, VB is good for some things. Also, at 50,000
>lines, anything is hard to maintain :).
Depends on how well the language supports modularity. Even VB code can
be maintable if you do it well enough (only it wasn't until version 5? that
you could see more than one event function simultaneously).
>> > > - Expressive power of the language
>> >
>> > What? Don't quite get your drift. If you're talking about the lack of real
>> > object orientation, I agree with you.
>>
>> Yes, and the lack of real first-class functions. And the lack of real
>> lists. And the lack of... etc.
>"First-class functions"? Never had trouble with the built-in functions. Not as
>good as C++, but few things are.
The major problem I see currently with VB is that it doesn't support true
OO. The most it can do with version 5 is a sugar coating of COM principles
to inherit an interface but not the functionality of implemented code. This,
IMHO, is not true OO, and is still my biggest criticism of VB.
>> > > - Assisting Bill Gates in his quest for world domination
>> >
>> > As if using Visual C++ didn't do the same thing...
>>
>> Who ever suggested using Visual C++?
>>
>I did. That or Borland is, IMAO, the best choice for Win32. Win32 is the
>dominant OS on the market. Makes sense to use the best choices for the most
>popular OS.
As I've mentioned previously, I like Delphi. But Borland's other products
are excellent as well. In fact, a VB devotee should be thanking Delphi: it
was the comptetion from Delphi, more than anything, that spurred Microsoft
to try and improve VB, to the extent that VB now actually includes a
compiler (what an innovative feature ;-)).
>Russell
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
You can say THAT again!! csa2 is a flamebed!
>I've always
>been impressed by the level of civility we in this group display. We very
>rarely start flaming each other, which, from reading other newsgroups, I
>am really amazed at (comp.sys.apple2 for instance).
Um, ok, I didn't really mean that...
>I've always
>been impressed by the level of civility we in this group display. We very
>rarely start flaming each other, which, from reading other newsgroups, I
>am really amazed at (comp.sys.apple2 for instance).
Stop it.
>>BKNambo
--
http://come.to/brocks.place
Drat! I was trying, really. At least I remembered the IIGS! ;)
I suppose I was just lucky.
> You're right. Lets not start a computer flame war. Although, I've always
> been impressed by the level of civility we in this group display. We very
> rarely start flaming each other, which, from reading other newsgroups, I
> am really amazed at (comp.sys.apple2 for instance).
I like that too... especially since this is a newsgroup with contributors from many
different platforms.
> Actually not really. VB is interpreted (well, at least until v 5, which
> is sort of compiled in the professional version). VB's runtime interpreter,
> VBRUNx00.DLL, has been notorious for crashing under all sorts of
> configurations... which generally left the programmer none the wiser on what
> caused it, and meant he had to try and rewrite all his code to try and
> avoid doing whatever it was that bombed the interpreter.
>
I never wrote code that caused a problem I couldn't find documented somewhere.
Profiting from the torment of others, I suppose :).
> Depends on how well the language supports modularity. Even VB code can
> be maintable if you do it well enough (only it wasn't until version 5? that
> you could see more than one event function simultaneously).
>
The IDE has never been good. I edit most of my code (C++, VB, etc...) in Notepad.
> The major problem I see currently with VB is that it doesn't support true
> OO. The most it can do with version 5 is a sugar coating of COM principles
> to inherit an interface but not the functionality of implemented code. This,
> IMHO, is not true OO, and is still my biggest criticism of VB.
>
It's mine too. On the other hand, I feel very comfortable writing plain structured
code.
> As I've mentioned previously, I like Delphi. But Borland's other products
> are excellent as well. In fact, a VB devotee should be thanking Delphi: it
> was the comptetion from Delphi, more than anything, that spurred Microsoft
> to try and improve VB, to the extent that VB now actually includes a
> compiler (what an innovative feature ;-)).
>
I agree.
Russell
:I've had some experience with VB. Even in version 3, it suffered from
:problems. The trouble is that VB uses a large runtime interpreter system
:(even non-Windows users may have heard the nightmare stories about
:VBRUNx00.DLL ;-)). It only takes a single bug in the interpreter code to
:cause otherwise legal code to crash in certain configurations. And this
:happened all too frequently.
:
:The fact you didn't experience the mysterious bombing of the interpreter
:seems to be either a) a matter of pure luck, or b) you didn't write any
:power code in any of the many configurations that would cause the
interpreter
:to crash.
I've been using VB since VB1, and while you can find occasional problems in
it's run-time routines it, (like all languages), they have generally been
well-documented (via MSDN). We have been writing "power" code for quite a
while - including API calls, and interfacing with a large variety of
external devices and have still been able to provide stable applications.
:... VB is a Windows only development system, which is both
:a strength and a weakness. I for example, am a Delphi developer, and I
:recognise that my code will not run on any system other than Windows. It's
:a tragedy you just have to live with ;-)
:Actually not really. VB is interpreted (well, at least until v 5, which
:is sort of compiled in the professional version). VB's runtime interpreter,
:VBRUNx00.DLL, has been notorious for crashing under all sorts of
:configurations... which generally left the programmer none the wiser on
what
:caused it, and meant he had to try and rewrite all his code to try and
:avoid doing whatever it was that bombed the interpreter.
Once again, this has not been the case with the large number of projects
which I and various associates have been involved in. In fact, given the
greater scope for error in using VBX's and OCX's (third party add-ons which
have greatly contributed to VB's success), it's a wonder that there aren't
more problems!
:As I've mentioned previously, I like Delphi. But Borland's other products
:are excellent as well. In fact, a VB devotee should be thanking Delphi: it
:was the comptetion from Delphi, more than anything, that spurred Microsoft
:to try and improve VB, to the extent that VB now actually includes a
:compiler (what an innovative feature ;-)).
For a long time, Borland was the prime motivator for MS to improve their
development tools. In fact for quite a while, I feel that Borland's tools
were FAR superior to MS's. I used Turbo/Borland Pascal & C during the "DOS
days". They provided high quality, low cost tools. They also had some very
good libraries, especially when they OOP'ed Pascal. When VB came out,
however, the ease of creating a Windows program blew away any other tool
available. Did I have to have to eat some serious humble pie in moving from
C & even Pascal to Basic - you bet. But VB lets me concentrate on doing
what I want to do (from a business point of view) and less on how to do it
(from a programming point of view), than any other mainstream tool out
there. Another advantage is that it can be used for a larger span of tasks
than many other tools. For example, some prefer PowerBuilder for developing
corporate apps, but VB can also handle this well (at least since VB3 -
before then, DB access required third party tools). A small utility
program can easily be written in C or Delphi, but once again VB can handle
this. (Admittedly, while bringing along a large run-time, but as an uncle
told me 20 years ago - memory is cheap, don't waste a lot of time on it (and
that's when it really wasn't <g>)).
So is a VB app going to run everywhere? - No. But it is going to run on xx%
(fill in your preferred number - probably > 85%) of the machines out there,
and 95+% of the machines being sold today (including soon, WinCE palmtops -
though I still like my Pilot better). So I know what easy to use & highly
productive language I'll be using when I want to target the largest possible
audience with a single app/build.
-- Greg
GBrunet@Semper_Soft.com (remove underline for email reply)
http://www.SemperSoft.com
[Re: Acorn's RISC OS]
> > Well, the original version (pedants please shut up, this is not an
> > Acorn group!) was called "Arthur"....
> Of course, some of us actually knew the eponynous Arthur.
Apparently, a reliable source informs me, it wasn't actually named after
him. Apparently, a bunch of Acorn's technical people had spent ages
sitting round trying to come with a name for this thing that they had
thrown together in a couple of months, when Roger Wilson (as she then was)
said "Call it Arthur." "What?" chorused the others. "Look," said Roger,
"we've already wasted days trying to work out a name for the damn thing,
why don't we just call it 'Arthur' and be done with it."
And so it was.
[We now return you to your regularly scheduled IF rants]
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... but that's a herring of a different colour
OK, if you don't know what you're talking about then we may as well stop
here.
> EXAMINE SCREEN
The screen has two knobs marked 'brightness' and 'contrast'.
> ADJUST SCREEN
You adjust the screen correctly, so that white is no longer blinding.
[Your score just went up.]
On 13 Feb 1998 01:07:53 GMT, p...@yallara.cs.rmit.EDU.AU (Paul Francis
Gilbert) wrote:
[...]
>>> > > - Expressive power of the language
>>> >
>>> > What? Don't quite get your drift. If you're talking about the lack of real
>>> > object orientation, I agree with you.
>>>
>>> Yes, and the lack of real first-class functions. And the lack of real
>>> lists. And the lack of... etc.
>
>>"First-class functions"? Never had trouble with the built-in functions. Not as
>>good as C++, but few things are.
>
>The major problem I see currently with VB is that it doesn't support true
>OO. The most it can do with version 5 is a sugar coating of COM principles
>to inherit an interface but not the functionality of implemented code. This,
>IMHO, is not true OO, and is still my biggest criticism of VB.
What it -- not being able to inherit the functionality of code -- does do,
however, is remove the "fragile semantic base class" problem. Bascially,
this problem occurs when you base your code on the implementation of the
inherited code and that implementation changes. This can cause all sorts
of problems when dealing with code from disparate sources, and is a problem
with OO. This problem is a barrier to true Component Oriented Programming
(essentially creating programs out of "pre-manufactured" components, as is
the case in most mature engineering disicplines), which is why, I believe,
it is not supported by COM.
>>> > > - Assisting Bill Gates in his quest for world domination
>>> >
>>> > As if using Visual C++ didn't do the same thing...
>>>
>>> Who ever suggested using Visual C++?
>>>
>>I did. That or Borland is, IMAO, the best choice for Win32. Win32 is the
>>dominant OS on the market. Makes sense to use the best choices for the most
>>popular OS.
>As I've mentioned previously, I like Delphi. But Borland's other products
>are excellent as well. In fact, a VB devotee should be thanking Delphi: it
>was the comptetion from Delphi, more than anything, that spurred Microsoft
>to try and improve VB, to the extent that VB now actually includes a
>compiler (what an innovative feature ;-)).
While I'm here, I'll through my vote in for BlackBox Component Builder.
BlackBox is a Windows/Mac Component Oriented Programming development
Environment based on Component Pascal. http://www.oberon.ch/
';';James';';
Errr, throw, not through. Don't know what I was thinkin'.
';';James';';
This is not a language problem. This is a programming problem. You should
never base child class code on the specific implementation of the parent
class' code -- on documented behaviors of that code, yes, because those
behaviors should not change even if the implementation of them does. But on
specific lines of code, no.
--
athol-brose -- cinn...@one.net
>On Wed, 18 Feb 1998 02:40:18 GMT, jrc...@netspace.net.au (JC) wrote:
>>What it -- not being able to inherit the functionality of code -- does do,
>>however, is remove the "fragile semantic base class" problem. Bascially,
Actually, I made a mistake, it's the "semantic fragile base class" problem.
>>this problem occurs when you base your code on the implementation of the
>>inherited code and that implementation changes.
>
>This is not a language problem. This is a programming problem. You should
>never base child class code on the specific implementation of the parent
>class' code -- on documented behaviors of that code, yes, because those
>behaviors should not change even if the implementation of them does. But on
>specific lines of code, no.
I should prefix what I'm about by saying that I was, and am, talking about
Component Oriented Programming (COP). In my post, I replied to a statement
about COM, which is an acryonym for "Component Object Model". In the
realms of COP, the semantic fragile base class problem is most definitely a
language problem.
I don't really buy that "the language isn't the problem, you just have to
use it properly" argument.
Here's a few points which aren't just applicable to COP. Firstly, you're
not always going to have the behaviour -- interface -- of the code
documented. In my experience this is more the rule rather than the
exception. In this case it would be extremely difficult for the programmer
to not make assumptions about how the code works.
Secondly, I think it's just too tempting to base you code on the
implementation, in which case you might be able to make you're code much
more efficient, if that possibility is there.
Lastly, if it's not a language problem, then how do you explain all the
problems people are having with OO heirarchies? What people, in general,
know they should do and what they actually do are separate matters.
Now, onto COP.
For COP you have to guarantee that as long as a component comforms to a
particular interface it can be used in a particular situation.
This goes for different versions of components, and even components from
different manufacturers (for example, two componanies might produce a spell
checking component for word processors). You also have to remember that
components have to be able to even work with other components which may be
written in the future. These future components will be compatible if they
define the required interface, or some superset of it.
When you start making programs out of various interconnected components, of
which various will be replaced over time, and where you *won't* be able to
change the code of the old components to cater for the behaviour of the new
ones, then it is paramount that components conform to set interfaces and
that the implementation of these interfaces is not relied upon.
A final thing which should be pointed out is that implementation
inheritance can be used *within* components, it just shouldn't be used
*between* them.
';';James';';
But to be fair, some languages encourage the problem. With C and C++,
all too often the interface definition is not clearly separated from the
implementation. (Sure, it can be, but we all know how effective it is
to leave enforcement of this kind of thing to good habits on the part of
programmers.) Other languages, like Modula 2, are clearer about the
separation.
...a proprietary API from Microsoft. Hence:
> Here's a few points which aren't just applicable to COP. Firstly, you're
> not always going to have the behaviour -- interface -- of the code
> documented.
How else are they going to give their own applications an unfair
advantage?
They do exactly the same with their non-object-oriented APIs: don't
adequately describe them in the external documentation, then change them
on a whim to pull the rug out from competitors' feet, whilst making sure
their own applications keep working. Try asking anyone who's ever
written a MAPI mailer. It's not purely a problem with the language,
it's mostly a problem with Microsoft.
>JC <jrc...@netspace.net.au> wrote:
>> I should prefix what I'm about by saying that I was, and am, talking about
>> Component Oriented Programming (COP). In my post, I replied to a statement
>> about COM, which is an acryonym for "Component Object Model".
>
>...a proprietary API from Microsoft. Hence:
Actually, it's no longer proprietry. Apparently, control has been passed
to the Open Group standardization organization.
>> Here's a few points which aren't just applicable to COP. Firstly, you're
>> not always going to have the behaviour -- interface -- of the code
>> documented.
>
>How else are they going to give their own applications an unfair
>advantage?
Huh?
I'm talking about code in general. Nothing to do with particular
companies.
>They do exactly the same with their non-object-oriented APIs: don't
>adequately describe them in the external documentation, then change them
>on a whim to pull the rug out from competitors' feet, whilst making sure
>their own applications keep working. Try asking anyone who's ever
>written a MAPI mailer. It's not purely a problem with the language,
>it's mostly a problem with Microsoft.
Huh?
I really don't see how any of this is related to my post.
There seems to be some misunderstanding here. The only link I've made
between Microsoft and Component Oriented Programming is COM, their model
for components. And the only reason I've mentioned COM is that something
relating to it started this discussion. There's no Microsoft specificity
to what I've said.
I should have to say this, but don't think this post somehow demonstrates
any opinion of mine towards Microsoft.
';';James';';
>I should have to say this, but don't think this post somehow demonstrates
>any opinion of mine towards Microsoft.
shouldn't! shouldn't! not should!
Geez, I really have to start reading my posts more carefully before I send
them. I think this is the fourth in a row where I've realised a mistake
after I've sent it.
';';James';';
mathew <me...@pobox.com> wrote in article
<1d4sixy.1r9...@d226.dial-2.cmb.ma.ultra.net>...
> JC <jrc...@netspace.net.au> wrote:
> > I should prefix what I'm about by saying that I was, and am, talking
about
> > Component Oriented Programming (COP). In my post, I replied to a
statement
> > about COM, which is an acryonym for "Component Object Model".
>
> ...a proprietary API from Microsoft. Hence:
COM is not an API; it is a binary specification. It is equivalent to the
C++ object model for single inheritance described in Lippman. Having
the standard vtable layout is all that COM requires.
// in C++
pObject->AddRef();
/* implementation in C */
(*pObject->pvtbl[ 1 ])( pObject );
; x86 assembly. ecx points to object
mov eax, dword ptr [ecx]
mov eax, dword ptr [eax+4]
push ecx
call dword ptr [eax]
What could be simpler than that? (See _Inside COM_, _Effective COM_,
and _Inside OLE, 2nd edition_ for details.)
In rec.games.programmer they're discussing how to support
scripting in their game engines. The old approaches suggested are
reinventing the wheel (write a parser, compiler, and virtual machine)
and borrowing someone's wheels (link in embeddable language X.)
It seems to me that the right way to do this is to expose the object
model of their game and support scripting through a standard set of
interfaces. This is the interchangeable wheels approach -- you can
use VB, Java, C++, Perl, or any other language to manipulate these
components.
It might be interesting to make COM IF components. Then you could
use Inform objects in TADS or port them to a future language without
thinking. But it seems likely that the incompatabilities between these
languages are deeper than 'how do I access this method'.
--
Sam Inala
Yes, and aren't we glad... I had to learn Modula-3 for this term's Computer
Science course. I get so SICK of "Doing it this way is unsafe: be sure to
build in this layer of abstraction so that nobody can uses your code if they
try."
Joe
Yep, Modula-3 is a pain, but it makes you do it the "better" way.
(I rather prefer C, where I can do what I like with things, and use
everything inappropriately, because it works, is faster, and more
efficient. Ofcourse C++ seems restrictive after that)
: You shake the box, holding your ear near it, but it refuses to yield any clues
: about it's contents.
I'm not sure that's the right way to treat delicate machinery :-)
>REZROV BOX
The box springs open. Bytes fly in all directions.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Joe Mason wrote:
> In article <1d4sitr.1b2...@d226.dial-2.cmb.ma.ultra.net>,
> mathew <me...@pobox.com> wrote:
> >implementation. (Sure, it can be, but we all know how effective it is
> >to leave enforcement of this kind of thing to good habits on the part of
> >programmers.) Other languages, like Modula 2, are clearer about the
> >separation.
>
> Yes, and aren't we glad... I had to learn Modula-3 for this term's Computer
> Science course. I get so SICK of "Doing it this way is unsafe: be sure to
> build in this layer of abstraction so that nobody can uses your code if they
> try."
We all do this anyway, though, don't we? (Well _I_ do, and the people I've
worked with do...I guess I can't speak for anyone beyond that).
Whether you do your object-orientation in C, C++ or just about anything else
(yeah, you can do proper classes and everything in C, if you know how, and don't
mind a little jiggering), the key foci seem to be abstraction and encapsulation.
Couple abstraction and encapsulation with inheritance, and you have an 'object
oriented' platform. Without the first two, you aren't doing OOP. You're just
fooling with classes (and probably being unnecessarily complex).
An OOP structure _should_ (IMO) be simple, clean, and clear. Every class is a
black-box. You don't mess with it's insides. You can't _see_ it's insides. If
someone wants to change it's insides, that's fine. You don't care how it
performs it's assigned function, or if that method might change from version to
version or invocation to invocation. You just press the buttons on the top of
the black box and let it do it's thing.
> PUT QUESTION IN SLOT
You insert the query into the Black Box of Classy OOPness.
> PRESS BUTTON
You press the button, and the Black Box hums for a few moments, then spits out
the answer.
> Z
Little software gnomes scurry in, and replace the Black Box for another one just
like it. It has a tag attached.
> READ TAG
"Black Box of Classy OOPness, version 2.0."
> PUT QUESTION IN SLOT
You insert the query into the Black Box of Classy OOPness.
> PRESS BUTTON
You press the button and out pops the answer. It's the same answer, it's just
about a hundred times faster.