Gadget - Past as Future

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

User avatar
LordHoto
ScummVM Developer
Posts: 1030
Joined: Sun Oct 30, 2005 3:58 pm
Location: Germany

Post by LordHoto » Sat Mar 05, 2011 4:06 am

bobdevis wrote:There is an other Director from Macromedia then this one?
Maybe, maybe not, though I pretty much guess it wasn't using Flash nor Shockwave for the games. Just check: Journeyman Project Mac was released in 1993, while Flash and Shockwave was released in 1995 (according to wikipedia).

User avatar
bobdevis
Posts: 563
Joined: Fri Jan 16, 2009 10:52 am

Post by bobdevis » Sat Mar 05, 2011 9:22 am

The Director (that I am talking about) had it's first release in 1985.
Exporting your project to a blob that is loadable by the Shockwave plug-in is not your only option.
You can export to stand-alone executable aswell for example. If you do that and do not use the trial version of Director then the user doesn't have to notice what technology is used.

Anyway, I see now that Flash and Director use diffident scripting languages (Lingo and ActionScript respectively). This suggests, like clone2727 said, that knowledge of Gnash is largely useless.

User avatar
stevenh
Posts: 8
Joined: Thu Mar 03, 2011 4:17 am
Location: Australia
Contact:

Post by stevenh » Sun Mar 06, 2011 10:02 am

Ok, have been mucking around this evening loading the binaries and processing them.... need to do a little thinking out aloud:

Do I want to go through and interpret every line of code? This seems unoptimal when the greater majority of commands are machine language assember jmps, movs, etc... is there a way to 'play' the executable? I imagine this would require actually throwing it up onto the stack rather than loading the bytes into an array.

I've previously worked on Transport Tycoon Deluxe (specifically TTDPatch) where this was done... the executable was renamed into another file and patched to add features and remove bugs. This was then loaded into memory and the stack pointer moved to it. Is this against the principles of ScummVM?

Otherwise...
We support NE EXE resources already
I cannot find any reference to this in the code... although I don't know what I'm searching for?

I've started with Groovie as the basis... as it was the first Script.cpp I saw loading a full file and translating the bytes... is there a better starting point?

Another option could also be to load up the executable into an array, then read the bytes and re-write them into local machine code somewhere on the stack; but this isn't much different from above.

Where would I go to ask developer-oriented questions? I'm subscribed to the scummvm-developer mailing list, but it's pretty quiet. I'll go and join IRC now to see if anyone is awake.

User avatar
clone2727
Retired
Posts: 1592
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Post by clone2727 » Sun Mar 06, 2011 2:17 pm

stevenh wrote:I've previously worked on Transport Tycoon Deluxe (specifically TTDPatch) where this was done... the executable was renamed into another file and patched to add features and remove bugs. This was then loaded into memory and the stack pointer moved to it. Is this against the principles of ScummVM?
Yes, very much against what ScummVM does. How would that work on any platform not running on an x86 processor (or 68k/PPC processor for Mac versions)?
stevenh wrote: Otherwise...
clone2727 wrote:We support NE EXE resources already
I cannot find any reference to this in the code... although I don't know what I'm searching for?
See common/ne_exe.*

And Mac resource fork parsing is in common/macresman.*

User avatar
LordHoto
ScummVM Developer
Posts: 1030
Joined: Sun Oct 30, 2005 3:58 pm
Location: Germany

Post by LordHoto » Sun Mar 06, 2011 2:25 pm

stevenh wrote:Ok, have been mucking around this evening loading the binaries and processing them.... need to do a little thinking out aloud:

Do I want to go through and interpret every line of code? This seems unoptimal when the greater majority of commands are machine language assember jmps, movs, etc... is there a way to 'play' the executable? I imagine this would require actually throwing it up onto the stack rather than loading the bytes into an array.
I am not sure but executing code on the stack seems like a rather odd idea. If you want to implement support for the games in ScummVM you probably want to reverse engineer the game, i.e. disassemble it and reimplement it in C(++).
stevenh wrote: I've previously worked on Transport Tycoon Deluxe (specifically TTDPatch) where this was done... the executable was renamed into another file and patched to add features and remove bugs. This was then loaded into memory and the stack pointer moved to it. Is this against the principles of ScummVM?
Actually we reimplement the game in C(++) rather when doing an recompilation or direct execution. Both of the latter (recompilation and/or direct execution of machine code) are not really what we do (or want in our codebase).
stevenh wrote: Otherwise...
We support NE EXE resources already
I cannot find any reference to this in the code... although I don't know what I'm searching for?

I've started with Groovie as the basis... as it was the first Script.cpp I saw loading a full file and translating the bytes... is there a better starting point?
I am not sure what you are looking at, but if you are interested on how to read resource data from NE executables you should probably look at common/ne_exe.h. It should provide the interface for getting read access to resources embedded in NE executables.
stevenh wrote:Where would I go to ask developer-oriented questions? I'm subscribed to the scummvm-developer mailing list, but it's pretty quiet. I'll go and join IRC now to see if anyone is awake.
You can just ask questions on -devel or on IRC.

User avatar
stevenh
Posts: 8
Joined: Thu Mar 03, 2011 4:17 am
Location: Australia
Contact:

Post by stevenh » Thu Mar 10, 2011 9:09 am

So... an update. "The Dark Eye" is 16-Bit Macromedia Director 4.0. It is also an NE executable which nothing wants to open up, but I believe this is because it's 'packed', although no software wants to tell me what it's packed by.

Journeyman Project Turbo is, of course, not even built in Director (the original versions were, as clone2727 listed.)

Gadget I've been musing over in IDA... but I was hoping to find another Director 5.0 app to compare with... I can't even find a purchasable version of Director 5.0 (would be nice to generate a very simple stage and compare bytes.)

Next trick is 'Amber - Journeys Beyond'.

User avatar
clone2727
Retired
Posts: 1592
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Post by clone2727 » Thu Mar 10, 2011 1:19 pm

stevenh wrote:Gadget I've been musing over in IDA... but I was hoping to find another Director 5.0 app to compare with... I can't even find a purchasable version of Director 5.0 (would be nice to generate a very simple stage and compare bytes.)
I have a Director 5.0 demo I can upload later.
stevenh wrote:Journeyman Project Turbo is, of course, not even built in Director (the original versions were, as clone2727 listed.)
Turbo Mac is director, Turbo Windows is not.

User avatar
clone2727
Retired
Posts: 1592
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Post by clone2727 » Thu Mar 10, 2011 2:56 pm

Orly's Draw-A-Story Windows demo is a Director game that was converted to Mohawk, but the demo comes with the original Director executable that they seem to have left in (or is the launcher, I'm not sure).

And the Mac demo is only Director.

They're both Director 5.0 apps and hopefully they'll help :)

User avatar
stevenh
Posts: 8
Joined: Thu Mar 03, 2011 4:17 am
Location: Australia
Contact:

Post by stevenh » Fri Mar 11, 2011 12:17 pm

clone2727, Thanks heaps for the pointers... definitely coming in handy.

Turns out the resources in the EXE are not where any compiled Lingo is... it all seems to be in the Macromedia Director files (DXR scares me, supposedly 'protected'). Have been reading through the code today. Found that the project executable has two DLLs attached to the end of it which are written to the C:\WINDOWS\ directory. In these are the references to the DXRs, so the Lingo could actually be in them... but a direct HEX compare of the exported files aren't as different as I would've expected...

Either way, I'm digging through the projector to brush up on my disasm skills and also to follow through the memory mapping of the projector. It throws the relevant DLL (32-bit) up near 0xFE00000 and then starts interacting. This should then let me work out how it starts attacking the loaded DXR Director Project. Once I get that in memory I'll watch it work with it.

end of rant.

User avatar
Strangerke
ScummVM Developer
Posts: 333
Joined: Wed Sep 06, 2006 8:39 am
Location: Belgium

Post by Strangerke » Mon Mar 14, 2011 8:12 am

After a check, Pyst uses Director 5.0 (or at least the french version I own)

Jorpho
Posts: 74
Joined: Sun Jan 15, 2006 2:20 am

Post by Jorpho » Tue Apr 05, 2011 3:33 pm

stevenh wrote:I've just coaxed it into running on Windows XP SP3 after an IDAFree debugging session and using OllyDBG to hack a jle to jmp.
I'd be really, really interested in the details of how you did all this. Did you follow a tutorial of some sort somewhere?
stevenh wrote:Next trick is 'Amber - Journeys Beyond'.
Are you aware that someone's already hacked together a patch for Amber? I had been thinking that the same techniques could be applied to other Director games. There's some discussion of the work at http://vogons.zetafleet.com/viewtopic.php?t=2070 ; the actual patch is at http://www.squirtthecat.com/games/amber/index.html . (Ah, but you know about that already.)

By the way, add The Residents: Freak Show and Bad Day on the Midway to the list.

User avatar
stevenh
Posts: 8
Joined: Thu Mar 03, 2011 4:17 am
Location: Australia
Contact:

Post by stevenh » Tue Apr 05, 2011 11:02 pm

Jorpho,

There are seriously no rules for disassembling an application. Assembler is a really good challenge and following it all in a debugger can be a nightmare.

I pretty much just stepped through the code, matching each function call to the function in IDA, reviewing the code in IDA before executing it... and then documenting in IDA in a vain attempt to understand the execution flow.

At the start, it was simple enough, as there were hints to message boxes and messages about insufficient memory. I then back-tracked to where this was jumped in to and realised it did a memory check. The values were all being stored in 16-bit vars which weren't capable of storing the true amount of memory on my machine and therefore I knew the jump would go the wrong way as it was only matching on the lower half of the actual free-memory value. Either way, this jump was based on the days of Win3.11 where Enhanced Memory was a pain... I just changed the value check to a hard 'jmp' so that it skips it altogether.

But that's completely off-topic :) and wont be required in the engine for ScummVM, as none of that code needs to come across.

The patch for Amber would probably apply directly to Gadget. The 'Projectors' are more-or-less byte-for-byte, except for a few resources, and yes, this would make Gadget work fine on Windows... But it's then not much of a hobby for me... I'd love to see this running in Linux, I suppose...

I've currently documented quite a bit of the code, maybe on the mark of 10%. A lot of the start is memory mapping and loading of the 'Xtras'... these are Macromedia support libraries for the main Director player, FileIO and 'Widgets'. I've also worked out where the DXR comes in and am now determining why it gets splattered across a whole lot of memory areas instead of just one. They seem to split it into special sections... which, once I determine what they are, will lead me to the ability to open the DXRs in ScummVM and hopefully then start executing the Lingo.

Progress is being made but, as per usual, time+motivation are always a factor. I'll keep you all updated when I hit the good bits.

User avatar
stevenh
Posts: 8
Joined: Thu Mar 03, 2011 4:17 am
Location: Australia
Contact:

Post by stevenh » Fri Apr 15, 2011 10:08 am

Gomenasai for the Double Post(TM)...

I was so hoping this would export to a "Windows" format... but it turns out the bytes are just swapped... should be easy to deal with as I want to be able to load MAC DXRs as well!

Image

Image

Image

More to come as I find the time to hack DWORDS.

User avatar
clone2727
Retired
Posts: 1592
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Post by clone2727 » Fri Apr 15, 2011 11:48 am

stevenh wrote:I was so hoping this would export to a "Windows" format... but it turns out the bytes are just swapped... should be easy to deal with as I want to be able to load MAC DXRs as well!
Well, we have a nice Common::SeekableSubReadStreamEndian class that would work well for you here. :)

Post Reply