A small IF platform survey
Icedragon
I am interested to know, as an IF player, if you (well, in this case the IF
Usenet-based portion of players) have had success installing the .Net
Framework and running applications on it (excluding the WINE emulator). If
no, the next question is: would you consider installing it to play an IF
game? If not, what is something that the IF author could do to make it
easier for you to run?*
* pre-empt obligatory lectures on Z-code/Inform
Sands...@yahoo.com
Icedragon wrote:
<< I am interested to know, as an IF player, if you
(well, in this case the IF Usenet-based portion of
players) have had success installing the .Net Framework
and running applications on it (excluding the WINE
emulator). >>
No.
<< If no, the next question is: would you consider
installing it to play an IF game? >>
Probably not, but that's a moot question since I don't
know of a way to install .NET on my platform of choice
anyhow.
<< If not, what is something that the IF author could
do to make it easier for you to run? >>
Choose a system that runs on more platforms than just WinTel.
Sophie Fruehling
>Hello,
>
>I am interested to know, as an IF player, if you (well, in this case the IF
>Usenet-based portion of players) have had success installing the .Net
>Framework and running applications on it (excluding the WINE emulator).
I haven't tried.
>If no, the next question is: would you consider installing it to play an IF
>game?
No. Apart from the fact that I don't know if it would even run on
Windows 98, I'm not going to install a >20 mb program to run a 128 kb
game, especially if I don't think I'll ever use it for anything else.
>If not, what is something that the IF author could do to make it
>easier for you to run?*
I don't know what you mean by 'it'. The .Net framework or the game?
If you mean the game, use something, that makes for a smaller
download?
>* pre-empt obligatory lectures on Z-code/Inform
Use Tads, Hugo, Alan, Adrift, Paws, Quest write your own small,
portable C parser from scratch?
--
Sophie Frühling
"El arte no viste pantalones."
-- Rubén DarÃo
Adrien Beau
>
> I am interested to know, as an IF player, if you (well, in this
> case the IF Usenet-based portion of players) have had success
> installing the .Net Framework and running applications on it
> (excluding the WINE emulator).
I had no success because I made no attempt. By the way, Wine Is
Not an Emulator.
> If no, the next question is: would you consider installing it to
> play an IF game?
If the IF game was great and renowned, I would put the
installation of the .Net Framework on my TODO list, which means I
would do it at some random point in the next decade (at about the
same time I would take the chance to alter the configuration of
my Windows computer).
> If not, what is something that the IF author could do to make it
> easier for you to run?*
>
> * pre-empt obligatory lectures on Z-code/Inform
It is a miracle or a dream.
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
Greg Boettcher
> Hello,
>
> I am interested to know, as an IF player, if you (well, in this case
the IF
> Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE
emulator).
When I tried downloading the thing that was supposedly going to allow
me to play the .Net-requiring game from the last IF Comp, it turned out
to be a lot bigger than I thought, and I just decided I didn't want to
let Microsoft put something that big into my computer unless I
absolutely had to. (I'm not sure if I might have found something
smaller to do the same job, but still.)
> If
> no, the next question is: would you consider installing it to play an
IF
> game?
No.
> If not, what is something that the IF author could do to make it
> easier for you to run?*
>
> * pre-empt obligatory lectures on Z-code/Inform
Not require the .Net framework.
Greg
Jimmy Maher
> Hello,
>
> I am interested to know, as an IF player, if you (well, in this case the IF
> Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE emulator).
No.
> If
> no, the next question is: would you consider installing it to play an IF
> game?
No.
If not, what is something that the IF author could do to make it
> easier for you to run?*
As others have said, don't require me to install the .NET framework.
I'm actually a little confused as to why this issue keeps cropping up
with IF software. I have a fair variety of free, shareware, and
commercial software installed on this machine, and none of it has ever
required me to install this framework to run. Surely there is SOME way
to package software developed with .NET that is transparent to the user?
I think you need to ask yourself what this .NET framework will give you
that is worth losing all of your potential non-Windows players, as well
as a good percentage of those who do use Windows. Only you can know for
sure, but I suspect that there has to be another way that will work just
as well.
Jimmy
James Cunningham
> I am interested to know, as an IF player, if you (well, in this case the IF
> Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE emulator).
Only small, "Hello World"-ish programs. But I do have it installed
wouldn't be against using it for a game, so I suppose that I'm a
minority here.
best,
james cunningham
Paul Drallos
> Hello,
>
> I am interested to know, as an IF player, if you (well, in this case the IF
> Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE emulator).
No. Indirectly, yes. What a mess!
> If no, the next question is: would you consider installing it to play an IF
> game?
Absolutely not.
If not, what is something that the IF author could do to make it
> easier for you to run?*
>
> * pre-empt obligatory lectures on Z-code/Inform
>
I would suggest that *anything* you consider doing with .Net, you
should reconsider and do with Java.
Quintin Stone
> I am interested to know, as an IF player, if you (well, in this case the
> IF Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE emulator).
I installed it for your 2004 comp game Getting Back To Sleep. That's the
only program I've ever run with the .NET framework, and I'm pretty sure
that this was before my hard drive failure, so I no longer even have the
framework installed.
> If no, the next question is: would you consider installing it to play an
> IF game?
I installed it for IFComp04 for the sake of completeness. I'd probably do
the same again in the future, but only grudgingly, as the last game's only
distinguishing feature was that it was in real-time, something that I felt
didn't really add any value. Anyway, I'll probably install the .NET
framework eventually anyway, whenever it is I get around to learning the
.NET languages.
> If not, what is something that the IF author could do to make it easier
> for you to run?*
If you require the .NET framework and people don't want to download and/or
install it, I'm not sure what kind of answer you're looking for here.
There doesn't seem to be anything you could do to get around this.
==--- --=--=-- ---==
Quintin Stone "You speak of necessary evil? One of those necessities
st...@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David
dwh...@gmail.com
> the IF Usenet-based portion of players) have had success
> installing the .Net Framework and running applications on it
>(excluding the WINE emulator).
I had the NET framework installed before the IFComp last year but it
still didn't allow me to play your game properly. The cursor froze, the
screen wouldn't react and no matter what keys I pressed I saw different
letters appear on the screen. In the end, I deleted it.
> If no, the next question is: would you consider installing it to
play > an IF game?
I have it installed already but if I didn't, would I install it for the
sake of playing a game? No.
> If not, what is something that the IF author could do to make it
> easier for you to run?
Try writing the game with a platform that already exists instead of
creating your own. No one's impressed by a platform that doesn't work.
Steve
"Paul Drallos" <pdra...@tir.com> wrote in message
news:fv6dnRDV897...@comcast.com...
>
> I would suggest that *anything* you consider doing with .Net, you should
> reconsider and do with Java.
>
Even develope applications for PocketPC?!? Interesting...
Dave Griffith
> Hello,
>KILL THE FLY WITH THE AXE
Which axe do you mean, the teensy axe or the atomic-powered supersonic
planet-smashing axe?
>TEENSY
The fly expires.
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Brandon Roberson
were avilable for that platform, I still wouldn't install it under any
circumstances, and fortunately, it isn't.
Writing a game using .NET is certainly your perogative, but you'll
probably find that it gets played only by people who already have a
working installation of the .NET runtime. Writing your game in VB 6
would be less onerous, and that still leaves it a platform-specific
excercise in guess-the-DLL-version-needed.
If you really must write using a non-IF language, such as C, I'd
suggest writing in very portable ANSI-C, and providing source code to
allow those of us with the inclination to port your game to our
platform of choice -- even the Palm.
Best of luck!
Brandon
David Kinder
> I am interested to know, as an IF player, if you (well, in this case the IF
> Usenet-based portion of players) have had success installing the .Net
> Framework and running applications on it (excluding the WINE emulator). If
> no, the next question is: would you consider installing it to play an IF
> game?
The .NET runtime I've got came with Visual C++, so installation was no
problem. I wouldn't download a 20Mb monster from Microsoft to play an IF
game if I didn't already have it though, especially when there are loads
os TADS and Z-code games I've not played.
> If not, what is something that the IF author could do to make it
> easier for you to run?*
Not use .NET? :) If you use something that requires a huge runtime
download (God knows why it's so vast, even Java is smaller) then you'll
probably put lots of people off: I can't see any way around that.
David
Icedragon
<dwh...@gmail.com> wrote in message
news:1112283743.7...@l41g2000cwc.googlegroups.com...
>> I am interested to know, as an IF player, if you (well, in this case
>> the IF Usenet-based portion of players) have had success
>> installing the .Net Framework and running applications on it
>>(excluding the WINE emulator).
>
> I had the NET framework installed before the IFComp last year but it
> still didn't allow me to play your game properly. The cursor froze, the
> screen wouldn't react and no matter what keys I pressed I saw different
> letters appear on the screen. In the end, I deleted it.
I can sympathize that would be frustrating. I couldn't find any other user
with this particular problem, so this likely isn't a problem with the game
in particular. (probably either a problem with device drivers or a bug in
.Net). I received some e-mails about people not being able to get .Net
working (any application, much less the game), but almost none with trouble
concerning a crash or major failure of game itself once they had it loaded.
Those that did were all running under WINE, which is known to have
compatibility problems. I should also say that there were many people who
enjoyed the game and completed it.
>> If no, the next question is: would you consider installing it to
> play > an IF game?
>
> I have it installed already but if I didn't, would I install it for the
> sake of playing a game? No.
>
>> If not, what is something that the IF author could do to make it
>> easier for you to run?
>
> Try writing the game with a platform that already exists instead of
> creating your own. No one's impressed by a platform that doesn't work.
Point taken. I think that writing the platform is part of the fun; to know
that you could do it. While it is true that one may not have all of the
features of Adrift or Inform, learning is about trying, and I learned much.
I appreciate the feedback, this is really interesting stuff to hear.
Icedragon
>> IF
>> Usenet-based portion of players) have had success installing the .Net
>> Framework and running applications on it (excluding the WINE emulator).
>> If
>> no, the next question is: would you consider installing it to play an IF
>> game? If not, what is something that the IF author could do to make it
>> easier for you to run?*
>
>> * pre-empt obligatory lectures on Z-code/Inform
>
>>KILL THE FLY WITH THE AXE
> Which axe do you mean, the teensy axe or the atomic-powered supersonic
> planet-smashing axe?
>
>>TEENSY
> The fly expires.
>ATOMIC :)
Icedragon
> If not, what is something that the IF author could do to make it
>> easier for you to run?*
>
> As others have said, don't require me to install the .NET framework. I'm
> actually a little confused as to why this issue keeps cropping up with IF
> software. I have a fair variety of free, shareware, and commercial
> software installed on this machine, and none of it has ever required me to
> install this framework to run. Surely there is SOME way to package
> software developed with .NET that is transparent to the user?
You would think so, but unfortunately, there is no way that I know of. You
can't distribute a dll like you could with VB6. Java has a similar problem,
albeit the package is a lot smaller.
Icedragon
Jimmy Maher
I thought it was possible to in effect compile the Java runtime into the
executable, so that the user never even has to realize it was written in
Java. I'm no Java expert, though... Borland C++ Builder is the only
Windows programming environment I use. (Well, unless you count Inform,
which I am learning...)
Even if the above is not possible, the Java run-time is a much smaller
download, and most people have it installed anyway because it is fairly
commonly used for web apps. Plus, it's multi-platform. If you are
determined not to use Inform or TADs, you might want to consider whether
your project is adaptable to Java. From what I understand, Java is
quite easy to pick up if you already know C / C++.
Jimmy
ChicagoDave
will respond are generally against .NET and/or don't know enough about
it to really comment. And if you change the topic to Mono
(cross-platform version of .NET), they will still not respond.
If you want to create something in .NET and create something
interesting, playable, and well-tested...then it's likely that people
will play it.
For anyone with Windows XP, .NET is usually already there. Anyone that
complains about installing the .NET Framework probably doesn't realize
that all it is is a bunch of dormant managed code API's that have no
executables and don't have any impact on the base OS at all.
Of course if your worried about losing 25mb of disk space, I
understand. Otherwise it's really not that big of a deal. The same
people will download x MP3's and not see anything wrong with the disk
space they use so to me, that's a specious argument.
This is really an OS religious issue. There is nothing fundamentally
wrong or dangerous in using or installing the .NET Framework. It's no
different than the Java runtime. Just a wee (by todays standards) bit
bigger.
You make a .NET game, I will be the first to play it.
See Also: http://www.ifsharp.org
David C.
David Thornley
ChicagoDave <david.c...@gmail.com> wrote:
>I think this is the wrong audience for these questions. The people that
>will respond are generally against .NET and/or don't know enough about
>it to really comment. And if you change the topic to Mono
>(cross-platform version of .NET), they will still not respond.
>
As far as being generally against .NET goes, what does it matter?
There's still the idea of downloading 20 MB or so to play one game.
>If you want to create something in .NET and create something
>interesting, playable, and well-tested...then it's likely that people
>will play it.
>
Maybe. In this community, many fewer than would play it if it were
in zcode or one of the TADS VMs.
Now, let me tell you another reason why I'm prejudiced against native-
code games.
Malware.
No version of Windows has decent security, so it's easy to write
programs that will mess up my computer big-time. This means that
I'm fussy about the free stuff I download and run. If it's not
from someplace I have reason to trust, I simply don't.
I have no a priori reason to trust you. I'm not saying that you
aren't scrupulous and honest, I'm saying I have no current reason
to believe you are.
>For anyone with Windows XP, .NET is usually already there. Anyone that
>complains about installing the .NET Framework probably doesn't realize
>that all it is is a bunch of dormant managed code API's that have no
>executables and don't have any impact on the base OS at all.
>
So you say. I am a lot less sanguine about installing Microsoft
software and its effects on my OS.
>Of course if your worried about losing 25mb of disk space, I
>understand. Otherwise it's really not that big of a deal. The same
>people will download x MP3's and not see anything wrong with the disk
>space they use so to me, that's a specious argument.
>
It's a cost-benefit thing. (Okay, I've never downloaded any MP3s,
so I may not be the best person to comment on this.) You're talking
about dozens of MB with no immediate purpose other than to play
one game. With 25 MB of MP3s, you presumably can listen to an awful
lot of songs. Moreover, downloading MP3s is sort of an incremental
thing, so that you can download 1 MB and enjoy that, then download
more.
>This is really an OS religious issue. There is nothing fundamentally
>wrong or dangerous in using or installing the .NET Framework. It's no
>different than the Java runtime. Just a wee (by todays standards) bit
>bigger.
>
As long as it's a separate step that somebody has to do in order to
play a game, it is a big deal.
Moreover, while .NET might not be dangerous, playing games that
require it is. One advantage of something like Inform and TADS
and Hugo and the like is that it's either very difficult (TADS 2)
or effectively impossible (zcode) to write any sort of malware
with it. I am willing to do it for the Comp games, since Stephen
goes to considerable lengths to screen them, but I'm not going to
download and play a game I don't trust. In my analysis, it's too
big a risk for too small a benefit.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Icedragon
"ChicagoDave" <david.c...@gmail.com> wrote in message
news:1112376316.3...@z14g2000cwz.googlegroups.com...
>I think this is the wrong audience for these questions. The people that
> will respond are generally against .NET and/or don't know enough about
> it to really comment. And if you change the topic to Mono
> (cross-platform version of .NET), they will still not respond.
It is useful in that it confirms what I saw from the IFComp 2004 and
provides some background. The scores for my game in the IFComp were
somewhat bimodal. Overall, about three times the number of people played
the average Z-code games as opposed to the Windows-only games. While it
might be feasible to support OSX, PocketPC and Palm by porting, personally
I'm not interested in producing anything for any Linux variant. Mono could
work on most of these platforms, which is good.
> If you want to create something in .NET and create something
> interesting, playable, and well-tested...then it's likely that people
> will play it.
> For anyone with Windows XP, .NET is usually already there. Anyone that
> complains about installing the .NET Framework probably doesn't realize
> that all it is is a bunch of dormant managed code API's that have no
> executables and don't have any impact on the base OS at all.
Absolutely true. The Java framework and the .Net framework have much in
common in this respect.
> Of course if your worried about losing 25mb of disk space, I
> understand. Otherwise it's really not that big of a deal. The same
> people will download x MP3's and not see anything wrong with the disk
> space they use so to me, that's a specious argument.
>
> This is really an OS religious issue. There is nothing fundamentally
> wrong or dangerous in using or installing the .NET Framework. It's no
> different than the Java runtime. Just a wee (by todays standards) bit
> bigger.
.Net supports similar security features as well. Again, they aren't very
different.
> You make a .NET game, I will be the first to play it.
Done. :) See IFComp 2004 "Getting Back To Sleep". The reason for this
thread was to ponder the next competition.
Icedragon
> programs that will mess up my computer big-time. This means that
> I'm fussy about the free stuff I download and run. If it's not
> from someplace I have reason to trust, I simply don't.
This is true of any of the current operating systems. There isn't anything
Windows-specific here. Malware runs on the Mac, Unix, BeOS, etc etc. All
of these operating systems support user-level accounts, and even guest
accounts. You are right to be fussy, there are many packages that silently
install spyware these days.
>>This is really an OS religious issue. There is nothing fundamentally
>>wrong or dangerous in using or installing the .NET Framework. It's no
>>different than the Java runtime. Just a wee (by todays standards) bit
>>bigger.
>>
> As long as it's a separate step that somebody has to do in order to
> play a game, it is a big deal.
The user inconvenience of installing something like this is apparently quite
large. But the question remains; consider the Java package. It is fairly
large, is required to run Java apps and must be downloaded specifically to
run them. Would you download the Java system to play an IF game? What is
the logical gap between Hugo and Java?
> Moreover, while .NET might not be dangerous, playing games that
> require it is. One advantage of something like Inform and TADS
> and Hugo and the like is that it's either very difficult (TADS 2)
> or effectively impossible (zcode) to write any sort of malware
> with it. I am willing to do it for the Comp games, since Stephen
> goes to considerable lengths to screen them, but I'm not going to
> download and play a game I don't trust. In my analysis, it's too
> big a risk for too small a benefit.
Then you're trusting the author of TADS, or Frotz, or whatever host you
choose to not have written any malware into it. On top of that, it has
already been shown that some of these tools had/have exploitable buffer
overruns in them which would allow you to execute anything on that machine.
By the same token, if enough time were spent, I'm sure you could find holes
in nearly every software package out there. Obviously it is more likely
with a native x86 program, since there is little security. But Java and
.Net support closed "sandbox" environments where you can prevent changes
outside the security zone, which should offer some level of safety.
samwyse
> Then you're trusting the author of TADS, or Frotz, or whatever host you
> choose to not have written any malware into it. On top of that, it has
> already been shown that some of these tools had/have exploitable buffer
> overruns in them which would allow you to execute anything on that machine.
I'm sorry, but which versions of these tools have had exploitable buffer
overruns? The Z-machine VMs that I've seens are sandboxed better than
Java or .NET could ever dream of being, and I'd imagine that the same is
true of the others. Some TADS interpreters could let the game call
compiled C code (external functions), but this feature was rarely useful
and has been removed.
Sophie Fruehling
>news:1112376316.3...@z14g2000cwz.googlegroups.com...
>> Of course if your worried about losing 25mb of disk space, I
>> understand. Otherwise it's really not that big of a deal.
I take it you are not on a slow dial-up connection. I'm not either
these days, thankfully, but I was at the time of last year's Comp,
and after downloading the huge competition package, I just didn't want
to spend more pay-per-minute online time to download an even larger
software package just to be able to play one single game.
>> This is really an OS religious issue. There is nothing fundamentally
>> wrong or dangerous in using or installing the .NET Framework. It's no
>> different than the Java runtime. Just a wee (by todays standards) bit
>> bigger.
If you are on dial-up, 10 Mb is a huge difference. Also, I need the
Java runtime for a few things, and I don't need the .Net framework at
all. (And I don't really care about what exactly it is if I don't
need it.)
Now, I'm not one to complain about having to install yet another
interpreter to play a game. But those interpreters usually come at a
reasonable size, and there are more than one or two games for each
of them. I also don't say you shouldn't write your games for .Net or
anything else, just don't expect that as many people will be able or
willing to play them as Z-code or Tads games. (And I think, some of
us do have "non-religious" arguments.)
David Kinder
> This is really an OS religious issue. There is nothing fundamentally
> wrong or dangerous in using or installing the .NET Framework.
You see, I don't see this as an ideological issue at all: to me it's
purely a practical issue. Developers may like things like .NET, Mono
and Java as it makes their lives easier, but too often they don't
consider whether it makes the user's life easier.
As a user, I don't care if the game was written with .NET, or Java,
or C, or PL/1, or whatever - I just want it to run, preferably in a
way I'm used to. If I have to poke around different websites to
install stuff from Microsoft or Sun, you (as a developer) have just
made my life harder, and I'll be very likely to give up, especially
if there are lots of other games I could be playing that won't give
me this headache.
Of course, as you say, if the game is good enough, and people whose
opinion I respect enthuse about it, I'll go make the effort. But the
chances of me doing that on the off chance the game is good are low.
David
Mike Roberts
>> Moreover, while .NET might not be dangerous, playing games that require
>> it is. One advantage of something like Inform and TADS and Hugo and the
>> like is that it's either very difficult (TADS 2) or effectively
>> impossible (zcode) to write any sort of malware with it.
>
> choose to not have written any malware into it.
Actually, no trust is required, as the complete source code for both of
those packages is publicly available. You're free to inspect the sources to
your satisfaction, and then install by building from the inspected sources.
> On top of that, it has already been shown that some of these tools
> had/have exploitable buffer overruns in them which would allow you to
> execute anything on that machine.
Really? I don't recall such a case with any of the major IF interpreters.
Reference, please.
--Mike
mjr underscore at hotmail dot com
Icedragon
"Mike Roberts" <mj...@hotmail.com> wrote in message
news:QrC3e.11784$zl.1...@newssvr13.news.prodigy.com...
Sure, here is an example. Given that most are written in C++ which prone to
overruns by design, it's more likely there are exploitable overruns than
not. Here is one example from rec.arts.int-fiction of a buffer overrun
(with all respect to David of course). I'm sure if you spend enough time
you'll be able to find one in almost any native-based application, including
Frotz, etc. I would grant that the Z-machine environment certainly lessens
the possibility of finding one.
Newsgroups: rec.arts.int-fiction
From: "David Kinder" <d.kin...@btinternetspamnothankyou.coè¡«>
Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
Local: Mon, Oct 18 2004 10:52 am
Subject: Re: [inform] minor compiler bug
> when I try to compile this (reduced) piece of code with inform 6.30 the
> compiler crashes. The "error" in my source is due to the missing ";" after
> the function name.
It's a buffer overrun in the compiler. It'll be fixed for the next
version - thanks for reporting it!
David
Andrew Plotkin
>
> Sure, here is an example. Given that most are written in C++ which prone to
> overruns by design, it's more likely there are exploitable overruns than
> not.
>
> From: "David Kinder" <d.kin...@btinternetspamnothankyou.co?m>
> Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
> Local: Mon, Oct 18 2004 10:52 am
> Subject: Re: [inform] minor compiler bug
>
> > version - thanks for reporting it!
Ah, no, that's a bug in the *compiler*. It would only affect someone
compiling malicious Inform source code. (Which is not a likely or
common case.) It could not affect game-players.
I'm not saying that Z-code interpreters are all well-sandboxed. Some
of them aren't, and I should know because I wrote them. But this
example does not support your contention.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Alexandre Owen Muniz
> Of course if your worried about losing 25mb of disk space, I
> understand. Otherwise it's really not that big of a deal. The same
> people will download x MP3's and not see anything wrong with the disk
> space they use so to me, that's a specious argument.
Most of the IF I play, I play on my PDA, which has a 256mb flash memory card. In that
context, 25mb is a lot. (I *did* put City of Secrets and a glulx terp on there, but even
that is an effort I might not have made if I hadn't paid for it and gotten the pretty
feelies.) Any MP3s and such that I may download, I keep on devices with multiple gb of
hard disk space, so that's not a fair comparison.
Owen
ChicagoDave
require it is."
This is fundamentally false. By default, the .NET security settings are
pretty strict. Any unknown application will get rights to execute and
save information to the sandbox area. If there was actually malicious
code in the .NET program (like changing file system things outside of
the sandbox) it would display a managed code security error and refuse
to execute the program. If the program tried to do some sort of piggy
back install, that too would go through the same managed code security
settings and fail.
Now, you can explicitly open up the .NET security client, select a .NET
application, then set it to Full Rights. This would be like downloading
a file to your linux machine, putting it in a publically available
directory, and then giving it root access. You would have to go way out
of your way to allow something like this and if you were only
downloading a game, it would never come up.
I'd also point out that if anyone ever released an IF game with
malware, they would be treated harshly by the community and the word
would spread so fast that a second person would never get hit by the
same dirty tricks.
The .NET framework allows developers to create safe and efficient
programs that _can_ be downloaded without worrying about hurting
someone's machine.
Ask a few of the original downloaders of my Visual Inform program what
they think of what can happen when things go wrong. I accidentally
disabled several systems with my installation program. In .NET, you
couldn't ever do that to someone's PC.
I see that as a good thing.
I agree that Microsoft has a bad track-record. But that's really mostly
related to Outlook, IE, and the older OS's. If you were running Windows
XP SP2 or Windows Server 2003, you'd have about as secure a system as
you can have. The footprint for security holes has been reduced to
almost nothing and in another year, it will diminish further. I think
people with assumptions about MS security from a year or two ago should
re-evaluate those assumptions.
I sympathize with anyone that has to suffer an initial download of the
.NET Framework. If you have an older PC, dial-up connection, or little
free diskspace, then clearly this is a barrier to you running a .NET
based program. But then again, those parameters probably prevent you
from doing a lot of things. Installing the .NET framework just gets
rolled into that list of restrictions.
David C.
Mike Roberts
>mjr:
>>"Icedragon":
>>> On top of that, it has already been shown that some of these tools
>>
>> Really? I don't recall such a case with any of the major IF
>> interpreters. Reference, please.
>
> Sure, here is an example. Given that most are written in C++ which prone
> to overruns by design, it's more likely there are exploitable overruns
> than not. Here is one example from rec.arts.int-fiction of a buffer
> overrun (with all respect to David of course). I'm sure if you spend
> enough time you'll be able to find one in almost any native-based
> application, including Frotz, etc.
>> It's a buffer overrun in the compiler. It'll be fixed for the next
>>version - thanks for reporting it!
That's a compiler, not an interpreter - that's not relevant to your claims.
And even if it were, a buffer overrun bug is not necessarily an
*exploitable* buffer overrun bug, and I see no evidence in the note you cite
that this one's exploitable. So, again, I'm curious what these cases are
where "it has been shown" that there's an exploitable buffer overrun in one
of the popular interpreters.
If all you're saying is "I'm sure exploitable bugs must exist" rather than
"it's been shown" that they exist, well, sure; I wouldn't claim that the
absence of known exploits proves the non-existence of same. But "I'm sure
they must exist" is a rather weaker claim than you first made.
samwyse
>>Reference, please.
>
> Sure, here is an example. Given that most are written in C++ which prone to
> overruns by design, it's more likely there are exploitable overruns than
> not.
Mike and Zorf have pointed out the error in your example; I'd like to
point out that none of the interpreters for which I've viewed the source
are written in C++. Virtual machines just aren't so complicated to
require an object-oriented design. VMs also tend to check for a lot of
things a bit more carefully than the average program, since an overrun
could clobber things on multiple levels of execution.
samwyse
> "Moreover, while .NET might not be dangerous, playing games that
> require it is."
>
> This is fundamentally false. By default, the .NET security settings are
> pretty strict. Any unknown application will get rights to execute and
> save information to the sandbox area. If there was actually malicious
> code in the .NET program (like changing file system things outside of
> the sandbox) it would display a managed code security error and refuse
> to execute the program. If the program tried to do some sort of piggy
> back install, that too would go through the same managed code security
> settings and fail.
What about the execution of potentially dangerous scriptable ActiveX
controls? Is an unknown application is allowed to activate controls
marked Safe for Scripting? If so, there's a problem. You can find a
partial list of dangerous controls here:
http://www.oreilly.com/catalog/malmobcode/chapter/ch11.html
Look for the section labeled "Malicious ActiveX Examples" about halfway
down the page.
ChicagoDave
ActiveX controls. That's why I have Norton Security lock them down.
Even Internet Explorer has the ability to turn off their execution. You
can set all ActiveX controls to simply not run without any prompting.
You can set them to run after being prompted. Or if you're a fool, you
can set them to run all the time.
But remember, ActiveX controls are 10 year old technology. No one is
suggesting creating anything in ActiveX.
And more to the point. The manner in which an ActiveX control executes
and the manner in which a .NET program or control executes are entirely
two separate architectures. One has no security and one has security
threaded through every aspect of its nature.
David C.
Icedragon
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:d2nbv1$o6v$1...@reader1.panix.com...
> Here, Icedragon <icenetRE...@icedragon.net> wrote:
>>
>> Sure, here is an example. Given that most are written in C++ which prone
>> to
>> overruns by design, it's more likely there are exploitable overruns than
>> not.
>>
>> Newsgroups: rec.arts.int-fiction
>> From: "David Kinder" <d.kin...@btinternetspamnothankyou.co?m>
>> Date: Mon, 18 Oct 2004 17:52:56 +0000 (UTC)
>> Local: Mon, Oct 18 2004 10:52 am
>> Subject: Re: [inform] minor compiler bug
>>
>> > It's a buffer overrun in the compiler. It'll be fixed for the next
>> > version - thanks for reporting it!
>
> Ah, no, that's a bug in the *compiler*. It would only affect someone
> compiling malicious Inform source code. (Which is not a likely or
> common case.) It could not affect game-players.
Yes, and it says "compiler" right in the quoted e-mail. I hesitate to
accept anyone claiming any application is 100% secure.
> I'm not saying that Z-code interpreters are all well-sandboxed. Some
> of them aren't, and I should know because I wrote them.
Agreed, and this is the point. Yet some people are saying there is no
Z-code that can overrun them.
> But this
> example does not support your contention.
My original contention: "it has already been shown that some of these tools
had/have exploitable buffer overruns in them"
Compiler == tool. If the tools for the platform have overruns, it's likely
the environments do too.
Icedragon
> the source are written in C++. Virtual machines just aren't so
> complicated to require an object-oriented design. VMs also tend to check
> for a lot of things a bit more carefully than the average program, since
> an overrun could clobber things on multiple levels of execution.
Yes, it's another good reason to use .Net and Java. Neither are prone to
buffer overruns for exactly the reasons you state; all objects on the stack
and heap are fully checked, including bounds and length. They also share
the ability to used sandbox security zones.
A list of interpreters used in IFComp 2004 and their source language:
WinFrotz - C/C++ mix
Frotz - C/C++ mix
Adrift - not open source? (can't verify security, could have same malware)
Hugo - C/C++ mix
ALAN - C++
TADS 2.x - C++
It is clear from this list that C++ is it, and this is what the vast
majority of players are running. Which interpreters are you talking about
that aren't in C++ and used in the competition? Examples?
Let's get back to the original point here though. It was that some people
might hesitate to run .Net or Java code on their machine because it's
somehow less safe or secure. The coup de grace, though is that most users
will run .exe installer programs that come with game packages, any of which
could be set up to execute a task on your machine, or install a back door
for later attacks. At that point, it really doesn't matter which system
you're using.
The nugget is that security should not be the major consideration in
determining the safety of running the games, you are vulnerable in varying
degrees _unless_ all you ever do is load and run .z files in an interpreter
that you code-reviewed and compiled from source yourself. And since you can
sandbox .Net, it is less of a concern than say, native-windows competition
entries or Adrift (assuming it's not open source).
samwyse
Well, you avoided directly answering my main question: "Is an unknown
application is allowed to activate controls marked Safe for Scripting?"
I don't use .NET, so I don't know the answer to that. Based on past
experience, I expect that MS hasn't re-implemented their entire
architecture in trusted code, so I further expect that the answer to my
question is 'by default, yes'. The rest of this post will assume that
this is the answer.
I understand that you can set all ActiveX controls to not run without
prompting, but a lot of those controls are used frequently in a lot of
different places; requiring prompting for everything isn't a realistic
option. This is why MS allows different controls to be flagged with
different levels of security, so that some "trusted" controls can be
invoked without prompts. "Safe for scripting" indicates that a control
doesn't do anything malicious. Unfortunately, there are some controls
that are marked as safe, but aren't. There are also controls that
aren't marked as safe, but are signed by a third party and are allowed
to run after prompting. Unfortunately, there are some controls that, as
a "convenience" to the user, will then modify the Windows registry to
indicate that *everything* signed by that third party can be trusted in
the future.
Both of these "features" make me unwilling to use ActiveX for anything,
and leave me nervous about anything that uses ActiveX under the covers.
(And yes, I have stopped using IE and Outlook on my computer in favor
of Firefox and Thunderbird. I also try to avoid using the built-in help
system in favor of Google search.) And that's why I don't have .NET
installed on my PC.
Andrew Plotkin
>
> My original contention: "it has already been shown that some of these tools
> had/have exploitable buffer overruns in them"
>
> Compiler == tool. If the tools for the platform have overruns, it's likely
> the environments do too.
You're just throwing around generalizations now.
The discussion was originally about possible security problems caused
by downloading and playing IF games of various forms.
The risks of IF *development* are a completely different category and,
despite your claim, there are no real implications you can draw from
one to the other. Different code base, different languages, different
tasks.
Jimmy Maher
> This is really an OS religious issue. There is nothing fundamentally
> wrong or dangerous in using or installing the .NET Framework. It's no
> different than the Java runtime. Just a wee (by todays standards) bit
> bigger.
I think this is turning into a religious, or more specifically
emotional, issue, but with all due respect I think you need to look at
your own reactions before criticizing others. I've been lurking here on
and off for a few years, and this is what I've noticed...
You feel that Microsoft's products in general, and particularly .NET,
are actually pretty damn good, and that they get a decidedly bum rap
here, and in hacker circles in general, due to an irrational
anti-Microsoft bias. I won't get into arguing the merits of that
contention, other than to say that I do see some merit to it.
Personally, Windows XP works pretty well for me as a desktop OS, and
when I've dabbled with Linux on the desktop I've always found it to be a
slow, ugly, unwieldy beast, and found most of the GUI applications
available to be clones of better Windows apps. (Linux as a server is
another matter, however. I'm baffled why anyone would voluntarily
choose a Windows-based over a Unix-based solution in that area...)
With that in mind, when we back up and look at the post that started
this thread, what was Ice Dragon really asking? He was saying that he
intended to write yet another home-grown parser from scratch, and asking
the community if they would be willing to install a substantial software
package to play the resulting game. As everyone knows, home-grown
parsers suck utterly 99% of the time, and even the 1% that don't are
generally not up to the level of Inform or TADs. If Ice Dragon had said
that he intended to write a new parser in C, or Java, or BASIC for that
matter, would you have responded that he should in effect not be
discouraged by the rest of the community, and that you would be the
"first to play" the resulting game? Somehow, I think not.
I submit that you were motivated to respond in such a way not because
you think programming from scratch is a good route to creating a game,
but because the idea of said game being programmed in .NET immediately
interested you. The idea of ANYTHING being programmed in .NET
interested you, because you want to see it survive and prosper.
Personally, I'm not opposed to or supportive of .NET. It's simply a
tool, one which I know very little about. If lots of software that I
want to run starts requiring this framework, I will doubtless shrug my
shoulders and download the framework.
All I'm saying is that, for IF, developing a game from scratch, in .NET
or any other environment, is probably not the best choice. If Ice
Dragon wishes to design his own parser for the intellectual challenge,
fine. That's as good a reason as any to do anything. He should
understand, though, that it will probably take him years of work just to
reach the level that Inform and TADs are at today.
In short: People are not reluctent to download this framework because of
some hatred of .NET, or Microsoft, or both. They are reluctent because
they suspect, based on much previous experience, that the game they are
downloading it for will almost certainly not be worth the effort.
Jimmy
samwyse
>>I'd like to point out that none of the interpreters for which I've viewed
>>the source are written in C++. Virtual machines just aren't so
>>complicated to require an object-oriented design. VMs also tend to check
>>for a lot of things a bit more carefully than the average program, since
>>an overrun could clobber things on multiple levels of execution.
>
>
> Yes, it's another good reason to use .Net and Java. Neither are prone to
> buffer overruns for exactly the reasons you state; all objects on the stack
> and heap are fully checked, including bounds and length. They also share
> the ability to used sandbox security zones.
No, it's not a reason to *favor* .NET or Java; the same arguments apply
to all of them, so it is a draw.
> A list of interpreters used in IFComp 2004 and their source language:
> WinFrotz - C/C++ mix
> Frotz - C/C++ mix
Where are you getting your Frotz source? The copy that I have is
written in C, only. I haven't checked, so the headers might make
provision for use by C++, but that doesn't make the code any less pure.
I expect that WinFrotz uses C++ so that it can access the Windows GUI,
but the VM is just plain Frotz and that is pure C and that means that a
program running in the VM won't have access to any C++ insecurities that
hypothetically may exist.
> Adrift - not open source? (can't verify security, could have same malware)
> Hugo - C/C++ mix
> ALAN - C++
> TADS 2.x - C++
The copy of the TADS common VM that I just downloaded appears to be pure
C code. I haven't checked the others, but I'd imagine that the
situation is the same as with WinFrotz; C++ may be used for interfacing
to the GUI on Windows systems, but the VMs themselves are all written in
straight C for reasons of portability.
> It is clear from this list that C++ is it, and this is what the vast
> majority of players are running. Which interpreters are you talking about
> that aren't in C++ and used in the competition? Examples?
It is clear that you don't know what you're talking about.
> Let's get back to the original point here though. It was that some people
> might hesitate to run .Net or Java code on their machine because it's
> somehow less safe or secure. The coup de grace, though is that most users
> will run .exe installer programs that come with game packages, any of which
> could be set up to execute a task on your machine, or install a back door
> for later attacks. At that point, it really doesn't matter which system
> you're using.
Quite true, but I don't see many cross-platform systems that use .exe
installer packages. The formats that I generally see available for
download are base files, or occasionally .zip files containing a
collection of games.
> The nugget is that security should not be the major consideration in
> determining the safety of running the games, you are vulnerable in varying
> degrees _unless_ all you ever do is load and run .z files in an interpreter
> that you code-reviewed and compiled from source yourself.
Actually, I load and run .z files on my Palm PDA.
> And since you can
> sandbox .Net, it is less of a concern than say, native-windows competition
> entries or Adrift (assuming it's not open source).
I don't run native-windows competition entries, period. I don't trust
native code that I find on the Internet, at least until it has sat in my
incoming files folder for a few months without other people reporting
problems. Yes, I'm a bit behind the times, but I don't have any malware
installed, either.
samwyse
> In short: People are not reluctent to download this framework because of
> some hatred of .NET, or Microsoft, or both. They are reluctent because
> they suspect, based on much previous experience, that the game they are
> downloading it for will almost certainly not be worth the effort.
Amen, brother!
Icedragon
>> WinFrotz - C/C++ mix
>> Frotz - C/C++ mix
>
> Where are you getting your Frotz source? The copy that I have is written
> in C, only. I haven't checked, so the headers might make provision for
> use by C++, but that doesn't make the code any less pure. I expect that
> WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
> just plain Frotz and that is pure C and that means that a program running
> in the VM won't have access to any C++ insecurities that hypothetically
> may exist.
C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
problems in these languages both come from the use of pointers, strings,
arrays and memory buffers without rules enforcement, and you could almost
see it as a design flaw.
>> Adrift - not open source? (can't verify security, could have same
>> malware)
>> Hugo - C/C++ mix
>> ALAN - C++
>> TADS 2.x - C++
>
> The copy of the TADS common VM that I just downloaded appears to be pure C
> code. I haven't checked the others, but I'd imagine that the situation is
> the same as with WinFrotz; C++ may be used for interfacing to the GUI on
> Windows systems, but the VMs themselves are all written in straight C for
> reasons of portability.
>
>> It is clear from this list that C++ is it, and this is what the vast
>> majority of players are running. Which interpreters are you talking
>> about that aren't in C++ and used in the competition? Examples?
>
> It is clear that you don't know what you're talking about.
It's clear you don't. They are all in C/C++ with the exception of Adrift.
Where are the other interpreters that are non-C++? If you were basing your
logic on the distinction between C and C++, it's erroneous.
Stephen Granade
> A list of interpreters used in IFComp 2004 and their source language:
> WinFrotz - C/C++ mix
> Frotz - C/C++ mix
> Adrift - not open source? (can't verify security, could have same malware)
> Hugo - C/C++ mix
> ALAN - C++
> TADS 2.x - C++
TADS 2, the base Frotz distribution, the base ALAN interpreter, and
the base HUGO interpreter are all written in C, not C++.
> It is clear from this list that C++ is it, and this is what the vast
> majority of players are running.
Here I think you have inadvertently hit upon the big stumbling block
for a single-shot .NET program: most people aren't running it. As it
stands, most everyone will have a z-code interpreter. Many will have a
TADS interpreter and a Hugo interpreter. That gives games written in
those languages a two-fold advantage. One, playing such a game
involves downloading just the game data, not a new interpreter. Your
hypothetical .NET game requires a download of the entire engine, and
quite probably a download of the .NET runtime. This is not a
zero-height barrier. Two, the common language interpreters are used by
a lot of people. So far no nasty bugs or malware have shown up from
them. Your .NET game is an unknown quantity, and could have all kinds
of nasty payloads attached to it.
Stephen
--
Stephen Granade
stephen...@granades.com
samwyse
>>>A list of interpreters used in IFComp 2004 and their source language:
>>>WinFrotz - C/C++ mix
>>>Frotz - C/C++ mix
>>
>>Where are you getting your Frotz source? The copy that I have is written
>>in C, only. I haven't checked, so the headers might make provision for
>>use by C++, but that doesn't make the code any less pure. I expect that
>>WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
>>just plain Frotz and that is pure C and that means that a program running
>>in the VM won't have access to any C++ insecurities that hypothetically
>>may exist.
>
> C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
> problems in these languages both come from the use of pointers, strings,
> arrays and memory buffers without rules enforcement, and you could almost
> see it as a design flaw.
Let me remind you of your original statement: "Given that most are
written in C++ which prone to overruns by design, it's more likely there
are exploitable overruns than not." I have pointed out that the VMs
themselves are written in C, not C++, so you have apparently choosen to
refashion your argument.
That's OK, I've spent some time inside the Frotz engine and it is pretty
well designed; in fact VMs generally go out of their way to enforce
rules on the bytecodes being simulated. For example, most buffer
overruns in C are caused by use of things like sprintf, which isn't used
anywhere in the VM proper. Also, every access to the VM memory is
checked to make sure that you aren't accidentally (or purposefully)
accessing past the "end of RAM" and viewing (or modifying) the
interpreter itself.
>>>It is clear from this list that C++ is it, and this is what the vast
>>>majority of players are running. Which interpreters are you talking
>>>about that aren't in C++ and used in the competition? Examples?
>>
>>It is clear that you don't know what you're talking about.
>
> It's clear you don't. They are all in C/C++ with the exception of Adrift.
> Where are the other interpreters that are non-C++? If you were basing your
> logic on the distinction between C and C++, it's erroneous.
Read your two statements again: "It is clear from this list that C++ is
it" and "They are all in C/C++". Do you see that you are changing your
own words? You started this by claiming that C++ is "prone to overruns
by design", I've called you on that statement, and now you want to say
that you really meant that there's no difference between C and C++.
Come back when you figure out what it is that you're talking about,
because I'm unable to figure it out on my own.
Icedragon
>>>>WinFrotz - C/C++ mix
>>>>Frotz - C/C++ mix
>>>
>>>Where are you getting your Frotz source? The copy that I have is written
>>>in C, only. I haven't checked, so the headers might make provision for
>>>use by C++, but that doesn't make the code any less pure. I expect that
>>>WinFrotz uses C++ so that it can access the Windows GUI, but the VM is
>>>just plain Frotz and that is pure C and that means that a program running
>>>in the VM won't have access to any C++ insecurities that hypothetically
>>>may exist.
>>
>> C is even slightly worse. ANSI C is mostly a subset of ANSI C++. The
>> problems in these languages both come from the use of pointers, strings,
>> arrays and memory buffers without rules enforcement, and you could almost
>> see it as a design flaw.
>
> Let me remind you of your original statement: "Given that most are
> written in C++ which prone to overruns by design, it's more likely there
> are exploitable overruns than not." I have pointed out that the VMs
> themselves are written in C, not C++, so you have apparently choosen to
> refashion your argument.
C is a subset of C++. Every one of the source packages for those in the
list that say "C++" contain .cpp files, and the _package_ contains it. You
are reducing the discussion to the parts you see as the VM. If they contain
the files, they typically use some code. Insecurities can come from trying
to format data for display through MFC.
> That's OK, I've spent some time inside the Frotz engine and it is pretty
> well designed; in fact VMs generally go out of their way to enforce rules
> on the bytecodes being simulated. For example, most buffer overruns in C
> are caused by use of things like sprintf, which isn't used anywhere in the
> VM proper. Also, every access to the VM memory is checked to make sure
> that you aren't accidentally (or purposefully) accessing past the "end of
> RAM" and viewing (or modifying) the interpreter itself.
Also: off-by-one errors in length or index, pointer arithmetic mistakes, and
more. No programmer plans his/her bugs, and if we could see them by
reviewing the source, all software would be bug free.
>>>>It is clear from this list that C++ is it, and this is what the vast
>>>>majority of players are running. Which interpreters are you talking
>>>>about that aren't in C++ and used in the competition? Examples?
>>>
>>>It is clear that you don't know what you're talking about.
>>
>> It's clear you don't. They are all in C/C++ with the exception of
>> Adrift. Where are the other interpreters that are non-C++? If you were
>> basing your logic on the distinction between C and C++, it's erroneous.
>
> Read your two statements again: "It is clear from this list that C++ is
> it" and "They are all in C/C++". Do you see that you are changing your
> own words? You started this by claiming that C++ is "prone to overruns by
> design", I've called you on that statement, and now you want to say that
> you really meant that there's no difference between C and C++. Come back
> when you figure out what it is that you're talking about, because I'm
> unable to figure it out on my own.
This is fluff. I recommend you do some reading on C and C++ and understand
the differences and similarities, because they are synonymous for this
purpose.
I disagree with you that C is somehow more safe or superior to C++,
considering C++ supports C code. That said, we agree to disagree, let's be
done with this.
Icedragon
"Stephen Granade" <stephen...@granades.com> wrote in message
news:m0u0mnr...@granades.com...
> "Icedragon" <icenetRE...@icedragon.net> writes:
>
>> A list of interpreters used in IFComp 2004 and their source language:
>> WinFrotz - C/C++ mix
>> Frotz - C/C++ mix
>> Adrift - not open source? (can't verify security, could have same
>> malware)
>> Hugo - C/C++ mix
>> ALAN - C++
>> TADS 2.x - C++
>
> TADS 2, the base Frotz distribution, the base ALAN interpreter, and
> the base HUGO interpreter are all written in C, not C++.
From the TADS website:
"The source code for TADS, written in C and C++, is freely available, so
even if an interpreter isn't already available for your system of choice,
you could port it there. The TADS source code was originally designed for
easy portability and has had its portability honed with years of experience
on a wide range of systems."
http://www.tads.org/tads.htm
Maybe the core components are C, I don't claim to have sifted through the
source code. But the documentation says it is. And it doesn't matter
either way, anyhow.
>> It is clear from this list that C++ is it, and this is what the vast
>> majority of players are running.
>
> Here I think you have inadvertently hit upon the big stumbling block
> for a single-shot .NET program: most people aren't running it. As it
> stands, most everyone will have a z-code interpreter. Many will have a
> TADS interpreter and a Hugo interpreter. That gives games written in
> those languages a two-fold advantage. One, playing such a game
> involves downloading just the game data, not a new interpreter. Your
> hypothetical .NET game requires a download of the entire engine, and
> quite probably a download of the .NET runtime. This is not a
> zero-height barrier. Two, the common language interpreters are used by
> a lot of people. So far no nasty bugs or malware have shown up from
> them. Your .NET game is an unknown quantity, and could have all kinds
> of nasty payloads attached to it.
Yes, but what ChicagoDave and I were getting at is that .Net can be set to
run in a security zone where it cannot deploy nasty payloads. An example:
run a .Net executable directly from a webpage (ie. via a link) and you fall
into the web security zone, which prohibits file access on the client
machine.
Along the lines of what you are saying, however, most people probably don't
know enough to be able to set up this kind of security when running the code
and will expose themselves to the nasty payloads.
samwyse
> "Stephen Granade" <stephen...@granades.com> wrote in message
> news:m0u0mnr...@granades.com...
>
>>"Icedragon" <icenetRE...@icedragon.net> writes:
>>
>>
>>>A list of interpreters used in IFComp 2004 and their source language:
>>>WinFrotz - C/C++ mix
>>>Frotz - C/C++ mix
>>>Adrift - not open source? (can't verify security, could have same
>>>malware)
>>>Hugo - C/C++ mix
>>>ALAN - C++
>>>TADS 2.x - C++
>>
>>TADS 2, the base Frotz distribution, the base ALAN interpreter, and
>>the base HUGO interpreter are all written in C, not C++.
>
>
> From the TADS website:
> "The source code for TADS, written in C and C++, is freely available, so
> even if an interpreter isn't already available for your system of choice,
> you could port it there. The TADS source code was originally designed for
> easy portability and has had its portability honed with years of experience
> on a wide range of systems."
> http://www.tads.org/tads.htm
>
> Maybe the core components are C, I don't claim to have sifted through the
> source code. But the documentation says it is. And it doesn't matter
> either way, anyhow.
I have sifted through the source code, and, actually, it does matter.
C++ is built on top of C, so by your arguments C++ may add insecurities
to what are already present in C. A VM, OTOH, is often written in a
restricted subset of C. For example, C++ allows the use of 'sprintf',
which is insecure; however a simple grep of the source indicates that
this function is not used by Frotz.
>>>It is clear from this list that C++ is it, and this is what the vast
>>>majority of players are running.
>>
>>Here I think you have inadvertently hit upon the big stumbling block
>>for a single-shot .NET program: most people aren't running it. As it
>>stands, most everyone will have a z-code interpreter. Many will have a
>>TADS interpreter and a Hugo interpreter. That gives games written in
>>those languages a two-fold advantage. One, playing such a game
>>involves downloading just the game data, not a new interpreter. Your
>>hypothetical .NET game requires a download of the entire engine, and
>>quite probably a download of the .NET runtime. This is not a
>>zero-height barrier. Two, the common language interpreters are used by
>>a lot of people. So far no nasty bugs or malware have shown up from
>>them. Your .NET game is an unknown quantity, and could have all kinds
>>of nasty payloads attached to it.
>
> Yes, but what ChicagoDave and I were getting at is that .Net can be set to
> run in a security zone where it cannot deploy nasty payloads. An example:
> run a .Net executable directly from a webpage (ie. via a link) and you fall
> into the web security zone, which prohibits file access on the client
> machine.
What do you think that the .NET CLR is written in? Before there was a
C# compiler, it was written in C and C++. Some or all of it may have
been rewritten in C# since then, but if so then it has to be using
unchecked code. By your own admissions, this is a source of possible
bugs. Java is in the same boat, and many bugs have been found that
violate the security model; these bugs have been fixed, but there is
nothing magic that could have kept them from being there in the first
place. .NET certainly has similar bugs, and (IMHO) it hasn't been
around long enough for them all to have been found.
The Z-machine has been around longer than .NET and Java put together,
and is built in the same way. All VM's implement some sort of security
zone, if for no reason that to prevent badly written byte code fom
clobbering the interpreter, and the Z-machine's has been tested for a
long time (I suspect, longer than you've been alive). I trust it a lot
more than anything written in code that MS keeps hidden from the public,
because I know MS's record on writing secure code.
And yes, you *can* run Z-code directly from a web page (at least using
Firefox and the Gnusto extension (which is written in Javascript, not C)).
Matthew Russotto
Icedragon <icenetRE...@icedragon.net> wrote:
>
>
>Sure, here is an example. Given that most are written in C++ which prone to
>overruns by design, it's more likely there are exploitable overruns than
>not.
Now there's the smell of horse manure.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Matthew Russotto
Icedragon <icenetRE...@icedragon.net> wrote:
>
>My original contention: "it has already been shown that some of these tools
>had/have exploitable buffer overruns in them"
>
>Compiler == tool. If the tools for the platform have overruns, it's likely
>the environments do too.
You'll never find a more wretched hive of specious reasoning.
Because Inform had a buffer overflow (not proven exploitable), ZPlet
must also? Even though they are written by completely different
people, in totally different languages, and accomplish completely
different things?
If I thought you'd understand, I'd explain exactly why it's more
likely for Inform to have a buffer overflow than a given Z-Machine
interpreter. Or why the usual reasons given for the exploitability of
C and C++ programs are largely inapplicable to a Z-machine
interpreter. Or why a Z-machine interpreter written in C with an eye
to security would likely be safer than any given .NET program, in
terms of buffer overflows. But if you could understand, you likely
wouldn't need the explanation, so I'll save my breath.
Matthew Russotto
Icedragon <icenetRE...@icedragon.net> wrote:
>It's clear you don't. They are all in C/C++ with the exception of Adrift.
>Where are the other interpreters that are non-C++? If you were basing your
>logic on the distinction between C and C++, it's erroneous.
Oh, OK, I WILL waste my breath. From the point of view of certain
kinds of security, C is _safer_ than C++, because so much goes on behind the
scenes in C++, particularly constructor and destructor calls.
ChicagoDave
The security for ActiveX controls is not the same security as for .NET.
Any of the scenarios you point out for ActiveX security issues is not
relevent to .NET. The .NET security checking looks at the actual code
and determines what is happening. If the code is trying to do something
that hasn't been explicitly allowed, a security error will prevent the
code from executing. Let's be clear about this:
1. Load .NET program into memory as a file
2. Read byte code operations
3. For each operation
4. Check if operation is allowed
5. If not allowed then
6. throw security exception
7. end if
8. next
9. run program
You can't get to "9. run program" unless every operation within the
code passes security.
In the ActiveX world, the code isn't checked. there's a bit in the file
that says it's trused in entirety. No one is arguing that this is a
crappy, flawed, and mis-used architecture.
I'm saying .NET doesn't do things that way.
David C.
ChicagoDave
focused on the .NET parts and less about what sort of game would
result.
I am absolutely a .NET evangelist. If you want to include Mono in there
you can. I just think the platform has a lot to offer.
If we're focusing on the idea that someone will build a new IF platform
in .NET, I support that as well and will _not_ assume it will suck and
instead encourage people to strive to do better.
David C.
PJ
I agree with you 100%. All this carping about security is somewhat
silly. The next great worldwide computer Ebola is not likely to come
out of the IF community, no matter what language people are developing
IF in. And as you point out, .NET has the appropriate security
features built into the framework.
The OP's original question(s), however, relatd to whether folks had
success running applications under .NET, and whether they would
download the framework if offered to chance to play a .NET game.
A .NET IF development platform is a different thing. I think many
folks on this site are (reflexively) anti-Microsoft and they are also
mostly content with Inform, TADS, and the occasional Hugo game. But if
someone came along with a new IF platform based on .NET, I think the
proof would be in the pudding. Is it better than Inform, TADS3, etc.?
If not, why bother?
I personally see room for improvement and would like a real visual
development environment for IF, but if it's not better than the
existing platforms (and you can define better in many ways, I guess),
then it seems unlikely that most of the existing crew of IF authors
will bother with it. If they don't, then the value of downloading the
.NET framework just for one game is, as many have pointed out, not very
high.
Be that as it may, I think the OP should give it a whirl, if that's
what he's looking to do. I don't share the naysayers' problems with a
"homegrown" IF language. Haven't they all basically been homegrown,
going back to ZIL and the z-machine? Given that the source is available
for the major languages now, using them and their libraries as a
starting point for the minimum requirements of a next-gen language
would seem to have great potential.
PJ
Richard Bos
> C is a subset of C++.
Ok, now we _know_ you don't know what you're talking about.
Richard
Jimmy Maher
> If we're focusing on the idea that someone will build a new IF platform
> in .NET, I support that as well and will _not_ assume it will suck and
> instead encourage people to strive to do better.
Okay, fair enough. I do think it worth noting, however, that the
original poster never proposed creating a new IF platform per se, only a
one-off game. The idea of a new development environment to rival TADs
and Inform is yours, not his. I wish you the best of luck should you
decide to pursue this goal.
Should you create such an environment, I will evaluate it on its merits,
and if it offers something that TADs and Inform do not, I may just make
it my language of choice (says the dude who has never finished work on
any IF game, in any language).
I hold to my original assertion, though, that any one-off game written
in a general-purpose programming language, even if it's the best
general-purpose language in the world, is unlikely to compare very well
with the best of what this community has so far created.
Jimmy
Jimmy Maher
> I agree with you 100%. All this carping about security is somewhat
> silly. The next great worldwide computer Ebola is not likely to come
> out of the IF community, no matter what language people are developing
> IF in. And as you point out, .NET has the appropriate security
> features built into the framework.
For what it's worth, I agree as well, which is why I never got involved
in that rather silly line of discussion.
> I personally see room for improvement and would like a real visual
> development environment for IF, but if it's not better than the
> existing platforms (and you can define better in many ways, I guess),
> then it seems unlikely that most of the existing crew of IF authors
> will bother with it. If they don't, then the value of downloading the
> .NET framework just for one game is, as many have pointed out, not very
> high.
I'm learning Inform right now, and the language is absolutely screaming
for a good visual environment similar to Borland's Delphi and C++
Builder. (There may be other environments just as good, mind you.
Those are just the products I am familiar with.)
I can envision exactly how it would work, but can also unfortunately
envision the staggering amount of effort developing such a tool would
entail. I want it bad enough, though, that I'm actually thinking about
rolling up my sleeves and giving it a go.
> Be that as it may, I think the OP should give it a whirl, if that's
> what he's looking to do. I don't share the naysayers' problems with a
> "homegrown" IF language. Haven't they all basically been homegrown,
> going back to ZIL and the z-machine? Given that the source is available
> for the major languages now, using them and their libraries as a
> starting point for the minimum requirements of a next-gen language
> would seem to have great potential.
Give me a professional-grade visual environment for Inform that requires
.NET, and I will run not walk to download this framework of yours.
Alternately, give me another language as powerful as Inform, only with
an integrated visual IDE, and I will be all over .NET there too.
Jimmy
David Alex Lamb
Last time I looked, Stroustrup claimed as a design goal keeping any C program
as a legal C++ program. So why doesn't that make C a subset?
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...)
Andrew Plotkin
> In article <4251bd55...@news.xs4all.nl>,
> Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
> >"Icedragon" <icenetRE...@icedragon.net> wrote:
> >
> >> C is a subset of C++.
> >
> >Ok, now we _know_ you don't know what you're talking about.
>
> Last time I looked, Stroustrup claimed as a design goal keeping any C program
> as a legal C++ program. So why doesn't that make C a subset?
Because he didn't achieve the goal. :)
Michael Coyne
> Last time I looked, Stroustrup claimed as a design goal keeping any C
> program as a legal C++ program. So why doesn't that make C a subset?
That doesn't mean he achieved it.
Try this:
char acStringLit[6] = "Inform";
That statement is legal in C and illegal in C++.
Michael
ChicagoDave
Ice - Clearly you need to review your C and C++ history. C and C++
share similarities, but are not the same language and one is not a
subset of the other. You may be able to get some non C programmers to
buy your statements, but the people that frequent this newsgroup have
been using both languages since before CRT's.
Everyone else - this is a newibie. Treat him as such. Take the boxing
gloves off and educate him.
Ice - we want to play nice, but you're not making it easy. Back off.
You're not going to make many friends by attacking the standards of the
IF development community. TADS and Inform are written in C. That may
seem insecure to you and to many on the surface, but this isn't the
right place or way to address the issue. Read through the available
source code and if you find a specific security problem, let the
maintainer know and I'm sure it will be addressed appropriately.
Everyone else - this is a newbie.
David C.
PJ
> I'm going to step in here and ask that we all knock it off.
A good idea. Let's summarize a few salient points, first, however:
-- C and C++ are not the same language. However, C code, if written
carefully not to conflict with the requirements of C++, can compile to
a C++ compiler. Does that make it a subset of C++? Who knows, who
cares?
-- Neither C nor C++ were written "before CRTs". C came out in the
early 70s, became an ANSI standard in the early 80s. C++ came out
circa 1985, and was written to be a "superset" encompassing C, but as
many have noted, didn't fully achieve that. There is also an ANSI
standard now for C++, and many documents demonstrating the
links/compatabilities between the two languages. Nobody is winning
this argument, so we may as well quit on it.
-- Arguing about the security of C, C++ or any of the current set of IF
compilers is kind of ridiculous. Does anyone honestly think the Hong
Kong/Taiwan/Shanghai bug-writing/bug-fixing shops are trying to infect
the world using IF as a vector? In short, "No."
-- Any discussion of this sort invokes the rabid anti-Microsoft bias of
many folks on this news group. I sympathize. But Microsoft and .NET
aren't going away. May as well accept it, particularly as C#.NET is
pretty cool anyway.
-- Icedragon wants to write games in .NET. Applause. But he will get
no kudos from the community unless he writes a full .NET IF development
platform and distributes it broadly enough that somebody else starts
using it. That means it also has to be good -- probably better, in
fact -- than the existing IF languages. Possible, but not necessarily
probable.
-- Do we all have too much time on our hands? Apparently so. ;)
PJ
PJ
PJ wrote:
> -- Arguing about the security of C, C++ or any of the current set of
IF
> compilers is kind of ridiculous. Does anyone honestly think the Hong
> Kong/Taiwan/Shanghai bug-writing/bug-fixing shops are trying to
infect
> the world using IF as a vector? In short, "No."
Replace bug-writing/bug-fixing with virus-writing/virus-fixing.
Too much time on my hands, but not enough to edit my thoughts,
apparently.
PJ
Matthew Russotto
It's illegal in C99 as well, I think. And will garner a warning in
many C dialects.
Richard Bos
> In article <pan.2005.04.05...@mtsDOT.net>,
> Michael Coyne <coy...@mtsDOT.net> wrote:
> >On Tue, 05 Apr 2005 00:10:41 +0000, David Alex Lamb said to the parser:
> >
> >> Last time I looked, Stroustrup claimed as a design goal keeping any C
> >> program as a legal C++ program. So why doesn't that make C a subset?
> >
> >That doesn't mean he achieved it.
> >
> >Try this:
> >
> >char acStringLit[6] = "Inform";
> >
> >That statement is legal in C and illegal in C++.
>
> It's illegal in C99 as well, I think.
Nope.
C99 6.7.8#14:
# An array of character type may be initialized by a character string
# literal, optionally enclosed in braces. Successive characters of the
# character string literal (including the terminating null character if
# there is room or if the array is of unknown size) initialize the
# elements of the array.
Note: _if_ there is room.
> And will garner a warning in many C dialects.
That means nothing. C compilers may emit anything from
An error was detected - giving up.
(as their only error message) to
This code is phenomenally ugly.
for any code which doesn't include a #pragma beautiful, as long as they
compile all strictly conforming code which fits.
Richard
Richard Bos
> ChicagoDave wrote:
> > I'm going to step in here and ask that we all knock it off.
>
> A good idea. Let's summarize a few salient points, first, however:
>
> -- C and C++ are not the same language. However, C code, if written
> carefully not to conflict with the requirements of C++, can compile to
> a C++ compiler. Does that make it a subset of C++?
If it did, C would be a subset of Pascal, and vice versa, because with
sufficient care, a C program can be written which is also Pascal. See
<http://www.nyx.net/~gthompso/self_mult.htm> (and shudder).
Basically, unless _normal_ C programs are also C++ programs, C is not a
subset of C++. And hardly any of my normal C programs compile as C++...
> -- Any discussion of this sort invokes the rabid anti-Microsoft bias of
> many folks on this news group. I sympathize. But Microsoft and .NET
> aren't going away. May as well accept it, particularly as C#.NET is
> pretty cool anyway.
*Shrug* Please explain how I can install Sheesh-dot-com on my Revo,
then.
Richard
samwyse
> I did answer your question.
Well, still not quite: When are .NET programs allowed to invoke ActiveX
components that are marked "Safe for Scripting"? Never, sometimes, always?
> Any of the scenarios you point out for ActiveX security issues is not
> relevent to .NET. The .NET security checking looks at the actual code
> and determines what is happening. If the code is trying to do something
> that hasn't been explicitly allowed, a security error will prevent the
> code from executing. Let's be clear about this:
All managed code eventually causes non-managed code to be executed
somewhere, to simulate the VM that is the target archtecture of the .NET
portable bytecode.
> In the ActiveX world, the code isn't checked. there's a bit in the file
> that says it's trused in entirety. No one is arguing that this is a
> crappy, flawed, and mis-used architecture.
>
> I'm saying .NET doesn't do things that way.
In other words, "never" is the answer I was looking for. Thanks.
ChicagoDave
"NET programs allowed to invoke ActiveX components that are marked
"Safe for Scripting""
...and am having a hard time. But I think I know where this is going.
In order for a .NET program to have the ability to invoke _anything_
(including an ActiveX object), it would need security settings
explicity opened by the user using the .NET Security Client.
Your reply "never" is absolutely correct, but the comment is
misleading. You're trying to drive a wedge into Microsoft .NET
development by making the "Safe for Scripting" architecture sound like
something that makes .NET fundamentally insecure.
There's absolutely no validity to this line of thinking. If you were to
create a program or control that was a facade for an ActiveX control,
you would have to explicitly open up the "AllowPartiallyTrustedCallers"
security setting for the .NET program. This is off by default and even
opening up security in IE won't allow the .NET code to be executed
because it contains an operation that requires
"AllowPartiallyTrustedCallers".
Let me repeat this part:
The .NET code does not execute without permission.
Your comment about "All managed code causes non-managed code to be
executed somewhere" is also true, but this is exactly why Microsoft
implemented Code Access Security. Every operation is tested, including
operations that launch unknown entities, before the program is
executed. If any of these operations haven't been explicity allowed
access to execute, than the VM never even executes the code.
I invite you to read through the documentation on MSDN regarding CAS:
No system is perfectly secure. If you run a linux box and install
something that requires root access, you're trusting that that
component doesn't have any malicious intent. But because you have the
option not to install it, you are the ultimate barrier for security
breeches. .NET requires the same exact level of interaction but it even
goes further. It gives the user (and developer) the ability to
explicitly design the operations that need to be allowed for a program
to execute.
So using CAS, I could create a program that required no operations
other than "Execute" and "Connect to Internet" and if the user allowed
those two operations, my program would execute perfectly without any
other requirements from the user.
If I created a program that required "Write to Local Disk" operations
and the user has this barred, my program wouldn't execute. It would
fail with a security exception before it even got to the point of
executing.
I know this is way off topic, but feel very strongly about pointing out
the difference between rhetoric and fact. The fact is, .NET is an
extremely safe and efficient development platform. You can say anything
you want about the state of MS development/security 5 years ago and I
will agree on nearly every point. But it's important to realize that MS
has moved way past ActiveX and COM as far as base architectures are
concerned.
David C.
Adam Thornton
Matthew Russotto <russ...@grace.speakeasy.net> wrote:
>In article <r%N3e.1477$1r6.1219@trnddc02>,
>Icedragon <icenetRE...@icedragon.net> wrote:
>>My original contention: "it has already been shown that some of these tools
>>had/have exploitable buffer overruns in them"
>>Compiler == tool. If the tools for the platform have overruns, it's likely
>>the environments do too.
>You'll never find a more wretched hive of specious reasoning.
Actually, I think you'll find that 1600 Pennsylvania Avenue is *even
more wretched*, difficult as that is to believe.
Adam
Adam Thornton
Icedragon <icenetRE...@icedragon.net> wrote:
>I disagree with you that C is somehow more safe or superior to C++,
>considering C++ supports C code. That said, we agree to disagree, let's be
>done with this.
Hey! A C++ compiler will also support my brand new language
"C--noreallyImeanminusminusandthensomemoreminuses" (henceforth
"C--...etc.").
The only legal program in "C--...etc." is:
int main(int argc,char **argv) {
exit(0);
}
This code will do the same thing, when compiled by a conformant
C--...etc. compiler, that the same code, compiled by a
correctly-implemented C or C++ compiler will do, because C--...etc. is a
strict subset of C and C++.
Please explain to me how this is abusable.
Adam
Adam Thornton
Jimmy Maher <mah...@SPAMgrandecom.net> wrote:
>I'm learning Inform right now, and the language is absolutely screaming
>for a good visual environment similar to Borland's Delphi and C++
>Builder. (There may be other environments just as good, mind you.
>Those are just the products I am familiar with.)
>
>Give me a professional-grade visual environment for Inform that requires
>.NET, and I will run not walk to download this framework of yours.
>Alternately, give me another language as powerful as Inform, only with
>an integrated visual IDE, and I will be all over .NET there too.
I don't know what you mean by "visual" here.
Seriously.
Writing code of any sort, is, for me, a fundamentally textual process.
Sure, there are visual interface builders I've found helpful (RIP,
VX-Rexx!), but these are useful for, well, deciding the layout of your
product's GUI. I don't see how anything like them is applicable to
something like Inform (presuming you're not proposing a drag-and-drop
adventure builder, where you lay out the map visually and autogenerate
code to build that, which strikes me as both of limited utility and
fundamentally unhelpful for everything about IF that isn't the map.)
So all I can figure you mean is, "something that does syntax
highlighting, has an integrated compiler and maybe some sort of indexed
or structurally-aware source browser, and will let me jump to the source
location that the first compilation error came from." In which case,
uh, Emacs plus speedbar pretty much does all that. That, not
coincidentally, is my favorite Java development environment as well as
my favorite Inform environment (honestly I've never used speedbar for
Inform because I've never written a game big enough to require a source
structure complex enough to make it worth the bother).
But maybe I'm missing something: what do you mean by "visual" here?
Adam
Jimmy Maher
> I don't know what you mean by "visual" here.
> So all I can figure you mean is, "something that does syntax
> highlighting, has an integrated compiler and maybe some sort of indexed
> or structurally-aware source browser, and will let me jump to the source
> location that the first compilation error came from." In which case,
> uh, Emacs plus speedbar pretty much does all that. That, not
> coincidentally, is my favorite Java development environment as well as
> my favorite Inform environment (honestly I've never used speedbar for
> Inform because I've never written a game big enough to require a source
> structure complex enough to make it worth the bother).
No, that's not what I mean. There are already quite a few tools to do
that with Inform. Personally, I've been using a free editor called
ConTEXT with Inform syntax highlighting. It's wonderful, and I wouldn't
want to be without it, but that's not what I'm talking about here.
> But maybe I'm missing something: what do you mean by "visual" here?
Okay, I'll try to describe my dream environment. Warning: this is
heavily influenced by Borland C++ Builder and Delphi.
When you start working on a new game, you are presented with a blank
window to contain the visual aspects. We'll call this a form. You also
have a blank text window to work with, separate from but linked to the
visual window.
On a menu bar, you have a bunch of commonly used, rather generic Inform
objects represented by little icons. You will have to have a room
object, of course, but many other objects are possible as well... a
light source, a book, a container object (knapsack, etc.). These are
all very generic, though, grouped by their fuction. The same object
might serve as a flashlight and an (American) torch, a knapsack and a
purse, etc. How? Let's hold off on that for just a moment and talk
about rooms first.
For most, the first step in creating an IF game is creating a map. You
can do this visually by clicking the "ROOM" icon on the menu bar to
highlight it, then dragging it to any blank area in the form window.
When you do this, a couple of things happen. A simple icon representing
a room appears in the form window, and all of the code necessary for a
very simple, generic room appears in the text editor.
Anytime a room is highlighted in the form window, something we'll call
the properties window for that room is displayed. This contains a whole
lot of, you guessed it, properties for that room. For instance, there
is a dropdown for "has light," which can be set to true or false. There
are also textual fields for the short and long descriptions, etc.
Basically, all of the common traits relating to a room are here.
Initially they are set to generic defaults -- perhaps the short
description is just set to something like "Room #1," etc. You change
these to suit your game. As you do this, your code is automatically
changed in the editor window.
As you create more rooms and drop them on the map, you can connect them
together. Simply click on a room, then drag the mouse to the room it
should connect to. Again, the code for this is automatically generated
in the editor window.
Other objects are handled similarly to rooms. You drag the generic
object you want from the menu bar and drop it on the room that should
contain it. Double clicking on a room will bring up a list of the
objects it contains. Click on any of these objects to bring up its
properties window, them customize things to your heart's content.
Container objects just function similarly to rooms. Drop objects into
them, then double click them to manipulate those objects.
This little propeties window we've been discussing also has a tab for
"before" and "after" routines. Common verbs are listed here, with text
fields for the functions that should be executed for them. Initially,
these fields will all be blank, meaning said routines do not exist, but
they can be filled in by you with function names from your program.
Let's say you want to create a poisoned apple. You would type a
function name into the "After Eat" field. If this function existed in
your code, the appropriate code to link it to the apple object would be
generated automatically. If not, a the above code is still generated,
but the skeleton of a function with the name you specified is also
generated for you, and you are dropped into the text editor at that
point, ready to code up the function.
Yes, I said code. This is not an "easy adventure creator" and not a way
to avoid learning Inform. It is a shortcut to take care of as many of
the mundane, tedious tasks as possible, and allow you to concentrate on
the gnarly bits that need your attention. Anytime you want to, you can
roll up your sleeves and dive into the code yourself. In creating a
game of any complexity, you will be spending the vast majority of your
time doing just that. That's fine. It's sort of the point, really.
You will NOT be spending a lot of time coding the generic sort of stuff,
worrying about indenting, and the like. That's being taken care of for
you, simply and elegantly. I can see this tool dramatically reducing
development time, reducing frustration as syntax niggles and the like
will be far less common, and generally making IF development a much more
pleasant experience. You still have the ability to code manually
anywhere and everywhere, however, and you will have to in many places if
you expect to create anything more than the most generic shell of a
game. That's a fact of life.
Any changes you make manually in the text editor would be reflected in
the GUI, and vice versa. It should be possible to manually code a room
or other object, and have it appear in the GUI just as if it had been
automatically generated. This would be an absolutely hellacious thing
to code up, though... probably the thorniest problem involved in
creating this app. Even Borland's professional products don't really do
this the way I would like.
I don't know how good a job I've done of explaining the dream app that's
in head, so if you need further clarification just let know and I will
try my best.
An app like this would of course require a huge amount of time, energy,
and considerable technical skill to pull off. I'm not sure I have
sufficent reserves of any of the three, at least right now. I can
dream, though...
Jimmy
samwyse
> So all I can figure you mean is, "something that does syntax
> highlighting, has an integrated compiler and maybe some sort of indexed
> or structurally-aware source browser, and will let me jump to the source
> location that the first compilation error came from." In which case,
> uh, Emacs plus speedbar pretty much does all that. That, not
> coincidentally, is my favorite Java development environment as well as
> my favorite Inform environment (honestly I've never used speedbar for
> Inform because I've never written a game big enough to require a source
> structure complex enough to make it worth the bother).
My favorite environment consists of two windows: one running vim, the
other running the following shell script:
while true; do read reply; make $TARGET && ./$TARGET; done
PJ
If you haven't seen it yet, check out Plugh!, which is meant to be a
visual development environment for TADS. It's not complete, and in
fact seems to be stalled, but it is along the lines of what you defined
(and I also would like) for Inform.
Link is www.plugh.info.
PJ
Andrew Cowper
> concentrate on the gnarly bits that need your attention. Anytime you
> want to, you can roll up your sleeves and dive into the code yourself.
> In creating a game of any complexity, you will be spending the vast
> majority of your time doing just that. That's fine. It's sort of the
> point, really. You will NOT be spending a lot of time coding the
> generic sort of stuff, worrying about indenting, and the like. That's
> being taken care of for you, simply and elegantly. I can see this
> tool dramatically reducing development time, reducing frustration as
> syntax niggles and the like will be far less common, and generally
But as you say, you'll be spending the majority of your time with your
sleeves rolled up in the code. So what are you saving by having all
the visual stuff and properties editors, that you couldn't save
cutting and pasting from a text file with code templates in it (or
emacs' skeletons for instance)?
> Any changes you make manually in the text editor would be reflected in
> the GUI, and vice versa. It should be possible to manually code a
This is the real hard part. Whats going to happen is that as soon as
you go in and edit your generated code the visual editor will become
much less usefull, and in all probability dangerous because its going
to mess up what you've done when it can't understand it.
None of this is to say that its not a beautiful dream though :)
--
Andrew Cowper
Pick a different user name to email me.
ChicagoDave
You might want to do a Google search in rec.arts.int-fiction for visual
IDE. We've discussed this a lot over the years. In fact, I was a
longtime instigator of this sort of discussion. I decided to give it a
shot and created a workable (if not usable and complete) program called
Visual Inform (it's on the archive somewhere).
What I learned from the experience is that creating an IDE is not all
that hard. I didn't implement features as you decribe them, but some of
the ideas are the same.
But as I was doing this work I was also still developing some games
using UltraEdit. Eventually I realized that I personally would never
use my own Visual Inform program to write a game because the
fundamental difference between IF and general programming (like Delphi
or C++) is that you're developing a story. The programming part can be
made more productive with syntax highlighting, auto complete, spell
checker, templates, breaking up your game into multiple files, and
things that nearly any professional text editor can handle.
I think the one thing an IDE (integrated development environment) could
offer would be inline debugging.
But I think the graphical stuff is not in line with what IF essentially
is, which is a story.
Any IDE has to first and foremost cater to the author or writer with an
easy way to track storylines, scenes, endpoints, branches, response
libraries, character development, and more. Then, within the construct
of providing a productive writing environment, enable all these other
gadgets to help the author construct their story effectively, which
would include all of the generic IDE nicities.
A few of us have tried to attack the IF IDE problem from the
generalized programming view and have either succeeded modestly or
failed. I think the only way to succeed completely is to attack it from
the writer's perspective.
This is not to say that a set of visual drag and drop tools wouldn't be
helpful. They might. But I think we still haven't discovered the core
set of tools needed to make an IF author highly productive.
David C.
Paul Du Bois
> >>>A list of interpreters used in IFComp 2004 and their source
language:
> >>>WinFrotz - C/C++ mix
> >>>Frotz - C/C++ mix
Jeez Louise, so much fuss! If you're worried about programs
implemented in C++, why not create a .net port of glulx? Then you'd
have the safety to be able to sleep at night, AND a productive, proven
development environment.
p
Adam Thornton
Jimmy Maher <mah...@SPAMgrandecom.net> wrote:
>Adam Thornton wrote:
>> I don't know what you mean by "visual" here.
[long, cool description snipped]
Yeah, it sure would be nice to have something like that, but....
>An app like this would of course require a huge amount of time, energy,
>and considerable technical skill to pull off. I'm not sure I have
>sufficent reserves of any of the three, at least right now. I can
>dream, though...
And here's the problem: the amount of effort that would go into
developing such an environment would be far, far larger than the amount
of effort using it to write games would save. Borland can get away with
investing the resources in an IDE like this because they can hope that
hundreds of thousands of developers will use their product (and of
course produce a revenue stream to fund the IDE's development).
Whereas, the total worldwide number of Inform programmers is in the few
thousands at largest, I think. Speaking just for myself, I wouldn't pay
for an IF development environment--I don't do it enough that the
investment would make sense, and I can get where I want to be with the
cruder tools available to me. My shelves are lined with cool products
(mostly games) that I paid for, used once or twice, and then never
touched again.
I think to produce this environment would take tens of thousands of
man-hours, and the total amount of time that would be saved by its use
might well be less than that.
I wonder to what degree something like this could be put on top of an
existing framework, though. I think that, for instance, Apple's Xcode
can be extended to support new languages; would it make sense to create
an Inform development environment for Xcode?
Adam
Jimmy Maher
Thanks, that is indeed very interesting. Definitely the closest thing
I've seen to what I have in mind, although I'm somewhat crippled by my
completely lack of TADS knowledge.
Jimmy
Jimmy Maher
> But as you say, you'll be spending the majority of your time with your
> sleeves rolled up in the code. So what are you saving by having all
> the visual stuff and properties editors, that you couldn't save
> cutting and pasting from a text file with code templates in it (or
> emacs' skeletons for instance)?
Well, it's a question of total development time, not ratios between
coding and doing something else. Let me give a simplistic example:
Say you write a small game that takes 100 hours to create with just a
text editor. However, you only spend 50 of these hours actually
wrestling with important coding problems. The rest of the time is
sucked up by the busy work: typing out object after very similar object,
worrying about syntax, indenting, hunting down typos, niggly little
things like making sure each map connection has a corresponding
connection at its destination, etc.
Under a theoretical IF IDE, you still spend 50 hours doing the important
bits of coding. That can't be helped. However, maybe only have to
spend 5 or 10 hours with all of the above, because most of those issues
are eliminated or at least made easier to deal with. End result: Total
development time is dramatically lessoned, frustration is reduced, and
the whole process is much more enjoyable and much less frustrating...
particularly for newbies, who would be able to get a very simple
skeleton game working without coding anything, then could learn Inform
at their own pace once hooked.
> This is the real hard part. Whats going to happen is that as soon as
> you go in and edit your generated code the visual editor will become
> much less usefull, and in all probability dangerous because its going
> to mess up what you've done when it can't understand it.
Yes, I'm aware of that. Compromises would probably have to be made
here. Some middle ground would have to be found between absolutely free
editablity of your code and the need to keep the GUI aware of what's
going on in the code. I'm not sure where that line would have to fall.
Since I was dreaming, though, I thought I might as well go all out...
Jimmy
Jimmy Maher
> I think the one thing an IDE (integrated development environment) could
> offer would be inline debugging.
I think the logical place for this might actually be in the interpreter.
It wouldn't be that hard to add functionality to an existing
interpreter to allow the user to view the object tree, program counter,
global and local variables, etc., interactively.
>
> But I think the graphical stuff is not in line with what IF essentially
> is, which is a story.
While I don't disagree that some or most IF is story-oriented, I'm not
sure I see the rest of your logic.
> Any IDE has to first and foremost cater to the author or writer with an
> easy way to track storylines, scenes, endpoints, branches, response
> libraries, character development, and more. Then, within the construct
> of providing a productive writing environment, enable all these other
> gadgets to help the author construct their story effectively, which
> would include all of the generic IDE nicities.
This sounds more like a prototyping or flowcharting tool. It would be
very nice to have, especially for complex story-oriented games, but it
strikes me as fufilling a very different role from the app I've
described. The two (imaginary) apps would actually complement each
other rather than rival one another. (Or integrate all of it together
into one app.)
Jimmy
Andrew Plotkin
>
> Well, it's a question of total development time, not ratios between
> coding and doing something else. Let me give a simplistic example:
>
> Say you write a small game that takes 100 hours to create with just a
> text editor. However, you only spend 50 of these hours actually
> wrestling with important coding problems.
Or, let's say you spend 90 of those hours wrestling with code (and
prose), and only 10 on repetitive busy work. Then the savings of
automation are very small.
See, it *is* a question of that coding time ratio. You're assuming
it's 50%. I think that's a large overestimate.
samwyse
> ChicagoDave wrote:
>
>> I think the one thing an IDE (integrated development environment) could
>> offer would be inline debugging.
>
> I think the logical place for this might actually be in the interpreter.
> It wouldn't be that hard to add functionality to an existing
> interpreter to allow the user to view the object tree, program counter,
> global and local variables, etc., interactively.
Nitfol does some, if not all, of this.
samwyse
>> This is the real hard part. Whats going to happen is that as soon as
>> you go in and edit your generated code the visual editor will become
>> much less usefull, and in all probability dangerous because its going
>> to mess up what you've done when it can't understand it.
>
> Yes, I'm aware of that. Compromises would probably have to be made
> here. Some middle ground would have to be found between absolutely free
> editablity of your code and the need to keep the GUI aware of what's
> going on in the code. I'm not sure where that line would have to fall.
> Since I was dreaming, though, I thought I might as well go all out...
There are some tools (non-GUI) that do some of this. For example, I've
written a Perl script that takes a "transcript" and generates room and
object descriptions. The idea is that you write out how you want the
game to play, and code is generated to do that. Other people have
written scripts that take dialog trees and similarly generate code. The
difficulty with all of these is, as you've said, merging things together.
I've sketched plans for an XML representation of Inform code. The
benefit is that you could have several files with partial definitions of
an object that could be combined into one. For example, the
transcript-to-Inform script could provide Bob's "description" property,
a dialog tree script would provide some "life" and "orders" code, and
you could hand-edit the rest. The merge process would result in a
single "Bob" object.
Like so many others, I haven't had the time to do much with this idea, alas.
Joel Ray Holveck
> I wonder to what degree something like this could be put on top of an
> existing framework, though. I think that, for instance, Apple's Xcode
> can be extended to support new languages; would it make sense to create
> an Inform development environment for Xcode?
Well, that's essentially what inform-mode under Emacs amounts to, isn't it?
joelh
David Thornley
PJ <pete_...@hotmail.com> wrote:
>ChicagoDave wrote:
>> I'm going to step in here and ask that we all knock it off.
>
>A good idea. Let's summarize a few salient points, first, however:
>
>-- Arguing about the security of C, C++ or any of the current set of IF
>compilers is kind of ridiculous. Does anyone honestly think the Hong
>Kong/Taiwan/Shanghai bug-writing/bug-fixing shops are trying to infect
>the world using IF as a vector? In short, "No."
>
No, but well-intentioned mistakes can be just as bad, and there are
malicious people out there. Nor do I want to start changing my habits,
which have worked well so far.
I had been unaware that .NET had useful sandbox capability; thanks for
telling me that, people. There's lots of software out there that I
don't know much about, for various reasons, and IMNSHO too much
propensity for people fond of a software package to assume its
details are well known.
>-- Any discussion of this sort invokes the rabid anti-Microsoft bias of
>many folks on this news group. I sympathize. But Microsoft and .NET
>aren't going away. May as well accept it, particularly as C#.NET is
>pretty cool anyway.
>
Could be; I'm not at all convinced that Microsoft "gets" security yet.
XP SP2 is definitely a step in the right direction there.
>-- Icedragon wants to write games in .NET. Applause. But he will get
>no kudos from the community unless he writes a full .NET IF development
>platform and distributes it broadly enough that somebody else starts
>using it. That means it also has to be good -- probably better, in
>fact -- than the existing IF languages. Possible, but not necessarily
>probable.
>
Not quite - if he writes an excellent game, that would be good. In my
experience, excellent games do not happen nowadays without specialized
IF development systems (even if the author writes his or her own
development system), so this is something of a moot point. In any
case, a development system is at least an indication that other
games might be coming, so it is an incentive to download and install
software to run it.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Andrew Plotkin
> Andrew Plotkin wrote:
> > Here, Jimmy Maher <mah...@spamgrandecom.net> wrote:
> > >
> > > Well, it's a question of total development time, not ratios between
>
> > > coding and doing something else. Let me give a simplistic example:
> > >
> > > Say you write a small game that takes 100 hours to create with just
> a
> > > text editor. However, you only spend 50 of these hours actually
> > > wrestling with important coding problems.
> >
> > Or, let's say you spend 90 of those hours wrestling with code (and
> > prose), and only 10 on repetitive busy work. Then the savings of
> > automation are very small.
> >
> > See, it *is* a question of that coding time ratio. You're assuming
> > it's 50%. I think that's a large overestimate.
>
> efficiency of many of the folks on RAIF. Not everyone who develops IF
> games is a professional developer by trade or training.
Wouldn't that mean I am uncharacteristically *low* in my code-writing
time, and the average Inform author spends *more* than 90% of his time
wrestling with code?
You go on to talk about a development system that handles some of the
coding for you. Presumably the coding that is, in some sense,
repetitive busywork.
But you then have to go back to the original proposal, which didn't
say that:
Jimmy Maher wrote, on Apr 8, 9:37 am:
> ...typing out object after very similar object, worrying about
> syntax, indenting, hunting down typos, niggly little things like
> making sure each map connection has a corresponding connection at
> its destination, etc.
(I'm sure I spend less time than most authors on *that* stuff, but that
doesn't mean that most people spend a *lot* of time on it. As compared
to designing significant code and writing text.)
In any case, you are allowing the goalposts to drift. "Everyone talks
about the perfect IF development environment, but nobody does anything
about it" -- because when you're just talking about it, you can gloss
over internal contradictions. Places where your simplifications either
(a) aren't powerful enough, or (b) don't simplify the thing that
people really want simplified, or (c) turn out to be just as unsimple
as what they're replacing. Stick to a specific proposal, and at least
we have something to discuss.
PJ
> Here, Jimmy Maher <mah...@spamgrandecom.net> wrote:
> >
> > Well, it's a question of total development time, not ratios between
> > coding and doing something else. Let me give a simplistic example:
> >
> > Say you write a small game that takes 100 hours to create with just
a
> > text editor. However, you only spend 50 of these hours actually
> > wrestling with important coding problems.
>
> Or, let's say you spend 90 of those hours wrestling with code (and
> prose), and only 10 on repetitive busy work. Then the savings of
> automation are very small.
>
> See, it *is* a question of that coding time ratio. You're assuming
> it's 50%. I think that's a large overestimate.
Well, to support Jimmy a bit, I think you are overestimating the coding
efficiency of many of the folks on RAIF. Not everyone who develops IF
games is a professional developer by trade or training.
Jimmy's 50-50 estimate may be more correct for one basic reason: other
than the simplest construct used to define a room or object, almost any
item in the game has the potential to require significant coding time
if you're not constantly working in Inform. Unless you have lots of
Inform experience and are actively coding a game, it is very easy to
forget which properties are most effective in doing simple things like
scenery objects. Is "has scenery" enough to keep the object from a
"take all?" When do you use "has static" and why? What about
"concealed," what's the difference beteween that and "scenery?"
Every time I go away from the language for even just a few months, I
find that I have to reacquaint myself with these subtle differences.
If I don't, I can spend several hours doing something which you and
other "top coders" may find easy, like a talk button on an intercom.
How do you make it switchable? What's the best way to get the NPC I
want to talk to in scope, or is that even necessary? Has anybody
contributed a button class to the library? Can I modify phones.h to do
what I want? Stupid of me, perhaps, but I'm not a real Inform or TADS
pro, nor am I ever likely to be. On the other hand, if I could just
drag a button object onto the workspace of my visual IDE and read its
comments in the code display, then I would probably save myself the 2
hours or so necessary to relearn these tricks. You probably don't need
to relearn this stuff, so you think of it as "simple coding." For many
of us, however, nothing in Inform is truly simple; it's just degrees of
complexity and the same opportunity for "stuckness" that we find in
playing the games.
I think you are also ignoring the possibility that if coding were
easier because of a drag 'n drop interface, more amateur coders who are
interested in writing but are scared of coding might join the fray.
Right now, let's say there are 50 Inform games a year developed by
people in the community, at an average development time of 100 hrs per
game, or 5000 labor hours per year. Per your ratios, there's only 500
hours a year that could be minimized by a visual development
environment. If it took 10,000 hours to develop that system and 250
hours a year of maintenance, obviously the net community payback would
be non-existent.
But, on the other hand, if the ratio of complex to less complex coding
is actually more like Jimmy's 50-50, and the development time (I
suspect) is really more like 200 hours per game, the payback scenarios
are quite different. You'd be attacking a nut of 5,000 annual hours of
development time for the existing Inform community. And if 50
additional games were developed because more people were attracted to
Inform by the visual IDE, then the potential payback quickly becomes
substantial.
Another point that would help even you "top coders" out there: a
visual IDE could serve as the native host for a class library that
would enable even more complex classes and object behaviors to be
deployed by Inform developers. Case in point: I recently spent a
significant amount of time analyzing how you implemented relative
directions in "Hunter, In Darkness." That required me to go to the
archive, pull down your source, wade through your files, etc., to
decide exactly how you were using the "UnknownVerb" entry point and the
various verbs, verbsubs, and ancillary routines to serve as a model for
the effects I wanted.
If instead a generic solution was sitting in the class library of a
visual IDE, I would simply have dragged it onto my workspace, read the
usage comments, then decided whether or not to use it, modify it, or
try to find an alternative solution. Even "top coders" can get a lot
of benny out of borrowing complex, pre-coded but relatively generic
objects like this rather than building everything from scratch. The
savings are, I expect quite a bit higher than most people really
believe. How many questions on r.a.i.f. end up being the same
solutions that people have figured out time and time again? How do I
do a hint menu? What's the best way to code a rifle or other
projectile shooting weapon? How do I do automatic opening/closing
doors? How do I stop implicit takes at the wrong time? etc., etc.,
etc. A visual IDE with a rich class/methods library could be a
tremendous boon to IF developers and potentially open the door to a
broader community of folks who are intimidated by the current "roll
your own" flavor of IF programming.
No visual IDE will solve all complex coding problems, but I think a
good one would be accepted far more readily than folks on this thread
tend to believe. The real problem is whether anyone has the time, the
chops, and the chutzpah to attack the problem. I don't have the
skills, but would be happy to help specify the requirements and/or
beta-test.
PJ
David Thornley
PJ <pete_...@hotmail.com> wrote:
>
>I think you are also ignoring the possibility that if coding were
>easier because of a drag 'n drop interface, more amateur coders who are
>interested in writing but are scared of coding might join the fray.
Okay, here's what piques my interest.
Lots of people will do something in Adrift that they wouldn't do
in a more conventional IF development system. Most of them produce
crap, but some of them go on to produce decent games. They will
even figure out how to use the yucky task system to do programming
in a horrifyingly complex way that appalls, for example, a software
engineer with considerable experience. (Consider "PK Girl", which
was very well done, and came with a way of unlocking the Adrift
equivalent of source code.)
The starting point seems to be to set up a simple way to set up the
routine stuff in a work of IF. This is stuff that a good programmer
can do when mostly asleep. Nobody who understands TADS halfway
decently is going to have any problem setting up a few rooms with
objects and such, but that appears to be a nearly unsurmountable
barrier to lots of people.
If there was a well-developed product that allowed that way of getting
started, I think a lot more people would step in.
>Another point that would help even you "top coders" out there: a
>visual IDE could serve as the native host for a class library that
>would enable even more complex classes and object behaviors to be
>deployed by Inform developers.
That works in Eclipse because there's standards in Java libraries
that simply don't exist in Inform libraries. I don't see how
that could be done (which is not the same thing as saying it cannot
be done, of course).
>If instead a generic solution was sitting in the class library of a
>visual IDE, I would simply have dragged it onto my workspace, read the
>usage comments, then decided whether or not to use it, modify it, or
>try to find an alternative solution.
Meaning that there has to be a generic solution in a form that the IDE
can handle easily.
>do a hint menu? What's the best way to code a rifle or other
>projectile shooting weapon? How do I do automatic opening/closing
>doors? How do I stop implicit takes at the wrong time? etc., etc.,
>etc. A visual IDE with a rich class/methods library could be a
>tremendous boon to IF developers and potentially open the door to a
>broader community of folks who are intimidated by the current "roll
>your own" flavor of IF programming.
>
I think this is almost completely orthogonal to the IDE issue, but is a
matter of creating and disseminating appropriate libraries.
If these libraries are available, organized, and easily browsable,
they can be easily used from any development tool. If they aren't,
well, the IDE can't access what doesn't exist, or isn't readily
accessible.
Jimmy Maher
(snip a lot of good stuff that I agree with)
Great minds think a alike. :-) This functionality was indeed on my mind
when I wrote out my initial description of the ID, but that description
was already getting so long and complex that I decided not to go into it
at that time. However, now that you've brought it up I will say that it
should be possible to add objects to your visual object palette anytime.
I picture the IDE coming with a stable of basic objects, but these
being only a starting point really. After creation, objects could be
packaged up, exported, then uploaded to the archive. Then other users
of the IDE who are interested in objects of that type can just download
the appropriate package and install the objects it contains into their
IDE with just a click or two. The objects are then there on their
palette, ready for use at any time.
> No visual IDE will solve all complex coding problems, but I think a
> good one would be accepted far more readily than folks on this thread
> tend to believe. The real problem is whether anyone has the time, the
> chops, and the chutzpah to attack the problem. I don't have the
> skills, but would be happy to help specify the requirements and/or
> beta-test.
There's the rub, eh? The one argument members of the newsgroup have
raised that I *do* entirely agree with is that this project would
require one hell of a lot of work to pull off, and may not be worth it
in the long run. Still... I'm vaguely thinking about it. We'll see.
Jimmy
Andrew Plotkin
> should be possible to add objects to your visual object palette anytime.
> I picture the IDE coming with a stable of basic objects, but these
> being only a starting point really. After creation, objects could be
> packaged up, exported, then uploaded to the archive. Then other users
> of the IDE who are interested in objects of that type can just download
> the appropriate package and install the objects it contains into their
> IDE with just a click or two. The objects are then there on their
> palette, ready for use at any time.
My only comment here is that before you design the IDE, you have to
design the IF development language which is scalable enough to permit
it. Inform isn't it.
I have some ideas, but they're highly speculative. I haven't even come
up with a complete model, much less proved it workable, much less
written it.
PJ
> I think this is almost completely orthogonal to the IDE issue, but is
a
> matter of creating and disseminating appropriate libraries.
> If these libraries are available, organized, and easily browsable,
> they can be easily used from any development tool. If they aren't,
> well, the IDE can't access what doesn't exist, or isn't readily
> accessible.
The key to any good visual IDE is the richness of the object model it
is allowing the developer to access, so I don't think this is
orthogonal. The fundamental purpose of a visual IDE is to make
reusable object code "available, organizable, and easily browsable" as
well as simplifying its insertion into / use by the program under
development.
A visual IDE that was nothing but a shell to start with, with no
predefined classes & objects, would not be very exciting to me. I
would still be doing all the work to populate the tool, which cuts the
benefits of object reuse that a visual IDE brings to the table.
Without this capability, you have just another fancy text editor.
So I think the issue of a robust class/methods library for Inform could
use a few different adjectives or descriptors other than orthogonal in
relation to a visual IDE. Of primary importance, probably. Difficult,
undoubtedly. Not yet realized in Inform, obviously. Better suited to
TADS3 or Hugo, perhaps. But given Inform's popular following, I still
think a fully realized visual IDE for Inform could be a rich
enhancement to the IF community.
PJ
ChicagoDave
if you want to move IF into a "professional" atmosphere, you would need
a syntax, parser, and world model that were component-based and
extensible. To do this, you would almost certainly have to develop the
platform on a full blown VM (.NET CLR or Java VM) as opposed to an IF
specific VM.
If you had this, then building an IDE would be much more obvious and
helpful.
Hence my grandiose idea for IF#.
If course I am properly chastised for not being smart enough nor
available enough to actually implement IF# by myself, so I will shut up
now.
David C.
David Thornley
ChicagoDave <david.c...@gmail.com> wrote:
>And on a more vocal note, I think Inform is great for what it is, but
>if you want to move IF into a "professional" atmosphere, you would need
>a syntax, parser, and world model that were component-based and
>extensible. To do this, you would almost certainly have to develop the
>platform on a full blown VM (.NET CLR or Java VM) as opposed to an IF
>specific VM.
>
machine (for TADS 3) looks like it should definitely be powerful
enough. What do you think would be required that an IF-specific
VM would lack?
David Thornley
PJ <pete_...@hotmail.com> wrote:
>David Thornley wrote:
>> I think this is almost completely orthogonal to the IDE issue, but is
>a
>> matter of creating and disseminating appropriate libraries.
>> If these libraries are available, organized, and easily browsable,
>> they can be easily used from any development tool. If they aren't,
>> well, the IDE can't access what doesn't exist, or isn't readily
>> accessible.
>
>The key to any good visual IDE is the richness of the object model it
>is allowing the developer to access, so I don't think this is
>orthogonal. The fundamental purpose of a visual IDE is to make
>reusable object code "available, organizable, and easily browsable" as
>well as simplifying its insertion into / use by the program under
>development.
>
have considerable value without an IDE. It isn't an easy one, either,
and from my limited knowledge of Inform would be easier in another IF
language - TADS 3, for example.
ChicagoDave
specific VM is the ability to add the unknown. The other thing that's
sort of tightly-coupled within TADS3 (and all other current platforms)
is that the PC is hardcoded as a single user.
So my contention is that a generalized VM with an IF syntax might be
more extensible.
David C.
Dan Shiovitz
Hmm, I think the single-user PC is almost entirely a library issue,
unless you're talking about wanting something like networking support.
In that case, yeah, you'd have to add support for it to the
interpreter, but this is something you'd have to do in any case,
regardless of the VM, if it wasn't implemented already. It's not
really that, say, the JVM is more extensible, it's that it's more
*extended* -- it already has support for networking, various kinds of
graphics, and most stuff you'd ever want for an IF system.
>David C.
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Mike Roberts
>I may be mistaken in this area, but the one thing missing from an IF
> specific VM is the ability to add the unknown.
I have no idea what you're getting at here.
> The other thing that's sort of tightly-coupled within TADS3 (and
> all other current platforms) is that the PC is hardcoded as a single
> user.
First off, I don't understand at all what this has to do with this has to do
with building an IDE. (That is what you were talking about, isn't it, or
did I miss a deflection in the thread?) Second, the singleness of the user
isn't actually a VM issue anyway; it's just that the libraries for IF that
tend to be of interest here are libraries for single-player IF.
--Mike
mjr underscore at hotmail dot com
PJ
Well, way back, the OP was talking about developing an IF game in .NET.
We seem to have successfuly forked the thread over to discussing
development of a visual IDE for IF.:)
I agree, however, that the robustness of standard IF virtual machines
has little to do with development of a visual IDE for IF.
A visual IDE is a developer's tool that uses a set of simple graphical
paradigms to manage the elements of a program and autogenerate a lot of
code through the quick & easy deployment of rich class libraries and
methods. Conceptually, it's little more than a text editor with a lot
of fancy graphical features on top of it to input, view & edit code,
and with a database underneath to track & manage the objects that are
being coded (the game under development), or already have been coded
(the libraries). Those fancy features, however, can make a tremendous
difference in the productivity of the development process, particularly
when the visual IDE is populated with a rich class & methods library.
It may be true that certain languages suit the visual paradigm better
than others. Obviously, the more object-oriented the language, the
easier it is to manage the code generation process (no "floating"
routines, global variables, etc., would be nice) It may also be true
that a specific IF language might have some limitations like file
handles that would require some hard thinking to circumvent in the code
generation-to-compilation process. There's no doubt that developing a
good, "professional" visual IDE would be a lot of work. But IMHO,
there's no technical reason why good IDE's couldn't be developed for
Inform, TADS and/or Hugo.
PJ
ChicagoDave
apologize for talking out of my arse and yes, I changed the subject.
This thread needs to die since there have been a bazillion topics in
it.
Anyway. I just make a sort of bland assumption that an IF specific VM
is not as extensible as a generalized VM with all of the IF parts being
components that tie together into a program that does the same things.
In a componentized platform, one could theoretically turn the VM itself
into a library.
I know this thinking has very little support, which is why I will now
shut up about VM's and IDE's.
David C.