Alright....those who know Delphi code, Gather 'round!

  • Thread starter Thread starter Goku7
  • Start date Start date
Status
Not open for further replies.
G

Goku7

Guest
Forgive me if I've already mentioned this before, but I believe I have finally hit upon the best solution to fix the current problem our FF8config program has with ffaddon files that are compressed using WinRAR 3.0 and above, without needing to update the actual RAR compression code currently used in the config program.....or constantly falling back to older versions of WinRAR for making compatible files.

As far as I know, the current version of the FF9 mod (version 2.1 for Samuel's DLS) on the FFSF site is the only one suffering from the problem. Specific information on the problem was posted several months ago by me in this thread, for those of you who don't know what happened.

My solution is this: we don't necessarily have to code the actual algorithim into the config -- Why not recode the program to instead use self-extracting rar files as the .ffaddon format, and have the program make calls to run the exe part of the self-extracting file?

In theory, this would eliminate the need to update the program to deal with the newer algorithms, because the self-extractor would already have the newer code in it.  It would allow the config program to install ffaddon files regardless of what version of WinRAR made it, and should be forward-compatible for some time.

Of course, we wouldn't want the config to simply check to see if the file is an executable and blindly run it :roll:.  Now, I'm guessing that self-extracting archives (both of the .zip and .rar formats) contain some information in the file header that identify the program as a self-extracting archive.  Assuming I'm right, we could then have the program read the file header, and if it does not indicate that it is a .rar self-extracting archive, then return an error saying it is not an .ffaddon file, or a corrupt one.

So, coders, what do you think?  Fice? Dag?  Anyone with delphi experience? :D
 
Hi!

It would take a bit of work, but it's possible! I use Delphi, and am quite experienced. The only thing that I lack is the one thing that is most needed in this department. That thing is reading from external files and running selected code from them. Ficedula shouldn't have any problem with that. Howeve, I have heard that he is quite busy at the moment...  :-?

I'll be happy to help with what I can! Keep me posted!  :D

xeriouxi.
 
Hi!

It would take a bit of work, but it's possible! I use Delphi, and am quite experienced. The only thing that I lack is the one thing that is most needed in this department. That thing is reading from external files and running selected code from them. Ficedula shouldn't have any problem with that. Howeve, I have heard that he is quite busy at the moment...  :-?

I'll be happy to help with what I can! Keep me posted!  :D

xeriouxi.
Click to expand...

That's great.  A few things you should know about the way the configurator was coded:

The source code for the configurator (version 2.0 only, I believe) is available here, off of the FFSF site, due to the whole GNU license thing...I think.

If I remember correctly, Fice once mentioned that version 2.0 (written by Dag, by the way) was coded in Delphi 5, whereas his (Ficedula) updated version (aka "version2.2", which added support for dynamic instrument loading for soundfonts instead of DLS), was coded in Delphi 3, and that the Delphi3 coding was part of the reason behind the error you get when you selected the "Controls" tab.

All I know is that the version I downloaded has that error, and Fice may have released a version that addressed the issue, but I don't know for sure, as his site seems to be down more often than not (and I've sorta....lost the address for his site...:oops:) so I haven't been able to check for that bug-fixed version.
 
I might be able to do something with it. I am pretty busy at the moment - job's do that to you ;) - but what you're proposing sounds reasonably simple.

Only issue with self-extracting RAR's is if they change the header format of the self-extractor in the future, it'd look like a not-a-se-RAR file, and refuse to run it.

In any case, I should be able to do something, even if it's just updating the RAR extraction code. Decide exactly what needs doing and I'll tell you how long it'll take ;)
 
In any case, I should be able to do something, even if it's just updating the RAR extraction code. Decide exactly what needs doing and I'll tell you how long it'll take ;)
Click to expand...

Well, I think coding it to use Self-Extracting RAR files would give the compatibility a bigger boost than simply updating the code to whatever the current WinRAR vesion is (3.x)...so I think that should be the goal.

On the other hand, we'd have to take down all the other existing ffaddon files and re-compress them as self-extracting files....personally, I think that instead of completely replacing the current algorithm in there, it would have support for non-self extracting files that are using the RAR 2.x algorithm, in addition to support for the self-extracting files when it encounters files that use the 3.x algorithm.

I suppose it'd be like this (warning: I have no clue how to code, this is merely being done on a purely conceptual level):

Code: [Select]
Code: 
If "*.FFAddon" has RAR 2.x header, thenuse oldcompression code, else use method2Method2If "*.ffaddon" has RAR 3.x header with self-extraction identifier, thenrun "*.ffaddon" as executable file

....it should be possible to have the program check for what header the file has, and then run the correct procedure based on the version it detects.
 
Hi!

Now, considering that we can class the 2.0 .rar files as 'old', why can't all of them be put into .rar 3.0 and there would be no need for the code implementation?  :-?

xeriouxi.
 
Hi!

Now, considering that we can class the 2.0 .rar files as 'old', why can't all of them be put into .rar 3.0 and there would be no need for the code implementation?  :-?

xeriouxi.
Click to expand...

Because currently as it is, only one package on the site is NOT using the 2.x code.  Of course, now that you've heard that you probably think "why would we rewrite a program for a problem that only a single package has?"

Because there is still a need for 3.x compatibility, as I have made some very odd observations concerning WinRAR.  For some reason it seems that if I use WinRAR 2.x to create the FFAddon, and then use the 3.x program to put it in a ZIP file, the FFAddon file's 2.x code seems to get transmuted into 3.x code either during compression to or extraction from ZIP....assuming that Aaron has indeed uploaded the one I created using WinRAR 2.x, as I recently downloaded it and tried to install it, only to get the same behavior as I get from a file created by the 3.x code.

The worst case scenario would be that WinRAR is changing the .FFAddon code from 2.x to 3.x upon extraction from ZIP, a situation in which using 2.x to create the file and compress to zip would not be a 100% guarantee of compatibility, as anyone who used WinRAR 3.x to handle the file would mean the code got changed to 3.x code at the last second, while other people would use WinZip to open it, and the file would install fine.....and mass confusion might arise.

The other scenario is that the FFAddon file is being changed from 2.x to 3.x code when WinRAR 3.0 is compressing it into a ZIP file.  In this case, using WinRAR 2.x to make the zip file should be fine....

Either way, the file's compatibility appears messed up if WinRAR 3.x touches the file.....and since any new packages, even if they are created with WinRAR 2.x, will inevitably come into contact with WinRAR 3.x and be compromised, the program has to be able to handle 3.x compression code.

Now, I should probably mention that I'm coming really close to getting the FF9 Mod ver2.1 (for Original DLS/Revision2) ready for release, I'm gonna need to make sure the package isn't gonna have the same problems that the one for Samuel's DLS is having.

Of course, it could be that Aaron simply had not gotten around to replacing the problem package with the one made using WinRAR 2.x that I sent him....and thus caused this confusion....my brain hurts now...
 
I'm almost positive that I replaced it.  But to be sure, if you have a correct version, you can send it to me again and I'll replace it again, or try to use it in in the FF Configurator myself.
 
I'm almost positive that I replaced it.  But to be sure, if you have a correct version, you can send it to me again and I'll replace it again, or try to use it in in the FF Configurator myself.
Click to expand...

I just did some timestamp-comparing between the one I made with WinRAR 2.x (which BTW I tested successfully on my own system, before I compressed it to Zip to pass it along to you) and the one I downloaded from the site, and it appears we have a mismatch.

Here's the difference (timestamps taken from the actual ffaddon files, and not the zip that contains it):

FF8mod_Samuel.ffaddon (on FFSF site) -- Modified Thursday, June 12, 2003 5:46:32 PM

FF8mod_Samuel.ffaddon (made with WinRAR 2.x) -- Modified Tuesday, July 29, 2003 8:53:56 PM

They're about one month apart....this should just about match up with the time difference between my sending you the incompatible one and the one I made with the 2.x code that should replace what's there.

Therefore, it appears that you did not replace the file.  Either that or I grabbed the wrong one when I attached it, lol.
 
Ok, here's some good news:

I don't have that repeating Illegal operation error anymore when I access the controller tab, so this should mean I can once and for all set my controller config up without FF8 reverting to the previous one every time I start it up...heh. :D

Bad news:

I attempted to use the program to install the version of "FF8mod_Samuel.ffaddon" that had the 3.x compression code in it, and got

Code: [Select]
Code: 
Access violation at 00000000. Read of Address FFFFFFFF.

Along with the program extracting the directory structure but not the files contained in the archive (i.e., failed to extract).

-edit-

Ok...I found out that the illegal operation is caused by the unrar.dll not being in the same directory as the program....and the one I threw in there (which I'm pretty sure is the 3.x dll) only got rid of the error message -- its still failing to extract the actual files.
 
Status
Not open for further replies.
Back
Top