xdms 1.3.2

[shd]

Originally Posted by poohbear

I identified the password using l33t h4x0ring skills. ;-)

Sorry for that. For the record to others, the password is uadecvs. It is now on the web site.

If you want a test for MinGW, you could use:

  mingw=$(gcc --version |grep -i mingw32)

to pick up on this part of the "gcc --version" output:

Added a check with gcc.

By the way, doesn't the library link flag have to appear after the object module with the undefined reference? In src/Makefile.in, I think you'll need the "-liberty" flag to appear after $(OBJS).

Ah! Fixed this in the CVS. A mingw user could confirm this was the problem. However, there's still "implicit declaration of mkstemps" in xdms.c. Need to find the proper #include for that.

Please checkout and try the new version.

[shd]

Originally Posted by Adderly

May i suggest "a" as command for "apply DMS archive to existing disk image" or something like this.
-> xdms a xxxxx.dms +yyyyy.adf

I'll look into this. I think i'll leave the + sign away because it is redundant ("a" implies that two filenames follow). Thanks for the test data.

[shd]

Originally Posted by Adderly

ok, here are some defect dms images for testing.

included are:
flt-cup.dms : dms error#8 on track24
grandnt2: dms error#8 on track42

->nasty errors, of you "test" the image with original dms or xdms the test shows no error but if actually depacked you'll get an error!

I've unpacked this images already with my modified undms V1.3 version, of course with some errors (bytes not original) on the erroneous track but the tracks that follow are rescued. Please try also with your xdms 1.3.2 version.

next one is a dms-error i could not depack beyond the error:

theunt01.dms : dms error#6 on track 6
->"test" dms-image will show this error and you cannot depack beyond track 6. I hope your xdms version can depack this one!

Thanks. I'll look into this issue as well.. I have to go to work soon, so later.

[demoniac]

I guess I like to use the traditional dms for patches as it displays ASCII and bitmap gfx that the packed file has. I can see how xdms might be able to display ASCII, but not easily the bitmap gfx.

[Qube]

Thanks for upping the test files Adderly, you beat me to it!

I didn't know a dms file could include actual gfx stuff, I thought it was all ascii or some kind of amiga ansi equivalent. I guess if you dropped out of a standard console display and invoked a graphic mode then you could display whatever you wanted to really, but this would require extra coding and bloat the app a bit; after all xdms is good in that it is so small and quick to use.

Great stuff - looking forward to the new builds!

[demoniac]

I think it's Amiga ANSI that was converted from bitmap gfx. It would definitely bloat the app. I think pure ASCII displays could be easily implemented tho.

[poohbear]

Originally Posted by shd

Added a check with gcc.

Ah! Fixed this in the CVS. A mingw user could confirm this was the problem.
However, there's still "implicit declaration of mkstemps" in xdms.c. Need to find the proper #include for that.

Thanks. Using Cygwin bash to run configure and MinGW gcc to build, produces a working executable. A recursive grep of the MinGW includes directory did not turn up a prototype for mkstemps which is annoying but tolerable (to me at least!). I did modify xdms.c to remove the "/tmp/" in the temporary file specification, because that directory is unlikely to exist on a Windows system. The "right" way to create a temporary file on Windows is documented in http://msdn.microsoft.com/library/de...orary_file.asp
but it seems that there's little to be gained by adding that code.

I tested the xdms executable on one DMS using the readdisk executable from the xDMS at http://iancoog.altervista.org/ , and it successfully unpacked the DMS and resulting ADF.

I have posted the executable to the Zone! for those without a C compiler.

[shd]

Originally Posted by poohbear

I did modify xdms.c to remove the "/tmp/" in the temporary file specification, because that directory is unlikely to exist on a Windows system. The "right" way to create a temporary file on Windows is documented in http://msdn.microsoft.com/library/de...orary_file.asp
but it seems that there's little to be gained by adding that code.

No, there is a lot to be gained by that code. Temp file creation is very important to get correctly (users of the same operating system must be carefully separated with namespaces and ACL to avoid conflicts). This is very important on UNIX. Because modern Windowses support all the necessary stuff (and should be multi-user) it should be done there too.

Please submit a patch to properly create tmp files for windows. I don't have the environment so I can't test. It is enough if you submit me a function of the form

int get_temp_file(char *name, size_t namesize)

in a separate module. The function should decide a proper name and create a file unreadable/writable by other users (avoiding race conditions). The function should return zero on success and non-zero on failure. Afterwards xdms will open that file with fopen(name, "w").

[Codetapper]

I implemented a brute force password cracking mechanism into xdms 1.3.1 to unpack some Amiga Format coverdisks. Would you like to merge my changes into your version aswell? It tries all 16 bit keys until it hits pay dirt, then generates passwords that match and prints out a bunch of them (all keys can be turned back into ASCII passwords 4 bytes or less in length).

All my changes just went into the xdms.c file.

Also when you do detect an error, what are you writing away to the track buffer? I would prefer something like what DIC does, write "TDIC" all through the track rather than have a track which is just random as you wouldn't be able to tell there was an error in that track by looking at the ADF.

If you want my source please PM me with where you want it sent.

[Adderly]

Originally Posted by Codetapper

I implemented a brute force password cracking mechanism into xdms 1.3.1

This would be a great feature for xdms!

Originally Posted by Codetapper

Also when you do detect an error, what are you writing away to the track buffer? I would prefer something like what DIC does, write "TDIC" all through the track rather than have a track which is just random as you wouldn't be able to tell there was an error in that track by looking at the ADF.

DMS is using "errdms!!" for this case.

But no, the track isn't just random. Take the defect flt-cup.dms file i provided for testing. Only one byte is different on the erroneous track (i have compared it with an error-free original)! Hmmm, but you are right, xdms should mark such tracks as bad somehow.
May i suggest to write just the standard (repeated) "errdms!!" string on the whole track as standard procedure but an option in xdms should allow to write the track with the error on it like it is. Of course this is for experts who know what they do. (maybe -e or -fe)?
Some guys like andreas or me would be able to hunt down just the wrong bytes and replace them from other Tosec disk etc. so this feature would be very welcome!

[Adderly]

Originally Posted by poohbear

I have posted the executable to the Zone!

Thanks, it worked great here even with -f option.

Originally Posted by poohbear

for those without a C compiler.

Cmon you did a good job poohbear, it's not trivial to compile the xdms source.

[poohbear]

Originally Posted by Adderly

This would be a great feature for xdms!

DMS is using "errdms!!" for this case.

But no, the track isn't just random. Take the defect flt-cup.dms file i provided for testing. Only one byte is different on the erroneous track (i have compared it with an error-free original)! Hmmm, but you are right, xdms should mark such tracks as bad somehow.
May i suggest to write just the standard (repeated) "errdms!!" string on the whole track as standard procedure but an option in xdms should allow to write the track with the error on it like it is. Of course this is for experts who know what they do. (maybe -e or -fe)?
Some guys like andreas or me would be able to hunt down just the wrong bytes and replace them from other Tosec disk etc. so this feature would be very welcome!

Presumably, the optimal solution would be to integrate the aggressive DMS unpacker with a GUI version of readdisk / ADF explorer that is aware of errors discovered by the DMS unpacker. For example, you might get a directory listing that indicates which files are corrupt, and possibly a disk editor to edit corrupt sectors before files are extracted.

[poohbear]

Originally Posted by shd

No, there is a lot to be gained by that code. Temp file creation is very important to get correctly (users of the same operating system must be carefully separated with namespaces and ACL to avoid conflicts). This is very important on UNIX. Because modern Windowses support all the necessary stuff (and should be multi-user) it should be done there too.

Please submit a patch to properly create tmp files for windows. I don't have the environment so I can't test. It is enough if you submit me a function of the form

int get_temp_file(char *name, size_t namesize)

in a separate module. The function should decide a proper name and create a file unreadable/writable by other users (avoiding race conditions). The function should return zero on success and non-zero on failure. Afterwards xdms will open that file with fopen(name, "w").

I agree that a robust program should comply with the platform's rules, but, realistically, my programming time has to be spent on other projects for the next couple of months. Sorry!

[Qube]

Thanks for the new build poohbear! I'll have to run some of my old dms files through this to help me get them over to adf. This will also give it all a good testing!
Q;

[BippyM]

can someone please up this to the zone again cheers

Seems I lost the one I downloaded :/

edit: Nevermind I just found where I had saved it to

[Paul]

While as I was at it uploading the mirror copy of winuae, I've put this xdms on the download page here Hope it's ok to have done so. If not then please tell me and I will delete.

[Crashdisk]

Poohbear, you can release your last source code version of xdms?
Ref: http://guide.abime.net/dloads.htm ( xDMS v1.3.3 )

[poohbear]

I'm not sure that I still have the source code. If I find it during a clear up, I will find this thread and upload it.

[Crashdisk]

thank

[Vot]

Well I don't know about poohbears copy but I compiled a win32 version and mailed it to the XDMS project maintainer heikki.orsila@iki.fi, many years ago but he didn't update his website. It really was just a small patch to fix mkstemp its funny you know he talks about it here but when I emailed him it didn't seem like it was patched already. Im pretty sure I kept the source code when I patched it..
I think mine just used the file creation flags to create the temp file but I think this was fine as far as I remember it made a per user temp file under their profile..

Ive attached what I sent but it looks like poohbears beat me to the punch as the messages in this forum were posted in 2006. I think I patched mine in 2008 as at the time the version at http://zakalwe.fi/~shd/foss/xdms/ was 1.3.2 and it didn't compile for windows.. I don't think this zip has a compiled version, you would have to fire up visual studio... the zip file has the vs2008 project files so it should compile fine..

Be aware the file in amiga-bin is probably still the 1.3.2 binary from the old version. this was just the source so heikki could update his repository.