Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Scripting

73 views
Skip to first unread message

Matt

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

Hey all,

I am in the process of planning this game and have decided to add a
scripting language to help out in level creation. I want to be able to
attatch snippets of script to tiles on the map, enemies , whatever I feel
like. For instance, I want to be able to attach a script to a tile that
will, if the player steps on it, spawn a fireball coming from the adjacent
wall to create a trap, and so on. Anyway, I know how to tokenize the
script file, and have some ideas on how to go about the actual compiling
and executing of the script, but I was hoping someone out there has done
this and could give me some tips on how to run the script at game quality
speed. I know that it can be done, alot of games use scripts (Duke 3d,
Quake). Perhaps there is already a library out there to handle this?

thanks alot for your help,

-matt

Paul F. Snively

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

In article <01bd3a3e$dcc31e00$5723...@ghema.jaguarsystems.com>, "Matt"
<gue...@usa.netNOSPAM> wrote:

Several. This is one area in which there's really no excuse for reinventing
the wheel--especially given that most people don't have a background in
writing high-performance interpreters!

Scripting languages are supposed to be small and simple, so I'm inclined to
recommend a good, fast, embeddable Scheme interpreter, which to me suggests
MzScheme (see <http://www.cs.rice.edu> and follow the Programming Language
Theory links to MzScheme). MzScheme is a complete Scheme, has been ported
to Win32, Mac, and various flavors of UNIX, is fast, is embeddable, and is
relatively easily extended via C++--that is, it's easy to create C++
classes whose functionality is then available in the Scheme language. There
are also extremely good introductory programming texts in Scheme, e.g. "The
Little Schemer," which may not be important to you, but may be to your
prospective audience.

TCL might be a more attractive choice if you don't like Lisp dialects. I
could only recommend it in good conscience as of the current version (8.x)
because of historical performance problems, but the new language
architecture is much faster. It also has been ported to Win32, Mac, and
UNIX and is fairly easily embeddable and extensible.

> thanks alot for your help,

I hope this does help!

> -matt

Paul Snively

James Slaughter

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

>In article <01bd3a3e$dcc31e00$5723...@ghema.jaguarsystems.com>,
"Matt"
><gue...@usa.netNOSPAM> wrote:
>
>> Hey all,
>>
>> I am in the process of planning this game and have decided to add a
>> scripting language to help out in level creation.
[...]
>> wall to create a trap, and so on. Anyway, I know how to tokenise

>> the script file, and have some ideas on how to go about the actual
>> compiling and executing of the script, but I was hoping someone out
>> there has done this and could give me some tips on how to run the
>> script at game quality speed.

There are libraries, but I prefer to write my own so that I know
what's going on. In my opinion, the best way to increase execution
time is to spend more during compilation. I try to convert all my
scripts into a series of instructions, similar to an assembly Op-Code.
Each Instruction is an integer, and each takes two operands, one or
both of which may be null if it is unused. The redundancy is there to
make it easy to move memory about for loading and script processing.
Then when it comes to executing the code, I index an array of pointers
to class member functions with the OpCode (which are pre-defined in
ascending numeric order, so it's OK), and dereference it passing to
the function each parameter, plus a virtual instruction pointer, and a
memory area.

Basically, my execution routine, once the script has been loaded looks
like this in pseudo code:

unsigned int CS_IP = StartPoint(); // Starting offset is never zero;

while(CS_IP)
{
InstructionTable[Script[CS_IP].OpCode](Script[CS_IP],&CS_IP,Memory);
}

...and an instruction sets CS_IP to zero to quit, else CS_IP is
automatically incremented to the next instruction, or set to something
else for a JMP instruction, etc. So far, I have not thought of anything
faster than this for execution, though I would welcome any suggestions.

When compiling, I take the following steps:

1) Parse into tokens
Divide the source file up into individual symbols, replace #define
style macro replacements, etc. Be careful to keep literals as such;
"SMEG" should remain as one token, not '"','SMEG','"'. Also, make sure
that two-symbol tokens are parsed as such, the equality operator
should not suddenly become to consecutive assignment operators. I
chose to add a 'fumble' in that it when it found something along the
lines of LValue op equals RValue (eg, A+=B), it substituted it for
LValue equals LValue op RValue (or A=A+B). Again, be sure to parse
'B--B' as 'B-(-B)' (pointless, I know), rather than 'B-- B' which is
illegal. Many commercial C++ compilers have a hard time with
statements such as '++A+++++A++;', which we might equate to ((++A)++)
+ ((++A)++), IE=2*(A+2), so I don't see why yours or mine should
bother if they're only a psuedo implementation of a custom script
language. Of course, strip out comments and whitespace. Caution! 'int
A/*COMMENT*/B' is illegal, because it is equivelent to 'int A B', but
if you just strip out comments, it becomes 'int AB' which is legal, if
AB is not already defined. Now's the time to decide if your language
is case sensitive. No? Convert the case now, then!

2) Mark Tokens as their type.
My entire language is based arround lists of a structure that defines
the name of the instruction as it appears in the script, the op-code
it should be replaced with, it's precedence (so * comes before +), the
types the operator deals with, and what format the operator is: unary,
binary, or keyword. It also stores the function pointer ready to
export to the instruction table for execution. I just index the Token,
if it is not in the list, then it must be an identifer, else I look up
its type. There can be a conflict with unary and binary
operators: -A-B, for example. I use the fact that a unary operator is
only ever next to one identifier.

3) Handle references
Now's the time to build a list of prototypes, and handle nasty include
directives. Do the includes first. Try to make sure that every
identifier is declared somewhere.

4) Type Checking
Does your language allow float=string*integer? Even if it does, you'll
want to make sure that the right operators being used. Do all type
checking now, and do it strictly to make running the script easy and
safe.

5) Recursive Descent.
Having assigned types, to split each expression up, I used a recursive
descent technique, not always terribly efficiant, but it works and is
quite elegant with a minimal of coding. In this, you start with an
expression 'A=B+C*D' for example. You take the first delimeter ('='),
and see if it is a lower priority than the one after ('+'), and if it
is, you call the procedure again, but with the bit after the first
operand. It is, so we start a new function with ('B+C*D'), and repeat
the process. We find that '*' is more important than '+', and so call
ourself again, with 'C*D' as the equation. There is nothing after
this, so we write it down in our 'to-do' list. We would also write it
down if whatever came after was equally or less important.

1st Operation: C*D;

The function returns, and we are now in the one started with
'B+[C*D]'. We would now look to see if whatever comes after the C*D is
still more important than the '+'. There isn't anything, so it's time
to do the Add. Our to-do list shows:

1st Operation: C*D;
2nd Operation: B+C;

Now we are back in the first call. There is nothing left at all, so we
write the instruction down:

1st Operation: C*D;
2nd Operation: B+C;
3rd Operation: A=B;

That's it! We would of course have to preserve C & B, since there
contents get overwritten during our approach. You could either
automatically 'push' any variable that is modified at the start, and
'pop' it back, which is a simple task, or add a result variable to
your instruction format, so that each opcode takes three parameters.
It's up to you. Be careful when popping values back, particularly when
doing stuff like if(A+B==C+D), where you can't say Push A, A+B, Pop A
is A equal to [...], you have to wait until the whole statements over,
which is OK here, but not for if(A+B==A+C), where it would check that
A+B is equal to A+A+C, which is impossible.

5) Variables
You cannot go on refering to variables by name. Well, actually, I
suppose you could, but it's hardly fast, even with the might of the
Standard C++ Library template classes ;), is it? No. Variables become
addresses, but they cannot be absolute addresses. Sometimes a function
will be called, and other times it won't. This would totally screw up
the creation of variables at run-time, so unless you want to define
all variables used in your script at start up and use giga bytes of
memory in the process, you need relative numbers. The easiest
soloution is to save an index at the start of each call, and use an
offset from that index.

6) Resolve names
Bugger about with name mangaling, etc. I'll go into this only if you
wan't me to. Very little to do unless you're into native Object
Orientation in your script language. (Yeah, I'm getting fed up typing
this message that few people are going to bother to read, and fewer
will find it interesting).

7) Write the Op Codes.
You also need to make function calls work some how. This is basically
a jump, and then a jump back, or, since this is a runtime thing, you
might like to spawn another execution routine that handles the sub
function, and let the recursion dump you back to where you were. Up to
you, really.

8) Execute, see above.

Comments? Criticism? Sorry about the last few steps... I expect you
can figure it out. I really would like to discuss ways to improve on
all this in a constructive manner... I'm not perfect, neither are you,
but together we come pretty close ;->.

One thing that I never decided on was the best techniques for I/O. I
currently follow a C/C++ style 'don't have any _keywords_' technique,
although it does support disk I/O since it's virtually the same on all
platforms. For anything else I have a system with which the script
communicates with the host interpreter to ask for services, which I
plan to include linking to external modules. What's the standard way,
I'm self taught...

Paul F. Snively wrote in message ...


>Scripting languages are supposed to be small and simple, so I'm
>inclined to recommend a good, fast, embeddable Scheme interpreter,
>which to me suggests

[...]
Not arguing, just asking, but how small is small, how simple is
simple? Sounds like I've made a complete arse of mine, but it is still
quite fast, and is very flexible.

I hope someone gets something out of this.
Regards,
James.

Paul Bleisch

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

Hey all,

Just thought people who are interested in small tight scripting
languages should check out Lua. The link is:
http://csg.uwaterloo.ca/~lhf/lua/

Lua is a small embeddable language with metalanguage features
and a pascal-esque syntax. First class functions. Hmm.. it
is smaller and faster than scheme and Python.

Paul


Brendan Reville

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

Matt wrote in message
<01bd3a3e$dcc31e00$5723...@ghema.jaguarsystems.com>...


>I am in the process of planning this game and have decided to add a

>scripting language to help out in level creation. I want to be able to
>attatch snippets of script to tiles on the map, enemies , whatever I feel
>like. For instance, I want to be able to attach a script to a tile that


There was an interesting article on Jedi Knight's scripting, somewhere
under programming, on http://www.gamasutra.com.

It also had a link to a site with *lots* of embeddable languages that you
could play with.

- Brendan


visit http://www.artoz.com/trance for a different kind of multimedia CD-ROM!

Amit Patel

unread,
Feb 18, 1998, 3:00:00 AM2/18/98
to

Paul F. Snively <ch...@mcione.com> wrote:
|
| Several. This is one area in which there's really no excuse for reinventing
| the wheel--especially given that most people don't have a background in
| writing high-performance interpreters!
|
| Scripting languages are supposed to be small and simple, so I'm inclined to
| recommend a good, fast, embeddable Scheme interpreter, which to me suggests
| MzScheme (see <http://www.cs.rice.edu> and follow the Programming Language
| Theory links to MzScheme). MzScheme is a complete Scheme, has been ported
| to Win32, Mac, and various flavors of UNIX, is fast, is embeddable, and is
| relatively easily extended via C++--that is, it's easy to create C++
| classes whose functionality is then available in the Scheme language. There
| are also extremely good introductory programming texts in Scheme, e.g. "The
| Little Schemer," which may not be important to you, but may be to your
| prospective audience.

I was trying to decide on a scripting for my game, and I considered
Scheme but decided against it for the same reason I decided against
Python and C++:

A general purpose language isn't going to be as well suited
for my game as a special purpose language.

Yes, I know I can write macros in Scheme, but it's still going to be a
functional/imperative style language, and it's still going to have a
lot of decisions made for me, like static scope, parenthesized syntax,
basic data types, lists using cons-cells, and so on.

As an example, suppose I was writing an RPG [I'm really not], and I
wanted to attach scripts to various events that might occur in the
game. I might want to write:

OBJECT Fred IS-A Paladin:
ON attacked-by X:
if X.evil: attack(X)
ON time-is 12pm:
walk to: tavern
ON time-is 9pm:
walk to: home

I can write a `bytecode' representation of this much more efficiently
than if I had used Scheme (or some other general purpose language),
because I know exactly what kinds of constructs are common in my code
and what to optimize for. I would expect that my compiled
representation would be two to five times smaller than that of a
general purpose language being used for this specific task. I would
guess (but I am not certain) that the virtual machine could be
somewhat smaller for a special purpose language as well. (The last
time I wrote a scripting language, which admittedly was many years
ago, the VM was under 10k, and it's hard to find that in SCM or
MIT-Scheme or any other variants I know of...)

I also get to write things in a natural style, like "12pm", rather
than something like "(make-time 12 'pm)". Consider how much easier it
is to use strings, lists, vectors, and functions in Scheme or Python
than in C. Yes, you _can_ code it in C, but it's much easier in
Scheme because it's built-in. Similarly, if I want to write programs
about objects, times, events, and locations, then it's easier to do
this in a language that understands these abstractions than to do it
in a language that merely allows you to build these abstractions.
This is especially true when the overall structure of your program
does not fit the conventional procedural (or functional, or
object-oriented) style of programming.


Anyway, I agree that Scheme may serve as a good scripting language,
but I disagree that ``there's really no excuse for reinventing the
wheel''. As the language becomes more specialized, there is more to
gain by writing your own language. You may be looking for a bicycle
wheel, and a motorcycle wheel, although more suitable than an airplane
wheel, just won't do.


- Amit

Jason Hoffoss (Tclord)

unread,
Feb 18, 1998, 3:00:00 AM2/18/98
to

On Mon, 16 Feb 1998 19:48:46 -0000, "James Slaughter"
<James.S...@susano.demon.co.uk> wrote:

>>In article <01bd3a3e$dcc31e00$5723...@ghema.jaguarsystems.com>,
>"Matt"
>><gue...@usa.netNOSPAM> wrote:
>>
>>> Hey all,
>>>
>>> I am in the process of planning this game and have decided to add a
>>> scripting language to help out in level creation.
> [...]
>>> wall to create a trap, and so on. Anyway, I know how to tokenise
>>> the script file, and have some ideas on how to go about the actual
>>> compiling and executing of the script, but I was hoping someone out
>>> there has done this and could give me some tips on how to run the
>>> script at game quality speed.
>
>There are libraries, but I prefer to write my own so that I know
>what's going on.

This is exactly why I wanted to do the same thing. :) Plus, I think
it's actually probably easier to do it yourself that figure out how
these other libraries and such work. I've never been able to do it.
They try and make it very generic and flexible for all cases, and it
just complicates it too much, etc. Writing your own, you can tailor
it down to just what you need. I think it works out a lot better.
Plus, you understand how it all works, and learned something new along
the way, which is always handy, I don't care what anyone says.

>In my opinion, the best way to increase execution
>time is to spend more during compilation. I try to convert all my
>scripts into a series of instructions, similar to an assembly Op-Code.

That's what I did. I have to think there's a good reason CPU's have
the sort of instruction sets that they do, and work the way they do.
So the best way to do an imbedded language is to model it after a CPU
I think, for doing general purpose things. Specific things it makes
more sense to have some hook to it, like the way interrupts worked
under DOS. If you really needed to, you could write the interpreter
in assembly for speed, and it probably wouldn't be very hard to write
it because your instructions would be so similar to the CPU
instructions.

Btw, the compiler I wrote for my language is blazing fast, and I
didn't even try writing it for speed. I put limitations on sizes so I
can load the source file completely into memory. Most real compilers
don't make an assumption like this and stream it off disk, which slows
it down incredibly I guess.

>Each Instruction is an integer, and each takes two operands, one or
>both of which may be null if it is unused. The redundancy is there to
>make it easy to move memory about for loading and script processing.

Your instructions don't model a CPU as much then I guess. With CPUs,
generally you do operations with a register and an operand, which is
how my language works as well. I only have one register, however, the
accumulator, which cuts down the number of instructions quite a bit.
You also have operators for branching, pushing values on the stack,
etc. I did combine most binary operations (i.e. math operations) with
the top value on the stack (i.e. acc = stack val * acc), since you
generate situations like this a lot when compiling a language.

Btw, is your language more like a real language, or more of an
assembler? It sounds more like an assember.

>Then when it comes to executing the code, I index an array of pointers
>to class member functions with the OpCode (which are pre-defined in
>ascending numeric order, so it's OK), and dereference it passing to
>the function each parameter, plus a virtual instruction pointer, and a
>memory area.

I have an int for the PC (program counter), which I used as the index
into a block of memory that is the byte-code. I basically use a big
switch statement to handle each op-code. If an op-code uses data, the
data directly follows the op-code (just like machine language). For
any decent compiler, this switch statement should turn into a jump
table in the executable.

>Basically, my execution routine, once the script has been loaded looks
>like this in pseudo code:
>
>unsigned int CS_IP = StartPoint(); // Starting offset is never zero;
>
>while(CS_IP)
>{
> InstructionTable[Script[CS_IP].OpCode](Script[CS_IP],&CS_IP,Memory);
>}
>
>...and an instruction sets CS_IP to zero to quit, else CS_IP is
>automatically incremented to the next instruction, or set to something
>else for a JMP instruction, etc. So far, I have not thought of anything
>faster than this for execution, though I would welcome any suggestions.

Looks like it will accomplish the same thing. Don't know what all
that info is you are passing in. I'd probably just make the CS_IP a
global and not bother passing it into the function. Of course, even
calling a function has it's overhead, which I guess is why I went with
a switch statement inside an infinate loop (with an RTS instruction
returning from the loop and thus exiting the loop).

>When compiling, I take the following steps:
>
>1) Parse into tokens
>Divide the source file up into individual symbols, replace #define
>style macro replacements, etc. Be careful to keep literals as such;
>"SMEG" should remain as one token, not '"','SMEG','"'. Also, make sure
>that two-symbol tokens are parsed as such, the equality operator
>should not suddenly become to consecutive assignment operators.

I don't really bother with tokenizing. I just compare the current
text with what is allowed at whatever point I'm at. For example, if I
just found an '=', then I know there much be a variable name or a
number next. If not, throw out an error. My compiling method is
pretty object oriented in how it works, which isn't really the
tranditional way compiler are writen.

>I
>chose to add a 'fumble' in that it when it found something along the
>lines of LValue op equals RValue (eg, A+=B), it substituted it for
>LValue equals LValue op RValue (or A=A+B).

I don't remember what I did here. I think it turns out something like
this in the end, though:

Load acc, A
Add acc, B
Store A, acc

So I guess it gets treated like A=A+B really. :)

>Again, be sure to parse
>'B--B' as 'B-(-B)' (pointless, I know), rather than 'B-- B' which is
>illegal.

In my system, if there is a space between the minus signs, it works
fine. If there isn't, it will see it as either a pre or post
increment operator (has higher precedence). So the results turn out
the same as would happen in C, and I don't run into problems like this
in C really, so I don't expect I will writing scripts. :)

>Many commercial C++ compilers have a hard time with
>statements such as '++A+++++A++;', which we might equate to ((++A)++)
>+ ((++A)++), IE=2*(A+2), so I don't see why yours or mine should
>bother if they're only a psuedo implementation of a custom script
>language.

Right. The way I set things up, though, it kind of came for free. It
would first see ++A, and then see (++A)++, but at this point you have
a post-increment on a non-LVALUE, so it would throw an error (who the
hell writes something like this anyway? :)

>Of course, strip out comments and whitespace. Caution! 'int
>A/*COMMENT*/B' is illegal, because it is equivelent to 'int A B', but
>if you just strip out comments, it becomes 'int AB' which is legal, if
>AB is not already defined. Now's the time to decide if your language
>is case sensitive. No? Convert the case now, then!

Because I work with C so much, I wanted to make mine work as much like
C as possible, so it is case sensitive as well. I think a scripting
language is a lot better the more it is like a real language a lot of
people know. Programmers will be able to learn and use it much
easier, and anyone who doesn't know has a wide range of books to help
learn it from. You don't have to try teaching it to them.

The comment problem was easy to deal with for me, as I know where I
can expect white space, and I call a function at these points to skip
the whitespace. It also skips comments here as well. A nice property
of comments is that they are only valid where whitespace is valid.

>2) Mark Tokens as their type.
>My entire language is based arround lists of a structure that defines
>the name of the instruction as it appears in the script, the op-code
>it should be replaced with, it's precedence (so * comes before +), the
>types the operator deals with, and what format the operator is: unary,
>binary, or keyword. It also stores the function pointer ready to
>export to the instruction table for execution. I just index the Token,
>if it is not in the list, then it must be an identifer, else I look up
>its type. There can be a conflict with unary and binary
>operators: -A-B, for example. I use the fact that a unary operator is
>only ever next to one identifier.

I check for identifiers as the highest possible precedence, basically.
They always start with an alpha-numeric, and end with anything not an
alpha-numeric, numeric or underscore character. I also have a list of
all reserved keywords (just like with C), and make sure when I find a
variable name it isn't one of these. Unary operators don't cause
problems, as long as you follow your precedences correctly.

>3) Handle references
>Now's the time to build a list of prototypes, and handle nasty include
>directives. Do the includes first. Try to make sure that every
>identifier is declared somewhere.

Function calls is one place my language is very different from C (or
C++). I don't allow overloading, and all parameters to a function are
basically defaults. If you don't provide them, they will have
standard values (0 if you don't explicitly specify one). So, for a
function like:

func(int a, int b=2, int c, string d)

You could call it with wither func(), func(4), func(5, 5), etc. They
are all allowed. You just can't pass in more arguments than are
allowed for it, like trying to do func(1, 2, 3, "blah", 9). Also,
types have to match. I only have integers and strings as types.
Strings are act much like constant strings in C. You don't modify
them. Another nice feature I added to my language is not having to
use prototypes. You can make a call to a function ahead of actually
defining the function, and the compiler will handle it all properly
for you. Prototypes were always one handle I never really cared for
much. :)

Another interesting feature I have is with the whole pass by address
vs pass by value thing, which relates to your reference handling.
Instead of the function deciding what should be passed how, I decided
to make the caller decide this. So, for a function:

func(int a, int b)

I can call it as func(a, b) to pass by value, or func(&a, &b) to pass
by reference. Completely reverse how any other language I've ever
seen does things, but I think doing it this way could have some
interesting advantages. I haven't really put it into practice much to
see if it works well yet, though. It makes sense to me that it would
be more useful for the caller to have control over this, though. The
function just does things generically for everyone who calls it. It's
each caller that has specific things it wants to do with it's data.

>4) Type Checking
>Does your language allow float=string*integer? Even if it does, you'll
>want to make sure that the right operators being used. Do all type
>checking now, and do it strictly to make running the script easy and
>safe.

Can't do this in my language. What would this mean? You could just
call a function to convert the string to an integer, if the string
just has digits. I don't think converting like this is really all
that common, so a library function seemed like a logical thing to do.
Generally, strings in my language are just useful for passing to
library function, such as asking for input, getting the name of an
object, comparing 2 strings, etc. This is a good example of how I've
limited my language down to just what was needed to fit the job I had
in mind for it. I don't have to worry about trying too hard to make
it very general and work with everything anyone can think of.

>5) Recursive Descent.
>Having assigned types, to split each expression up, I used a recursive
>descent technique, not always terribly efficiant, but it works and is
>quite elegant with a minimal of coding. In this, you start with an
>expression 'A=B+C*D' for example. You take the first delimeter ('='),
>and see if it is a lower priority than the one after ('+'), and if it
>is, you call the procedure again, but with the bit after the first
>operand. It is, so we start a new function with ('B+C*D'), and repeat
>the process. We find that '*' is more important than '+', and so call
>ourself again, with 'C*D' as the equation. There is nothing after
>this, so we write it down in our 'to-do' list. We would also write it
>down if whatever came after was equally or less important.
>
>1st Operation: C*D;
>
>The function returns, and we are now in the one started with
>'B+[C*D]'. We would now look to see if whatever comes after the C*D is
>still more important than the '+'. There isn't anything, so it's time
>to do the Add. Our to-do list shows:
>
>1st Operation: C*D;
>2nd Operation: B+C;
>
>Now we are back in the first call. There is nothing left at all, so we
>write the instruction down:
>
>1st Operation: C*D;
>2nd Operation: B+C;
>3rd Operation: A=B;

I do a more object oriented method. Basically, since = has the lowest
priority, I check for this first:

int check_equ()
{
check_plus();
skip_white();
match("=");
check_plus();
out(OP_EQU); // stack-1 = acc
}

This looks for X=X type of things. It doesn't really worry about what
X might be, though. Next, in check_plus(), I break X down..

int check_plus()
{
check_mult();
skip_white();
match("+");
check_mult();
out(OP_ADD); // acc += stack - 1
}

So this looks for Y+Y within an X. So combined, we look for something
like (Y+Y)=(Y+Y). Since in check_equ() we first call check_plus(),
the whole Y+Y that is before the = gets processed before control
returns back to check_equ() and it can look for the =. So things are
all checked for in their correct precedence as a result. Works pretty
slick. Check_mult() would look like this..

int check_mult()
{
check_var();
skip_white();
match("*");
check_var();
out(OP_MUL); // acc *= stack - 1
}

Check_var() looks for a variable name or number/string, which has the
highest priority, so it doesn't make any calls down to anything else.
Whatever it finds it puts on the stack. So it's like recursion, but
it's always calling new functions. What's nice about using new
functions for each level is that you can just check for what you can
expect there, instead of having to check everything. Keeps each
function simpler.

>That's it! We would of course have to preserve C & B, since there
>contents get overwritten during our approach. You could either
>automatically 'push' any variable that is modified at the start, and
>'pop' it back, which is a simple task, or add a result variable to
>your instruction format, so that each opcode takes three parameters.
>It's up to you. Be careful when popping values back, particularly when
>doing stuff like if(A+B==C+D), where you can't say Push A, A+B, Pop A
>is A equal to [...], you have to wait until the whole statements over,
>which is OK here, but not for if(A+B==A+C), where it would check that
>A+B is equal to A+A+C, which is impossible.

Right, == has lowest priority, so (A+B) gets put on stack, (C+D) gets
put in acc when you actually execute the == operation.

>5) Variables
>You cannot go on refering to variables by name. Well, actually, I
>suppose you could, but it's hardly fast, even with the might of the
>Standard C++ Library template classes ;), is it? No. Variables become
>addresses, but they cannot be absolute addresses. Sometimes a function
>will be called, and other times it won't. This would totally screw up
>the creation of variables at run-time, so unless you want to define
>all variables used in your script at start up and use giga bytes of
>memory in the process, you need relative numbers. The easiest
>soloution is to save an index at the start of each call, and use an
>offset from that index.

Actually, I create 2 symbol tables, one for globals, one for local
vars. The max number for each is 256, so I can turn all variable
references into a byte that represents what variable I am dealing
with. I think a max of 256 is enough. I don't expect people to make
huge scripts, and limiting so I can use 1 byte for variable references
reduces the size a lot. Compiled scripts are pretty compact. In the
code to actually run the script, local and global variables each is an
integer array, and I use the variable number as the index to get the
value.

>6) Resolve names
>Bugger about with name mangaling, etc. I'll go into this only if you
>wan't me to. Very little to do unless you're into native Object
>Orientation in your script language. (Yeah, I'm getting fed up typing
>this message that few people are going to bother to read, and fewer
>will find it interesting).

I'm one of the exceptions then I guess. :) Since I don't allow
overloading, I don't have to worry about this one.

>7) Write the Op Codes.
>You also need to make function calls work some how. This is basically
>a jump, and then a jump back, or, since this is a runtime thing, you
>might like to spawn another execution routine that handles the sub
>function, and let the recursion dump you back to where you were. Up to
>you, really.

Again, I model it after CPU instructions, so I have a CALL instruction
and an RTS instruction. I also have branch instructions, which you
need for things like loops and gotos. You don't use them for function
calls. You can't just jump back, btw, because you can call functions
from many places. How do you know which to jump back to? So you need
a call stack, etc.

>8) Execute, see above.
>
>Comments? Criticism? Sorry about the last few steps... I expect you
>can figure it out. I really would like to discuss ways to improve on
>all this in a constructive manner... I'm not perfect, neither are you,
>but together we come pretty close ;->.

Well there's a glimpse from my experiences with messing with all this.
I've successfully written a compiler and interpreter for my language,
and they work. I haven't actually used the interpreter in a real game
yet, though. :) So you can call this a little more than theory, but
less than proven.

>One thing that I never decided on was the best techniques for I/O. I
>currently follow a C/C++ style 'don't have any _keywords_' technique,
>although it does support disk I/O since it's virtually the same on all
>platforms. For anything else I have a system with which the script
>communicates with the host interpreter to ask for services, which I
>plan to include linking to external modules. What's the standard way,
>I'm self taught...

The way I would handle it is with library functions, just like C. My
language doesn't really have library functions, though. They are
actually 'system functions', which are hooks to do special things like
this. For example, if you want to display a string to the user, you
can add in a 'print()' system function. All that is needed for me is
to add it to my 'system function' header file (which tells the
compiler what all the system functions are), and then add support for
it doing something useful in the interpreter. So it's pretty flexible
and easy to extend as I come up with new things I need to support.
The language itself never changes. You can extend the abilities of C
with new libraries without changing the fundimentals of C. You'll
notice I base a lot of my ideas on other things out there (C, CPU,
etc). I figure they did what they did for good reasons after
researching it extensively, so why re-invent the wheel? Take a
shortcut instead and do it how they do it. And of course, their
approaches are proven and stable.

I'm still fixing up my compiler and interpreter right now, but
eventually I plan to release this for others to use for their games.
Anyway, if you have any question about anything I mentioned, feel free
to ask.

>Paul F. Snively wrote in message ...
>>Scripting languages are supposed to be small and simple, so I'm
>>inclined to recommend a good, fast, embeddable Scheme interpreter,
>>which to me suggests
>[...]
>Not arguing, just asking, but how small is small, how simple is
>simple? Sounds like I've made a complete arse of mine, but it is still
>quite fast, and is very flexible.

What I sort of invision for my language is to have many small scripts
instead of just one big one (that's the idea I'm playing with anyway).
Going to the first post, he wanted a script to handle shooting out a
fireball as part of a trap. So you could have a script just for that
one trap. Another trap elsewhere would be a seperate script, etc. So
having a lot of little scripts in one reason I wanted to keep the
compiled byte-code compact. It can make it easier to maintain as
well. Of course, you might have a lot more source files to deal with.
Tradeoffs for everything, as always.

-Jason

Paul F. Snively

unread,
Feb 19, 1998, 3:00:00 AM2/19/98
to

In article <6cfl25$6lg$1...@nntp.Stanford.EDU>, am...@Xenon.Stanford.EDU (Amit
Patel) wrote:

> I was trying to decide on a scripting for my game, and I considered
> Scheme but decided against it for the same reason I decided against
> Python and C++:
>
> A general purpose language isn't going to be as well suited
> for my game as a special purpose language.
>
> Yes, I know I can write macros in Scheme, but it's still going to be a
> functional/imperative style language, and it's still going to have a
> lot of decisions made for me, like static scope, parenthesized syntax,
> basic data types, lists using cons-cells, and so on.

Well, there are a lot of "ifs" and "buts" to respond to this with, e.g.
Scheme is lexically scoped, but you can often find implementations with
"dynamic-bind," "dynamic-let," and/or "dynamic-wind." The parenthesized
syntax can be done away with by writing a parser of some kind using, e.g.
Zebu. Of course it has basic data types and lists using cons cells. So
what? It had better have basic data types!

> As an example, suppose I was writing an RPG [I'm really not], and I
> wanted to attach scripts to various events that might occur in the
> game. I might want to write:
>
> OBJECT Fred IS-A Paladin:
> ON attacked-by X:
> if X.evil: attack(X)
> ON time-is 12pm:
> walk to: tavern
> ON time-is 9pm:
> walk to: home
>
> I can write a `bytecode' representation of this much more efficiently
> than if I had used Scheme (or some other general purpose language),
> because I know exactly what kinds of constructs are common in my code
> and what to optimize for. I would expect that my compiled
> representation would be two to five times smaller than that of a
> general purpose language being used for this specific task. I would
> guess (but I am not certain) that the virtual machine could be
> somewhat smaller for a special purpose language as well. (The last
> time I wrote a scripting language, which admittedly was many years
> ago, the VM was under 10k, and it's hard to find that in SCM or
> MIT-Scheme or any other variants I know of...)

Sure. This is always the trade off: specificity vs. generality. Given that
I'm targeting PC's and Macs rather than, say, Nintendo 64's and Sony
Playstations, I'm not overly concerned about the size of the code. I'm
concerned with how easily I can integrate it with C++ and what I can
express in it.

> I also get to write things in a natural style, like "12pm", rather
> than something like "(make-time 12 'pm)".

Again, macros or a preprocessor easily handle issues like this.

> Consider how much easier it
> is to use strings, lists, vectors, and functions in Scheme or Python
> than in C. Yes, you _can_ code it in C, but it's much easier in
> Scheme because it's built-in. Similarly, if I want to write programs
> about objects, times, events, and locations, then it's easier to do
> this in a language that understands these abstractions than to do it
> in a language that merely allows you to build these abstractions.

One reason I like MzScheme is that it has an object system. A major reason
that I like Lisp dialects in general is that it's easy to use them as
metalanguages: a language for writing a language that's specific to your
application. MzScheme has the added benefit that I can build the
abstractions, find that they are indeed too cumbersome in terms of either
memory or performance, and rewrite them in C++, providing them to the rest
of my MzScheme code as if they were native functionality of MzScheme.

> This is especially true when the overall structure of your program
> does not fit the conventional procedural (or functional, or
> object-oriented) style of programming.

I think this is your strongest point so far. It's been my experience that,
in game programming, you almost always end up wanting some sort of
delegation semantics, and none of the popular application or scripting
language naturally support such a semantics.

> Anyway, I agree that Scheme may serve as a good scripting language,
> but I disagree that ``there's really no excuse for reinventing the
> wheel''. As the language becomes more specialized, there is more to
> gain by writing your own language. You may be looking for a bicycle
> wheel, and a motorcycle wheel, although more suitable than an airplane
> wheel, just won't do.

While I agree in principle, I think there are larger questions that have to
be answered before making a choice, such as: are you adding a scripting
language for yourself or for potential third parties? If for yourself, then
knock yourself out and invent a new language, but don't be surprised if you
someday down the road find yourself wishing that your tight, specialized
little scripting language did something it doesn't, and can't easily
without turning its syntax, if not its semantics, into a hodgepodge. On the
other hand, if you really want third parties to add cool new objects to
your game or even build whole new games using nothing but the core
functionality of your engine, I still have to recommend sticking with an
existing embeddable language. In fact, I would even if only I'd be
scripting, again because I have a personal preference for expressive power,
and hence generality, vs. application specificity, which might indeed have
led me to a smaller and possibly faster (but I doubt it) implementation.

> - Amit

Paul

Sam Inala

unread,
Feb 22, 1998, 3:00:00 AM2/22/98
to

Amit Patel <am...@Xenon.Stanford.EDU> wrote in article
<6cfl25$6lg$1...@nntp.Stanford.EDU>...


> I was trying to decide on a scripting for my game, and I considered
> Scheme but decided against it for the same reason I decided against
> Python and C++:
>
> A general purpose language isn't going to be as well suited

> for my game as a special purpose language. [..]


>
> As an example, suppose I was writing an RPG [I'm really not], and I
> wanted to attach scripts to various events that might occur in the
> game. I might want to write:
>
> OBJECT Fred IS-A Paladin:
> ON attacked-by X:
> if X.evil: attack(X)
> ON time-is 12pm:
> walk to: tavern
> ON time-is 9pm:
> walk to: home

Gee, this looks just like Visual Basic events!

It seems like two approaches have been suggested:
1. Reinventing the wheel (write parser, compiler, and virtual machine)
2. Reusing a wheel (embedding Scheme, Tcl, Lua)

How about a third approach?
3. Interchangeable wheels (expose the game's object model)

Exposing the object model means that your game implements
some standard COM interfaces. Then you can use any scripting
language you want: Visual Basic, Java, C++, Perl, etc. You
can easily add custom events to be fired to any object and
custom properties and methods. Scripting support is lightweight
and mostly trivial to implement using ATL. Plus, you can leverage
the already existing knowledge of one million VB coders.

More information:
_Inside COM_ by Rogerson
_Effective COM_ by Box
_Inside OLE, 2nd Edition_
MSDN

--
Sam Inala < s a m i @ m i c r o s o f t . c o m >


Vic

unread,
Feb 22, 1998, 3:00:00 AM2/22/98
to

Sam Inala wrote:
> More information:
> _Inside COM_ by Rogerson
> _Effective COM_ by Box
> _Inside OLE, 2nd Edition_
any resources online? How do you use those COMs anyways? Do you just
need a win32 compiler or do you need visual C++?
--
--> http://www.cam.org/~tudor <--

Joshua Heyer

unread,
Feb 22, 1998, 3:00:00 AM2/22/98
to

Jason Hoffoss (Tclord) wrote:

> One thing I see about this is that it might take longer to learn this
> stuff than to use one of the first 2 methods. Also, I'm not sure if
> COM object just give you access to functions or to data as well, but
> if you allow access to the data, then you will lose the advantage of
> validating the data. While C and a lot of power, it can also be
> pretty fragile. If you don't really know what you are doing, and you
> do something bad, like try to access an illegal index in an array, or
> have a bad pointer, or whatever, you can crash the program, and it's
> not always an easy matter to find the problem. With a scripting
> language, you can design it to be a lot more crash-proof. Another
> thing I don't like about doing this is that your end users now have to
> be programmers to write the scripts, and have to own a compiler. If
> you write your own scripting language, they just need a text editor,
> and only have to learn a simplified language, rather than a full-blown
> language. And lastly, for me anyway, it's fun to write a compiler,
> and I think it's always good to know as much as you can. Writing a
> compiler can teach you a number of things.
>
> -Jason

Well said. It's funny to see how far some people will go to avoid
writing something themselves!

************************************************************************
Joshua Heyer -- joshua...@yahoo.com
************************************************************************
Save the Whales -- Harpoon a Honda.
************************************************************************


Jason Hoffoss (Tclord)

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

On 22 Feb 1998 21:11:10 GMT, "Sam Inala" <sa...@ersatz.microsoft.com>
wrote:

>It seems like two approaches have been suggested:
>1. Reinventing the wheel (write parser, compiler, and virtual machine)
>2. Reusing a wheel (embedding Scheme, Tcl, Lua)
>
>How about a third approach?
>3. Interchangeable wheels (expose the game's object model)
>
>Exposing the object model means that your game implements
>some standard COM interfaces. Then you can use any scripting
>language you want: Visual Basic, Java, C++, Perl, etc. You
>can easily add custom events to be fired to any object and
>custom properties and methods. Scripting support is lightweight
>and mostly trivial to implement using ATL. Plus, you can leverage
>the already existing knowledge of one million VB coders.

One thing I see about this is that it might take longer to learn this

Sam Inala

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Vic <tu...@cam.org> wrote in article <34F051...@cam.org>...


> Sam Inala wrote:
> > More information:
> > _Inside COM_ by Rogerson
> > _Effective COM_ by Box
> > _Inside OLE, 2nd Edition_
> any resources online? How do you use those COMs anyways? Do you just
> need a win32 compiler or do you need visual C++?

http://www.microsoft.com/cominfo COM info
http://www.microsoft.com/msdn General developer info
http://www.microsoft.com/kb Knowledge base articles

All you really need is any C++ compiler. (Actually, you can develop
COM components in C or VB too. But I digress.) You can develop
them on the Mac or Unix as well. RealNetworks, for example, does
this.

In C++, you use them just like you use normal C++ objects. Here's
how you can use the XML parser shipped with IE4:

#include <msxml.h>

//
// FIXME: Omitting error checking
//
IXMLDocument* pDocument = NULL;

HRESULT hr = CoCreateInstance(
CLSID_XMLDocument,
NULL,
CLSCTX_SERVER,
IID_IXMLDocument,
(void**) &pDocument );

IPersistStreamInit* pPersistStreamInit = NULL;
hr = pDocument->QueryInterface( IID_IPersistStreamInit, (void**)
&pPersistStreamInit );

// getting pStream omitted
hr = pPersistStreamInit->Load( pStream );

IXMLElement* pRoot = NULL;
hr = pDocument->get_root( &pRoot );

BSTR bstrAttribute = SysAllocString( OLESTR( "HOSTNAME" ) );

VARIANT var;
VariantInit( &var );

hr = pRoot->getAttribute( bstrAttribute, &var );
OutputDebugStringW( var.bstrVal );

VariantClear( &var );
SysFreeString( bstrAttribute );

Hmm, I hope that doesn't scare anyone off. Given a document like this one:

<?XML version="1.0"?>
<MIF
HOSTNAME="\\sami1"
Period="30">

<GROUP HREF="http://www.microsoft.com">
<PROTOCOL
IPADDRESS="238.238.238.238"
PORT="2000"
TTL="32">
</PROTOCOL>
</GROUP>
</MIF>

It will parse it, get the root element, fetch the attribute called
HOSTNAME,
and send the string '\\sami1' to the Debug window. Writing the same in VB
or Java is much easier, of course.

First we include the header file for the component. Then we call
CoCreateInstance with CLSID_XMLDocument and a pointer. CoCreateInstance
is a standard Windows call. The other arguments are not important.

The pointer, pDocument, is a pointer to an instance of the abstract base
class IXMLDocument, declared in the header file. Your C++ knowledge
applies from here on out; we just exercise some of those IXMLDocument
methods to do some work.

The MSDN's Dr. GUI appears to be writing an introduction to COM on
the web site. VC has several wizards for generating components, but
I suggest understanding them on a fundamental level first.

"You've skipped over tons of detail!" Yes, there's a lot more. COM itself
is simple; you can learn the basics in an hour or two. But many standard
interfaces have been defined now for OLE, ActiveX controls, scripting, etc.
Learning these may take a while. But to use DirectX, you'll need an
understanding of COM anyway. Some parts of the shell may only be
extended using COM. Your COM knowledge will be very leveragable.

Sam Inala

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Jason Hoffoss (Tclord) <hof...@volition-inc.com> wrote in article
<34f3d068....@192.48.96.24>...


> On 22 Feb 1998 21:11:10 GMT, "Sam Inala" <sa...@ersatz.microsoft.com>

> >It seems like two approaches have been suggested:
> >1. Reinventing the wheel (write parser, compiler, and virtual machine)
> >2. Reusing a wheel (embedding Scheme, Tcl, Lua)
> >
> >How about a third approach?

> >3. Interchangeable wheels (expose the game's object model) [using COM]


>
> One thing I see about this is that it might take longer to learn this
> stuff than to use one of the first 2 methods.

Yes, it will. Maybe if you ignored everything but what you need for
scripting, it wouldn't take much longer, but I doubt it. Afterwards,
exposing an object model would be faster, I'm sure.

A Sun engineer once said that he classified people by the
time frames they operated in: milliseconds, microseconds,
nanoseconds, etc. Similarly, you could ask: how long will
people be writing scripts for my program?

Days: Scripting is not appropriate. Use C/C++/DLLs.
Weeks: Macro processing, recursive descent compiler with VM
Months: Embeddable language / Object model.

> Also, I'm not sure if COM object just give you access to functions or
> to data as well, but if you allow access to the data, then you will
> lose the advantage of validating the data.

COM never allows direct access to data. Data may only be
accessed through methods. However, in languages like VB,
it will *look like* you are accessing a property directly. E.g.

' VB code
Debug.Print( dxmPlayer1.FileName )

actually calls a C++ method,
CDirectShowPlayer::get_FileName( BSTR* pbstrFilename ).

If you know the Eiffel language, this is like its concept
of referential transparency. Whether data is retrieved by directly
accessing a member variable or by executing some code is
abstracted away. Access is always validated, making only
scripting errors possible.

> [..] And lastly, for me anyway, it's fun to write a compiler,


> and I think it's always good to know as much as you can. Writing a
> compiler can teach you a number of things.

I agree. People who do this might like Jon Bentley's _More
Programming Pearls_, which discusses some little language
design. Also good is the neglected _Writing Interactive Compilers
and Interpreters_ and _Write your own programming
language in C++_.

If you wanted to be cool you could extend an embeddable
language to understand scriptable objects, like they did for Perl.
I'd like to see a COM savvy Forth or Lisp.

Wilbur Streett

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Sam,

Thanks for demonstrating why all of the languages that are coming out of
Microsoft suck, as in there's more to a scripting language than exposing
"objects".

And a perfect example is how great a scripting language ASP is, Microsoft
can't even get their own web pages working properly with it.

Take your advocacy somewhere where people care.. or actually back up your
bullshit with real statements of "fact".

Wilbur
-----------------------------------------
Putting a Human Face On Technology ;-)
-----------------------------------------

John Scholes

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Wilbur Streett writes

>Sam,
>
>Thanks for demonstrating
<a few points about MS>

A little harsh, I mean it is not as if CORBA type stuff was invented by
MS. The funny thing is you would thing it was. Scarcely a week goes by
without another breathless instalment of amazing technology from the
Lovable Nerd.

Isn't it wonderful how well it all works! And the wonderful free
entertainment, of quite unexpected types. Did you know, for example,
that W95 trashes other OSs when you instal it in a multiple boot
configuration. I have no hair left. I ripped it all out in frustration.
[I am still hopeful of sorting it out, though, with the help of the
indispensable System Commander manual. And the bottle of Regrow :)]

So give credit where it is due. They are *brilliant* at marketing (and
one or two other less savoury things ...)

--
John Scholes

Sean Timarco Baggaley

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

In article <01bd3fd6$65506240$f255389d@sami1>, Sam Inala
<sa...@ersatz.microsoft.com> writes

[...]

>Gee, this looks just like Visual Basic events!

>It seems like two approaches have been suggested:


>1. Reinventing the wheel (write parser, compiler, and virtual machine)
>2. Reusing a wheel (embedding Scheme, Tcl, Lua)

Close: but you're missing the advantages of having a bespoke scripting
language...

>How about a third approach?
>3. Interchangeable wheels (expose the game's object model)

>Exposing the object model means that your game implements
>some standard COM interfaces.

1: Not everybody writes [games] for Win95 -- many games are written for
*consoles*.

2: MS do not support COM on a Sony Playstation.

> Then you can use any scripting
>language you want: Visual Basic, Java, C++, Perl, etc. You
>can easily add custom events to be fired to any object and
>custom properties and methods. Scripting support is lightweight
>and mostly trivial to implement using ATL. Plus, you can leverage
>the already existing knowledge of one million VB coders.

VB coders? Surely you jest!

The whole *point* of creating a simple scripting language (for an
gameplay-centric game at least) is to make it easier for the *creative*
types to get in on the act. The people who should be using the scripting
engine are those who will create the core gameplay, tweak the puzzles,
fine-tune the AI, create the logic puzzles, provide the speech trees and
such like.

There's a big difference between scripting support and extensibility.

If 'making life easier for the programmers' is your only reason for
creating a scripting engine, then you are utterly missing the point;
DLLs [as ID are using in Quake 2] would be just as effective.

But if you want to allow your game designer(s), artists and writers to
fiddle around with the gameplay until it fair reeks of 'Addict-O! The
Wonder Polish for Games!' then aiming for a bespoke, *simple to use*
scripting language is the best route. (Although 'script-generation'
front-ends should not be ruled out.)

--
Sean Timarco Baggaley

<mailto:stim...@cix.co.uk>

Of course, if I've just jumped into the middle of a 'How Do I Write Quake'
thread, feel free to ignore this entire post...

E&OE

Paul Bleisch

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote:
>Sam,
>
>Thanks for demonstrating why all of the languages that are coming out of
>Microsoft suck, as in there's more to a scripting language than exposing
>"objects".
>
>And a perfect example is how great a scripting language ASP is, Microsoft
>can't even get their own web pages working properly with it.
>
>Take your advocacy somewhere where people care.. or actually back up your
>bullshit with real statements of "fact".
>

Hmm... I thought what he said was very useful if people want to understand
how COM handles interlanguage issues. Yes, a scripting language is more
than exposing objects, but in general, most people want to just expose
objects to the scripting environment. While I don't think VBA is a great
language, it has the advantage of making use of COM objects and doing so
very easily.

Personally, I use LUA with COM objects in a similar manner and found that
VBA and the peoples at MS to be very helpful in making my project work.
Eventhough it doesn't make them any money and Lua is a free software project.

Paul

Paul Bleisch

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Sean Timarco Baggaley <stbag...@hotmail.com> wrote:
>
>1: Not everybody writes [games] for Win95 -- many games are written for
>*consoles*.
>
>2: MS do not support COM on a Sony Playstation.


Indeed they don't. Doesn't mean you can't. I use COM on Linux,
an unsupported platform. The COM spec is available and is actually
very easy to get up and moving.

If you don't like COM (I'm sure for noble reasons) then there are
still many advantages to what is being suggested.


>There's a big difference between scripting support and extensibility.
>If 'making life easier for the programmers' is your only reason for
>creating a scripting engine, then you are utterly missing the point;
>DLLs [as ID are using in Quake 2] would be just as effective.

I use Lua because I like the language more than C++. The COM/Lua
integration makes life easier and overall, I can design test and
use new algorithms quicker in Lua/COM/C than in straight C or C++.
There are many reasons to use a script based language.


Word,
Paul


Wilbur Streett

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

pble...@iago.jeske.meer.net (Paul Bleisch) wrote:

>Hmm... I thought what he said was very useful if people want to understand
>how COM handles interlanguage issues. Yes, a scripting language is more
>than exposing objects, but in general, most people want to just expose
>objects to the scripting environment. While I don't think VBA is a great
>language, it has the advantage of making use of COM objects and doing so
>very easily.

And we all base our object models on COM, now don't we?

>Personally, I use LUA with COM objects in a similar manner and found that
>VBA and the peoples at MS to be very helpful in making my project work.
>Eventhough it doesn't make them any money and Lua is a free software project.

VBA has shown itself time and time again to be useless. It's been
available for free for a few years now, and how many games are using it?

I could replace "object" with "internals of a game" and the argument would
be the same, with with specifying COM, the scripting language looks like
shit.. there are plenty of examples out there, and none of them are
useful.

Wilbur Streett

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

pble...@iago.jeske.meer.net (Paul Bleisch) wrote:

>
>Indeed they don't. Doesn't mean you can't. I use COM on Linux,
>an unsupported platform. The COM spec is available and is actually
>very easy to get up and moving.

Oh, the COM spec. Instantiate, and do a version check. So useful.

Such a wonderful specification.

Paul Bleisch

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote:
>
>And we all base our object models on COM, now don't we?

No, but knowing how something else *actually* works can be a great
benefit now can't it? Whether or not you like COM shouldn't matter.
You had damn well better be able to determine what is wrong with it
and why, or else you are eventually going to miss something. COM
is so lightweight, I don't understand why everyone isn't using it.
(Actually, I have a pretty good idea why people don't use it and it
has mainly to do with having too many ways to do something.)

>VBA has shown itself time and time again to be useless. It's been
>available for free for a few years now, and how many games are using it?

I couldn't give two squirts whether anything is using it, I wanted to know
how the integration worked and they helped me out.


>I could replace "object" with "internals of a game" and the argument would
>be the same, with with specifying COM, the scripting language looks like
>shit.. there are plenty of examples out there, and none of them are
>useful.

Can you rephrase this? I am not sure what you are saying here.

Paul


Paul Bleisch

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote:

>pble...@iago.jeske.meer.net (Paul Bleisch) wrote:
>
>Oh, the COM spec. Instantiate, and do a version check. So useful.
>Such a wonderful specification.

What the hell are you talking about? The spec I was talking
about is available at http://www.microsoft.com/cominfo/
You need to make an effort to actually complain about something here.
I know there are problems with COM, but overall, it is actually
the best solution for alot of problems. The slip-up with COM
has actually been the confusion produced by the renaming and
hand-waving that MS marketing did a couple years ago.

Paul


Wilbur Streett

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

pble...@iago.jeske.meer.net (Paul Bleisch) wrote:

>Wilbur Streett <WStr...@shell.monmouth.com> wrote:
>>
>>And we all base our object models on COM, now don't we?
>
>No, but knowing how something else *actually* works can be a great
>benefit now can't it?

And a great waste of time as well.

COM has demonstrated that it doesn't work. COM is OLE, COM is ActiveX, COM
is everything and the kitchen sink, COM is the Microsoft. It doesn't work,
it's a mess.. and it binds you into the proprietary, bug ridden Microsoft
architectures.

>Whether or not you like COM shouldn't matter.
>You had damn well better be able to determine what is wrong with it
>and why, or else you are eventually going to miss something. COM
>is so lightweight, I don't understand why everyone isn't using it.
>(Actually, I have a pretty good idea why people don't use it and it
>has mainly to do with having too many ways to do something.)

So it's not a decent architecture.. you admit it. 3 different ways to do
the same thing doesn't lead to working technology, it leads to technology
that's never been fully exercised, and the implementations are bug ridden
and remain bug ridden. You spend all of your development time figuring out
why objects don't work as documented, (if you can even find the
documentation in the first place..)

>>VBA has shown itself time and time again to be useless. It's been
>>available for free for a few years now, and how many games are using it?
>
>I couldn't give two squirts whether anything is using it, I wanted to know
>how the integration worked and they helped me out.

Because you asked them.. Ask the same questions on comp.compilers and you
get better non-proprietary answers. In case you didn't notice, if the
product isn't being used, that's because it DOESN'T WORK.

>>I could replace "object" with "internals of a game" and the argument would
>>be the same, with with specifying COM, the scripting language looks like
>>shit.. there are plenty of examples out there, and none of them are
>>useful.
>
>Can you rephrase this? I am not sure what you are saying here.

OBJECT is a generic term that has been overutilized to the extent of being
useless.

Any scripting langage that simply exposes the underlying object model is in
effect providing a more obtuse and more complicated method to access the
object model than a direct implementation would. Check out the scripting
on web pages that are accessing the underlying "object" model, What you'll
see is

object.method("parm", "Parma", 2)..
object.method2("parm", "Parma", 2)..
object.method3("parm", "Parma", 2)..
object.method4("parm", "Parma", 2)..
object.method5("parm", "Parma", 2)..
object.method6("parm", "Parma", 2)..
object.method7("parm", "Parma", 2)..

Hardly a worthwhile language. Almost unreadable..

Sam Inala

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote in article
<34f0f3a7....@news.monmouth.com>...
> Take your advocacy somewhere where people care.. [..]

My apologies, Wilbur. I will write less in the future.

I try to avoid advocacy; my tastes are mostly catholic.
I admit that your further comments merely confused me.

If people will only consider developing scripting
languages from scratch, how about this alternative:

Use a token threaded Forth, similar to the one
in the OpenBoot PROMs in Sun computers.

Advantages:

* Much faster than an traditional interpreters.

* Very compact. Forth is most used in embedded
environments because of the small size of the
inner interpreter. 4k is typical. Indeed, Java
uses a similar architecture because of the
compactness of zero-operand machines.

See Phil Koopman's _Stack Computers_
for some comparisons.

* Extensible: The CREATE> .. DOES>
pair allow you to extend the language itself,
similar to Lisp macros. You can build a
forth on a base of 10-20 words, after which
everything may be written in the language
itself. This also makes it easy to port.

Resources:
_Starting Forth_ by Leo Brodie
_Thinking Forth_ by Leo Brodie
comp.lang.forth

Sam Inala

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Meta note: For at least the next month, I will not be
posting to this newsgroup. I hope you don't mind
direct mail, but I don't wish to be involved in random flames.

Sean Timarco Baggaley <stbag...@hotmail.com> wrote in article
<v1A5IDAW...@cix.co.uk>...


> In article <01bd3fd6$65506240$f255389d@sami1>, Sam Inala
> <sa...@ersatz.microsoft.com> writes

> >Gee, this looks just like Visual Basic events!
>
> >It seems like two approaches have been suggested:
> >1. Reinventing the wheel (write parser, compiler, and virtual machine)
> >2. Reusing a wheel (embedding Scheme, Tcl, Lua)
>
> Close: but you're missing the advantages of having a bespoke scripting
> language...

That's true. I thought about addressing this. After all the principal
advantage of a scripting language is what Amit alluded to in his post:
being able to encapsulate the common logic of a game into the
language itself. Awk scripts, for example, are compact because
the filter code is ingrained in the language.

> >How about a third approach?
> >3. Interchangeable wheels (expose the game's object model)
>
> >Exposing the object model means that your game implements
> >some standard COM interfaces.

> [..vb is too hard for creative types..]

Well, you would know; I have not worked with such people.
Most of the simple scripting languages I've seen are much
harder than VB (take the Jedi Knight scripting language, e.g.)

Keith Elder

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Sam Inala wrote:
>
> If people will only consider developing scripting
> languages from scratch, how about this alternative:
>
> Use a token threaded Forth, similar to the one
> in the OpenBoot PROMs in Sun computers.
>
> Advantages:
>
> * Much faster than an traditional interpreters.
>
> * Very compact. Forth is most used in embedded
> environments because of the small size of the
> inner interpreter. 4k is typical. Indeed, Java
> uses a similar architecture because of the
> compactness of zero-operand machines.
>
> See Phil Koopman's _Stack Computers_
> for some comparisons.
>
> * Extensible: The CREATE> .. DOES>
> pair allow you to extend the language itself,
> similar to Lisp macros. You can build a
> forth on a base of 10-20 words, after which
> everything may be written in the language
> itself. This also makes it easy to port.
>

In fact, there is a Forth implementation written
in C, which is explicitly designed to function as
a scripting language for large C programs. It
is public domain. I am toying with the idea of
using it for my game, and am pretty impressed
with it. It is called ATLAST, and can be
found at:

http://www.fourmilab.ch/

(a very interesting web site, even if you aren't
interested in the ATLAST code.)

Keith Elder
el...@cdsnet.net

Justin Heyes-Jones

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

On Mon, 16 Feb 1998 07:09:05 -0000, "Matt" <gue...@usa.netNOSPAM>
wrote:

I have an idea for using Java to do game scripts like those you are
after. What I imagine is a cut down virtual machine where the java
objects represent attributes and methods in your core game code.

Mappers/Designers then write the java code which is pointer free, type
safe and I hope clear and easy-ish to learn. You don't use any
standard java classes in the machine, unless you implement them in
your game.

Take the .java code and produce fast C,C++ or ASM source which can
then be compiled with you game engine on whatever platform.

Any comments?

>Hey all,
>
>I am in the process of planning this game and have decided to add a

Paul 'Ozymandias' Harman

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Justin Heyes-Jones wrote in message <34f299ca.4869834@probe-nt-2>...

>On Mon, 16 Feb 1998 07:09:05 -0000, "Matt" <gue...@usa.netNOSPAM>
>wrote:
>I have an idea for using Java to do game scripts like those you are
>after. What I imagine is a cut down virtual machine where the java
>objects represent attributes and methods in your core game code.
>
>Mappers/Designers then write the java code which is pointer free, type
>safe and I hope clear and easy-ish to learn. You don't use any
>standard java classes in the machine, unless you implement them in
>your game.


The Java back-end is a good idea, I reckon: having a virtual machine
interpreter rather than directly interpreting the source at run-time.

But I have to wonder... are your level designers going to be programmers?
Maybe, maybe not. So perhaps Java would not be a brilliant language to use.
Perhaps you want something like AppleScript (on the Mac) - something closer
to English.

So you wouldn't have commands like

object.setposition(32,567);

You'd say:

Set position of object to (32,567);

Ozzy

--
+-+ Paul Ian Harman +-+-+-+-+-+-+- Ozzy +-+ Games Guru & Sci-Fi Admirer +-+
-+- oz...@kasterborus.demon.co.uk +-+ http://www.kasterborus.demon.co.uk -+-

Justin Heyes-Jones

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

On Tue, 24 Feb 1998 10:54:39 -0000, "Paul 'Ozymandias' Harman"
<oz...@kasterborus.demon.co.uk> wrote:

>But I have to wonder... are your level designers going to be programmers?
>Maybe, maybe not. So perhaps Java would not be a brilliant language to use.
>Perhaps you want something like AppleScript (on the Mac) - something closer
>to English.
>
>So you wouldn't have commands like
>object.setposition(32,567);
>You'd say:
>Set position of object to (32,567);

That's my main issue with this, is whether you're going to be able to
get so called non-programmers writing Java. However, I've seen mappers
use some complex tools in the past. And without pointers java becomes
a lot easier than C too teach.

I'm certain that you're example is within the grasp of the mappers.
You could auto generate things like threads to control in game objects
and allow mappers to fill in blanks. Imagine this fictious source code
for a simple proximity mine's main loop.

public void run()
{
if( this.distanceToPlayer < 500 )
{
this.destroySelf( BIG_EXPLOSION );
}
}

There's certainly a lot they can do without having to do hard core
programming.


Paul Bleisch

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote:
>pble...@iago.jeske.meer.net (Paul Bleisch) wrote:
>
>COM has demonstrated that it doesn't work. COM is OLE, COM is ActiveX, COM
>is everything and the kitchen sink, COM is the Microsoft. It doesn't work,
>it's a mess.. and it binds you into the proprietary, bug ridden Microsoft
>architectures.

That's odd, I write COM component based applications all the time and
they work just fine. Maybe I'm just lucky, or maybe I actually put
out an effort to understand what is wrong with the components and
fix them.


>So it's not a decent architecture.. you admit it. 3 different ways to do
>the same thing doesn't lead to working technology, it leads to technology
>that's never been fully exercised, and the implementations are bug ridden
>and remain bug ridden. You spend all of your development time figuring out
>why objects don't work as documented, (if you can even find the
>documentation in the first place..)

My statement had to do with the fact that there are a bunch of ways to
develop COM components and that MS should have just stuck to using IDL.
But since they didn't, it has allowed me to use MIDL generated headers
under Linux.

>Because you asked them.. Ask the same questions on comp.compilers and you
>get better non-proprietary answers. In case you didn't notice, if the
>product isn't being used, that's because it DOESN'T WORK.

Actually, I asked on comp.compilers and comp.lang.perl and no one on
either group could explain it and the only 'answers' I got were "Don't
use COM, it's from Microsoft." or "I don't know, but I'm sure you can't
get it to work because Microsoft doesn't want you to use anything but
VBA."


>Hardly a worthwhile language. Almost unreadable..

Ah.. I dunno, the couple people that have been using the COMLua
stuff have said they dig it. This is mainly due to the fact
that Lua is a table based language. This makes my COM components
that are exposed to the LUA environment look very similar to the
fully Lua based objects. For example, my test app is a little
web tool that uses the MS IE component:

-- Test COMLua
--
MSIE = CoCreateObject("Shell.Explorer");
if( MSIE == nil ) then
print( "Word to ya homey, MSIE not installed" );
exit();
end

-- print out function documentation
--
PrintDoc(MSIE.GoHome);
PrintDoc(MSIE.Navigate);

MSIE.Height = 640;
MSIE.Width = 480;
MSIE:GoHome();
MSIE:Navigate("http://www.acm.org");
MSIE:GoBack();
MSIE:GoForward();


I think this is very readable and allows me to test com objects
very easily.

Paul

Wilbur Streett

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

pble...@iago.jeske.meer.net (Paul Bleisch) wrote:

:>>COM has demonstrated that it doesn't work. COM is OLE, COM is ActiveX, COM
:>>is everything and the kitchen sink, COM is the Microsoft. It doesn't work,
:>>it's a mess.. and it binds you into the proprietary, bug ridden Microsoft
:>>architectures.
:>
:>That's odd, I write COM component based applications all the time and
:>they work just fine. Maybe I'm just lucky, or maybe I actually put
:>out an effort to understand what is wrong with the components and
:>fix them.

And you spend how much of your time fixing Microsoft's technology? I write
applications that use standard technologies, so I don't have to worry about
fixing Microsoft's screw ups.

<snip>

> -- Test COMLua
> --
> MSIE = CoCreateObject("Shell.Explorer");
> if( MSIE == nil ) then
> print( "Word to ya homey, MSIE not installed" );
> exit();
> end
>
> -- print out function documentation
> --
> PrintDoc(MSIE.GoHome);
> PrintDoc(MSIE.Navigate);
>
> MSIE.Height = 640;
> MSIE.Width = 480;
> MSIE:GoHome();
> MSIE:Navigate("http://www.acm.org");
> MSIE:GoBack();
> MSIE:GoForward();

Oh yeah, that's beautiful code.. ;-P

Robert Blum

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett wrote:
>pble...@iago.jeske.meer.net (Paul Bleisch) wrote:
>

[snip talk about COM]


>
>And you spend how much of your time fixing Microsoft's technology?

Less time than coming up with an own technology for binary objects.

>I write
>applications that use standard technologies, so I don't have to worry about
>fixing Microsoft's screw ups.

And what exactly *is* a standard technology that can be used instead of COM?
(Please, don't say CORBA. )
I'm not exactly an MS fan, but introducing VBX/OCX was a *big* step forward
concerning visual programming.

><snip>
>
> > -- Test COMLua
> > --
> > MSIE = CoCreateObject("Shell.Explorer");
> > if( MSIE == nil ) then
> > print( "Word to ya homey, MSIE not installed" );
> > exit();
> > end
> >
> > -- print out function documentation
> > --
> > PrintDoc(MSIE.GoHome);
> > PrintDoc(MSIE.Navigate);
> >
> > MSIE.Height = 640;
> > MSIE.Width = 480;
> > MSIE:GoHome();
> > MSIE:Navigate("http://www.acm.org");
> > MSIE:GoBack();
> > MSIE:GoForward();
>
>Oh yeah, that's beautiful code.. ;-P

It's not a question of beauty. It's a question of things getting done
quickly. That's the whole point of scripting languages.
And the above is one of the quickest ways to display HTML in your program.

Apart from that: I don't see any _beautiful_ way to resize a window and go
to a certain web page. Is there one?


Bye,
Robert

Paul Bleisch

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

Wilbur Streett <WStr...@shell.monmouth.com> wrote:
>And you spend how much of your time fixing Microsoft's technology? I write

>applications that use standard technologies, so I don't have to worry about
>fixing Microsoft's screw ups.

Man, I guess I need to speak clearly and slowly. The 'fix them' comment
was about fixing components that I develop. As in, if developers would
take some time to understand what was happening then the quality of
components would increase. This is not MS's fault. There is nothing
inherently wrong with COM. It works as advertised. The components that
third party developers write may suck, but alot of this has to do with
the fact that a) they don't understand component software or b) they
don't care.

So what standard technologies do you use that clears up all these worries?


Word,
Paul


James Slaughter

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Sam Inala wrote in message <01bd40fa$9f691e70$f255389d@sami1>...


>
>Wilbur Streett <WStr...@shell.monmouth.com> wrote in article
><34f0f3a7....@news.monmouth.com>...
>> Take your advocacy somewhere where people care.. [..]
>
>My apologies, Wilbur. I will write less in the future.


Actually, I for one appreciated your responses: informative, justified, and
each with good references to find further information; this is totally
unlike (and IMHO far better than) many in rec.games.programmer, keep it up!

>If people will only consider developing scripting
>languages from scratch, how about this alternative:
>
>Use a token threaded Forth, similar to the one
>in the OpenBoot PROMs in Sun computers.
>

Traditionally, I write my own from scratch, purely because programming at
my age is only a hobby, and I find the challenge of doing something myself
far more interesting than the joy of getting something together quickly
through plagiary of someone else's code.

I am curious, though, as to how an implementation of Forth is quicker than
other techniques? I do not program in the language, but if possible, could
you outline briefly why? Is it just that the language lends itself to
simple optimisation, or forces tight code?

My thoughts on COM are that for other programmers, it is an ideal
solution - or at least the approach is sound - I don't know whether it has
the problems mentioned elsewhere in this thread, or whether it is just
Wilber being... himself :).

However, one of the advantages of a script language is that it can be
comparatively simple, which allows the occasional 'enthusiastic' user to
write their own enhancements. This is more important for a game where many
people enjoy writing their own levels - as id (among others) has shown -
than it is for an application where a few 'Power Users' and programmers
will occasionally write a simple 'nigglet' of code to speed something up.

A Visual Basic type system is one solution, but few games developers have
the time to stop and write that kind of thing.

Regards,
James.

John Scholes

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Wilbur Streett writes

<<mucho snipped>>

>>No, but knowing how something else *actually* works can be a great
>>benefit now can't it?
>
>And a great waste of time as well.
>

>COM has demonstrated that it doesn't work.

>So it's not a decent architecture..

>>I couldn't give two squirts whether anything is using it, I wanted to know


>>how the integration worked and they helped me out.
>
>Because you asked them..

<and more>

I think you could be missing the point here, Wilbur. I apologize for
asking a Real Newbie Question. But indulge me a little, just to avoid
misunderstandings, is it your premiss that the whole DCOM thing is
intended to be useful?

I don't want to enter into a long rant if we are at cross-purposes here.

I mean you do believe that the Mr BG, the richest man in the world,
loves you dearly and cares about nothing except you welfare, don't you?
You do realize that he has been grievously misunderstood and
misrepresented, don't you?

You do believe that he is a former nerd, who loves coding and wants
nothing more than to make coders little lives easier? You do appreciate
that he is not a Rotten B****** Suit, that he is different ...


--
John Scholes

John Scholes

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Sam Inala writes

>
>> Take your advocacy somewhere where people care.. [..]
>
>My apologies, Wilbur. I will write less in the future.
>
>I try to avoid advocacy; my tastes are mostly catholic.

Hey Sam! Are you really from MS? You sound so much like a coder, I did
not realize.
Look I have this small problem. I am trying to install the following on
my hard drive:

primary 1: Win95
primary 2: DOS6/Win3.1
primary 3: NT4
primary 4: redhat5

I know this sort of thing is a bit silly really. It's just that I am
short of money and want to use the same machine as a test-bed for some
code I am trying to write.

Anyway, I know how good you guys are about supporting developers. You
give us all this absolutely amazing stuff at such giveaway prices, and
there is always another goodie just around the corner. It is really ...
well, I guess, I never was much good with words, I just cannot
adequately express what I feel about it all ...

But back to the point. The thing is it is proving unexpectedly awkward.
I know it is my fault, really. I cannot get rid of this unreasonable
feeling that it would be nice if setup thingies set things up. Silly
really. But the real problem is that one or two really strange things
seem to happen. I mean, I am almost tempted to give up hope sometimes.
It is only the thought of all you guys giving us this Amazing Stuff at
such amazing prices that keeps me struggling on ...

I cannot afford any more of these new Priority Support Calls things. So
I was wondering, as a special favor, whether you might be able to pull a
few strings and get one of the guys to help me out. You know, on an
unofficial basis.

There is another slight difficulty. I seem to have a problem with the
this marvellous winmodem they told me so much about. But I was always
hopeless at comms. So maybe it would be best it we did the whole thing
on usenet (I managed to retrieve an old machine with some of that old
Win3.1 stuff on it which still works, provided you do not stay on it too
long. Goodness, when I look back you did an amazing job in those days.
Mind you. I guess things were easier then. There wasn't all this
unstandardized hardware around).

Come to think of it, others might pick up a few hints too. But maybe
not. I guess no one could be as stupid as me. I am 40 hours into it and
still not quite there, somehow. Never mind. I am sure that with your
help I soon will be.

--
John Scholes

Russ Williams

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

John Scholes wrote in message <72$62aBmr...@kalva.demon.co.uk>...

>Look I have this small problem. I am trying to install the following on
>my hard drive:
>
>primary 1: Win95
>primary 2: DOS6/Win3.1
>primary 3: NT4
>primary 4: redhat5

What exactly do you mean by 'primary' for these? You mention your
hard drive (singular) above, yet this seems to suggest 4 drives with
primary partitions.

Doesn't Linux have a boot-disk option? With a DOS boot disk
you can get DOS6/Win311, and Win95/NT4 co-exist quite happily
(if you install Win95 first...)
If you've got Win95, pre-OSR2, then you can even keep
DOS6/Win311 with the Previous OS option in the F8 boot menu.

---
Russ

Sean T Barrett

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Russ Williams <ru...@algorithm.demon.co.uk> wrote:
>If you've got Win95, pre-OSR2, then you can even keep
>DOS6/Win311 with the Previous OS option in the F8 boot menu.

Ack! They took that out of OSR2?! Oh well, so
much for trying to scam up a copy of OSR2 just
so I don't have to partition my 6.4G hard drive
into 5 partitions (5 because I want a couple
megs with <32K clusters--but it takes 4 even with
2.1M per partition).

And don't even get me started on that. Oh,
too late. I can't believe how here and on the
IBM PC newsgroups people say how it's cheap
and easy to upgrade, but nobody mentions you
can't get FAT32 without buying a new machine--
you're out of luck if you put it together yourself
or just upgrade. FAT32 is _not_ one of the
OSR2 features you can download from MS.

I'm sure they do it for support reasons, but
it pisses me off that the web page is covered
with patronizing "oh, you don't need this unless
you have a new machine" comments. No, you
idiots (they're not really, they're just being
schmoozing marketeers who don't want to say
they don't want to deal with support), you just
need new _hardware_, not a new freakin' machine.

Sean Barrett

John Scholes

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Russ Williams writes

>>Look I have this small problem. I am trying to install the following on
>>my hard drive:
>>
>>primary 1: Win95
>>primary 2: DOS6/Win3.1
>>primary 3: NT4
>>primary 4: redhat5
>
>What exactly do you mean by 'primary' for these? You mention your
>hard drive (singular) above, yet this seems to suggest 4 drives with
>primary partitions.

I mean precisely what I said. I have a single 8GB hard drive. I wish to
partition it to allow multiple boot.

>
>Doesn't Linux have a boot-disk option?

Yes you are correct. It does. So what?

>With a DOS boot disk
>you can get DOS6/Win311, and Win95/NT4 co-exist quite happily

This has to be a wind-up.

Just try to get these charming well-behaved MS OS onto the same physical
drive and see what happens. You have *tried it yourself* haven't you,
Russ?

Come on now Russ. I know you are a big expert and I am an idiot. Now
just tell us precisely what I am doing wrong.

Ok, so I not doing what I am supposed to do. Ok, I need to pay for some
advice. Fair enough. How's about I pay you $100 if you can get this
going in the next 24 hours. This is a serious offer with plenty of
witnesses. Reason. I *really* want to know. This MS stuff is driving me
bananas.

My machine or yours. But just be sure to tell us all *precisely* how you
did it.

It is a brand new just delivered Gateway 233MHz. IBM 8GB hard drive.
Mitsumi 13/32x CD. Supposedly top-end AccelGraphics 8MB card
(documentation and Win95 differ on exactly which one), EV700 17"
monitor. 64MB RAM. No funnies except one of these f***ing, unusable
winmodems. BTW I am about the smash the thing as a public service.
Whatever you do folks don't tangle with them (unless you like the
approved set-up and pre-installed OS and web software, of course).

So how do I do it? I really want to know. It has wasted >30 hours of my
time at this point. $100 will be the bargain of the century. If you can
do it, of course. -$10 for everything I have to tell you about NT, 3rd
party utilities, from this point on? Fair enough?


--
John Scholes

Wilbur Streett

unread,
Feb 25, 1998, 3:00:00 AM2/25/98