Sign in with
Sign up | Sign in
Your question

A small IF platform survey

Last response: in Video Games
Share
March 31, 2005 8:02:00 AM

Archived from groups: rec.games.int-fiction (More info?)

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). 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

More about : small platform survey

Anonymous
March 31, 2005 8:02:01 AM

Archived from groups: rec.games.int-fiction (More info?)

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.
Anonymous
March 31, 2005 8:02:01 AM

Archived from groups: rec.games.int-fiction (More info?)

Icedragon wrote:
> 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
Related resources
Can't find your answer ? Ask !
Anonymous
March 31, 2005 11:16:48 AM

Archived from groups: rec.games.int-fiction (More info?)

Icedragon wrote:
> 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
Anonymous
March 31, 2005 11:42:23 AM

Archived from groups: rec.games.int-fiction (More info?)

> 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.

> 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.
Anonymous
March 31, 2005 1:24:45 PM

Archived from groups: rec.games.int-fiction (More info?)

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).

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
Anonymous
March 31, 2005 1:49:57 PM

Archived from groups: rec.games.int-fiction (More info?)

Icedragon wrote:
> 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.
March 31, 2005 1:49:58 PM

Archived from groups: rec.games.int-fiction (More info?)

"Paul Drallos" <pdrallos@tir.com> wrote in message
news:fv6dnRDV897ok9HfRVn-rw@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...
Anonymous
March 31, 2005 2:30:36 PM

Archived from groups: rec.games.int-fiction (More info?)

On Thu, 31 Mar 2005, 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).

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
stone@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David
Anonymous
March 31, 2005 3:42:38 PM

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:

>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
Anonymous
March 31, 2005 4:18:43 PM

Archived from groups: rec.games.int-fiction (More info?)

On Jeudi 31 Mars 2005 06:02, 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).

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.bucket@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
Anonymous
March 31, 2005 5:10:05 PM

Archived from groups: rec.games.int-fiction (More info?)

I play IF almost exclusively on my Palm handheld. If the .NET runtime
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
Anonymous
March 31, 2005 9:34:34 PM

Archived from groups: rec.games.int-fiction (More info?)

Icedragon <icenetREMOVETHIS@icedragon.net> wrote:
> 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). 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.


--
David Griffith
dgriffi@cs.csbuak.edu <-- Switch the 'b' and 'u'
Anonymous
April 1, 2005 3:02:50 AM

Archived from groups: rec.games.int-fiction (More info?)

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). 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
April 1, 2005 6:48:11 AM

Archived from groups: rec.games.int-fiction (More info?)

See inline.

<dwhyld@gmail.com> wrote in message
news:1112283743.731244.119200@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.
April 1, 2005 6:51:38 AM

Archived from groups: rec.games.int-fiction (More info?)

> 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.
Anonymous
April 1, 2005 6:51:39 AM

Archived from groups: rec.games.int-fiction (More info?)

Icedragon wrote:

>>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.
>
>

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
April 1, 2005 6:53:32 AM

Archived from groups: rec.games.int-fiction (More info?)

>> 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
>
>>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 :) 
April 1, 2005 6:55:34 AM

Archived from groups: rec.games.int-fiction (More info?)

Thanks for the replies.
Anonymous
April 1, 2005 1:25:16 PM

Archived from groups: rec.games.int-fiction (More info?)

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.

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.
Anonymous
April 2, 2005 2:43:53 AM

Archived from groups: rec.games.int-fiction (More info?)

In article <1112376316.309388.127610@z14g2000cwz.googlegroups.com>,
ChicagoDave <david.cornelson@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.
>
Does Mono work reliably?

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.
david@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
April 2, 2005 12:26:57 PM

Archived from groups: rec.games.int-fiction (More info?)

"ChicagoDave" <david.cornelson@gmail.com> wrote in message
news:1112376316.309388.127610@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.

> See Also: http://www.ifsharp.org
>
> David C.
>
April 2, 2005 12:44:37 PM

Archived from groups: rec.games.int-fiction (More info?)

> 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.

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.
April 2, 2005 3:01:50 PM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/2/2005 2:44 AM, Icedragon did proclaim:
> 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.
Anonymous
April 2, 2005 4:28:33 PM

Archived from groups: rec.games.int-fiction (More info?)

ChicagoDave wrote:
> 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
Anonymous
April 2, 2005 5:55:13 PM

Archived from groups: rec.games.int-fiction (More info?)

>"ChicagoDave" <david.cornelson@gmail.com> wrote in message
>news:1112376316.309388.127610@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.)

--
Sophie Frühling

"El arte no viste pantalones."
-- Rubén Darío
Anonymous
April 2, 2005 8:42:47 PM

Archived from groups: rec.games.int-fiction (More info?)

ChicagoDave wrote:

> 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
Anonymous
April 2, 2005 9:35:35 PM

Archived from groups: rec.games.int-fiction (More info?)

"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.

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.
Anonymous
April 2, 2005 11:33:04 PM

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>> 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.
>
> Then you're trusting the author of TADS, or Frotz, or whatever host you
> 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
Anonymous
April 3, 2005 3:08:24 AM

Archived from groups: rec.games.int-fiction (More info?)

I'll be the first one not to trust Internet Explorer and unknown
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.
April 3, 2005 4:26:39 AM

Archived from groups: rec.games.int-fiction (More info?)

"Mike Roberts" <mjr_@hotmail.com> wrote in message
news:QrC3e.11784$zl.11355@newssvr13.news.prodigy.com...
> "Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>>> 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.
>>
>> Then you're trusting the author of TADS, or Frotz, or whatever host you
>> 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.

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­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




> 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
Anonymous
April 3, 2005 5:04:49 AM

Archived from groups: rec.games.int-fiction (More info?)

Here, Icedragon <icenetREMOVETHIS@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.

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.
April 3, 2005 7:40:11 AM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/2/2005 5:26 PM, Icedragon did proclaim:
> "Mike Roberts" <mjr_@hotmail.com> wrote in message
>>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.

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.
Anonymous
April 3, 2005 7:46:28 AM

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@icedragon.net> wrote:
>mjr:
>>"Icedragon":
>>> On top of that, it has already been shown that some of these tools
>>> had/have exploitable buffer overruns [...]
>>
>> 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.
>> From: "David Kinder"
>> 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.

--Mike
mjr underscore at hotmail dot com
April 3, 2005 7:54:41 AM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/2/2005 7:35 PM, ChicagoDave did proclaim:

> "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....
Look for the section labeled "Malicious ActiveX Examples" about halfway
down the page.
April 3, 2005 12:41:59 PM

Archived from groups: rec.games.int-fiction (More info?)

"Andrew Plotkin" <erkyrath@eblong.com> wrote in message
news:D 2nbv1$o6v$1@reader1.panix.com...
> Here, Icedragon <icenetREMOVETHIS@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.
April 3, 2005 1:37:57 PM

Archived from groups: rec.games.int-fiction (More info?)

> 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.

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).
April 3, 2005 8:49:25 PM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 12:08 AM, ChicagoDave did proclaim:

> I'll be the first one not to trust Internet Explorer and unknown
> 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.

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.
Anonymous
April 3, 2005 9:00:54 PM

Archived from groups: rec.games.int-fiction (More info?)

Here, Icedragon <icenetREMOVETHIS@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'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.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
April 3, 2005 9:18:37 PM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 4:37 AM, Icedragon did proclaim:

>>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.
April 3, 2005 9:24:01 PM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 12:19 PM, Jimmy Maher did proclaim:

> 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!
April 4, 2005 12:15:28 AM

Archived from groups: rec.games.int-fiction (More info?)

>> 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.

>> 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.
Anonymous
April 4, 2005 1:58:02 AM

Archived from groups: rec.games.int-fiction (More info?)

"Icedragon" <icenetREMOVETHIS@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++.

> 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-usenet@granades.com
April 4, 2005 1:59:23 AM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 3:15 PM, Icedragon did proclaim:
>>>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.
April 4, 2005 3:31:13 AM

Archived from groups: rec.games.int-fiction (More info?)

>>>>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.

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.
April 4, 2005 3:41:48 AM

Archived from groups: rec.games.int-fiction (More info?)

"Stephen Granade" <stephen-usenet@granades.com> wrote in message
news:m0u0mnr09h.fsf@granades.com...
> "Icedragon" <icenetREMOVETHIS@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.
Anonymous
April 4, 2005 2:28:25 PM

Archived from groups: rec.games.int-fiction (More info?)

In article <PSF3e.11404$k66.10752@trnddc03>,
Icedragon <icenetREMOVETHIS@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.
Anonymous
April 4, 2005 2:34:58 PM

Archived from groups: rec.games.int-fiction (More info?)

In article <r%N3e.1477$1r6.1219@trnddc02>,
Icedragon <icenetREMOVETHIS@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.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Anonymous
April 4, 2005 2:38:14 PM

Archived from groups: rec.games.int-fiction (More info?)

In article <A9Y3e.1724$%b1.1024@trnddc08>,
Icedragon <icenetREMOVETHIS@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.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
April 4, 2005 4:03:27 PM

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/3/2005 6:41 PM, Icedragon did proclaim:
> "Stephen Granade" <stephen-usenet@granades.com> wrote in message
> news:m0u0mnr09h.fsf@granades.com...
>
>>"Icedragon" <icenetREMOVETHIS@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)).
!