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).bobdevis wrote:There is an other Director from Macromedia then this one?
Gadget - Past as Future
Moderator: ScummVM Team
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.
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.
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...
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.
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...
I cannot find any reference to this in the code... although I don't know what I'm searching for?We support NE EXE resources already
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.
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: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?
See common/ne_exe.*stevenh wrote: Otherwise...I cannot find any reference to this in the code... although I don't know what I'm searching for?clone2727 wrote:We support NE EXE resources already
And Mac resource fork parsing is in common/macresman.*
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: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.
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: 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?
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: Otherwise...I cannot find any reference to this in the code... although I don't know what I'm searching for?We support NE EXE resources already
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?
You can just ask questions on -devel or on IRC.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.
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'.
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'.
I have a Director 5.0 demo I can upload later.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.)
Turbo Mac is director, Turbo Windows is not.stevenh wrote:Journeyman Project Turbo is, of course, not even built in Director (the original versions were, as clone2727 listed.)
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
And the Mac demo is only Director.
They're both Director 5.0 apps and hopefully they'll help
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.
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.
-
Strangerke
- ScummVM Developer
- Posts: 335
- Joined: Wed Sep 06, 2006 8:39 am
- Location: Belgium
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: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.
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.)stevenh wrote:Next trick is 'Amber - Journeys Beyond'.
By the way, add The Residents: Freak Show and Bad Day on the Midway to the list.
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.
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.
