A small IF platform survey

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
88 answers Last reply
More about small platform survey
  1. 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.
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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.
  7. 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...
  8. 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
  9. 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
  10. 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).
  11. 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
  12. 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'
  13. 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
  14. 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.
  15. 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.
  16. 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
  17. 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 :)
  18. Archived from groups: rec.games.int-fiction (More info?)

    Thanks for the replies.
  19. 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.
  20. 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-
  21. 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.
    >
  22. 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.
  23. 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.
  24. 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
  25. 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
  26. 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
  27. 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.
  28. 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
  29. 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.
  30. 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
  31. 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.
  32. 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.
  33. 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
  34. 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.html
    Look for the section labeled "Malicious ActiveX Examples" about halfway
    down the page.
  35. Archived from groups: rec.games.int-fiction (More info?)

    "Andrew Plotkin" <erkyrath@eblong.com> wrote in message
    news:d2nbv1$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.
  36. 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).
  37. 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.
  38. 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.
  39. 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.
  40. 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!
  41. 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.
  42. 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
  43. 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.
  44. 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.
  45. 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.
  46. 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.
  47. 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.
  48. 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.
  49. 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)).
Ask a new question

Read More

Video Games