[GD-General] RE: Gamedevlists-general digest, Vol 1 #284 - 10 msgs

[Jeff L. <je...@SP...>]

> > Because when push comes to shove, Windows is *still* just DOS - it still
> > requires a PATH environment variable of ";" seperated directory names to
> > search - in fact, with the latest versions of Windows, Microsoft is
> > disparaging the idea of putting your DLL's into the system 
> directory, but they don't give adequate documentation or support of the 
> API's required to insert directories into the search path.

> Hmm.. Sooo.. you can't do something like LoadLibrary(MyExeLocation +
> \\MyLibrary.dll); ??

This only works if you softlink to everything, and doesn't if the DLL you
are loading hard-links to something not visible in the path.  Been there,
done that.  My application (not technically a game) does lots of chdir()
operations while dynamically loading DLL's to ensure that the current
directory is optimal for softlinking support.

Sure, you can set your APP up this way, but in general terms, it pushs up
the error rate enormously since you can't tell that you have your
application built correctly till RUNTIME when you discover all the missing
entry points.

> Only if he's an admin(which is the root of so many problems..), and if he
> is, he can screw up many more things.

If he can't write to that directory, he can't write a preference file into
it.
If he can, he can erase its contents.  As I recall.
Windows != Unix, there is no "chmod a+t" here.

> > you like, but understand that its your config.
> That's a fun idea, there. For the adventurous type, you could use the hash
> that email uses for binary attachments and shove it all into a human
> readable xml file. Could get big, though...(MD5, I think?). 
> Might be fun to try out in someone's small puzzle type game. oo, oo... if
you 
> wanted real fun you could Zip the xml, so humans who wanted to read it 
> would just WinZip it and life would be good. Hmmmm..

I'm not quite sure what you are getting at here.  I'm envisioning that
instead of having a readily visible Quake.app icon, I have Jeffs Quake and
Paulines Quake icons - double-clicking those load up Quake.app and pre-load
my, or her, preferences and thus open the correct save games, mouse
settings, etc.

The application would install, by default, a "New User" icon which you can
either double-click (and it magically detects that you are requesting that a
new set of user prefs be created), or perhaps you just duplicate it and
rename it.

> > Of course, on Windows, this means needing unique file types 
> (since thats
> how
> > the registry maps files to apps), but on MacOS it works beautifully.
> Better go look up how MacOS works...

Files can have "types" and "owners" which are independent of filename
extensions.  The Finder just "knows" that files owned by "8PBM" (?) should
be opened by Photoshop, files owned by "R*ch" (?) should be opened by
BBEdit, etc.  Each app is supposed to have its own unique signature handed
out by Apple.  MacOS has worked this way since day one.

Windows, on the other hand, just looks in HKCR\(.extension) and does some
arcane indirection through great long CLSID entries before eventually
settling on a command-line it should run, or a DDE message it should send.
Works ok, but restricts the user to having to include extensions like ".doc"

(The only plus side I see to the Windows world comes when I've edited web
pages with DreamWeaver - it saves itself as the owner so double-clicking the
.html file does not load a browser, it loads the editor.  And this is an
annoyance, not much else)

> > The truly innovative could, however, write a tiny app that functioned as
a
> > LAUNCHER, that stored the preferences back into itself as resources, and
> > passed values on perhaps through environment variables, a command-line
> > option or a temporary file.
> That'd be a fun SourceForge project I bet.

To my eye, it'd be a few days work to do the whole thing, given that the
launcher only has to:

a) load and run another application

Since the registry probably has your install directory anyway, its a
registry read, and a ShellExecute()

b) act as a REPOSITORY for preferences

You'd probably do this by having the launcher app have a few documented
entry points that could be accessed via LoadLibrary().

Its up to Brian's library to store the actual preferences into the library
(which he'd do by simply opening the launch application, soft-linking to a
few dynamic entry points and calling them)

Its up to the user of Brian's library to provide UI for the preferences.

Jeff Laing <je...@sp...>
----------------------------------------------------------------------------
---
"Meetings.  Don't we love meetings?  Every day.  Twice a day.  We talk." He
got
on one elbow.  "I bet if I blew the conch this minute, they'd come running.
Then we'd be, you know, very solemn, and someone would say we ought to build
a
jet, or a submarine or a TV set."       -- William Golding, "Lord of the
Flies"