xdms 1.3.2

[Qube]

Has anyone compiled xdms 1.3.2 for win32/dos cmd?

I've had a look and can't get the makefile to run with mingw32, tried manually creating the object files but it looks like there are a few defines to fix etc.

Wondered if anyone had compiled it?

http://zakalwe.fi/~shd/foss/xdms/

Q;

[Adderly]

wow, new "Added an option for salvaging broken DMS images"!
This is exactly what i coded into another dms unpacker to depack broken images beyond the dms-error! See here: http://eab.abime.net/showthread.php?t=24636
I'll try to compile this new (unofficially) xdms version...

[poohbear]

Try running "./configure" from bash within Cygwin. That will build Makefile from Makefile.in. If you don't have Cygwin, I can post the output.

One small problem I ran into is that mkstemp doesn't appear to be in MinGW. Deprecated POSIX function perhaps?

mkstemps is defined in %MINGW%\lib\libiberty.a, and a quick glance of the GNU mkstemps suggests that mkstemp(p) is equivalent to mkstemps(p,0). So change, lines 288-289 from:

strcpy(tname, "/tmp/xdmsXXXXXX");
fd = mkstemp(tname);

to:

strcpy(tname, "xdmsXXXXXX");
fd = mkstemps(tname,0);

(unless you have a writeable /tmp directory).

Then modify your Makefile (or makefile.in before running ./configure) in the src directory to link with libiberty.a:

xdms: $(OBJS)
$(CC) $(LFLAGS) $(OBJS) -liberty -o $@

The resulting binary successfully unpacked a DMS.

[Adderly]

ah yes, that is exactly the reason why i modified a different dms-unpacker and not the xdms source coz it's not easy portable. I wasn't able to compile it and have no motivation to fix this because there are other dms-unpacker with sourcecode in portable C out there on Aminet...
If someone was able to build a win32 or dos executable please zone it for us. Thanks!

[shd]

Originally Posted by poohbear

One small problem I ran into is that mkstemp doesn't appear to be in MinGW. Deprecated POSIX function perhaps?

You should have emailed me. I can fix the problem directly in the source tree.

mkstemps is defined in %MINGW%\lib\libiberty.a, and a quick glance of the GNU mkstemps suggests that mkstemp(p) is equivalent to mkstemps(p,0). So change, lines 288-289 from:

strcpy(tname, "/tmp/xdmsXXXXXX");
fd = mkstemp(tname);

to:

strcpy(tname, "xdmsXXXXXX");
fd = mkstemps(tname,0);

(unless you have a writeable /tmp directory).

One has to have a write /tmp directory, that's a basic requirement for UNIX programs.

Next version (hopefully released soon) will have the fix.

[shd]

Originally Posted by Adderly

ah yes, that is exactly the reason why i modified a different dms-unpacker and not the xdms source coz it's not easy portable. I wasn't able to compile it and have no motivation to fix this because there are other dms-unpacker with sourcecode in portable C out there on Aminet...
If someone was able to build a win32 or dos executable please zone it for us. Thanks!

Support for new platforms are added as someone requests it and is willing to help me. It seems mingw support will happen now.

[Adderly]

I used undms 1.3 (12.2.98) from Aminet.
Seems it is based on the xdms source, at least Andre Rodrigues de la Rocha is mentioned for his help. It is portable C, i was able to compile it without any needed modifications using Visual C for Windows. Not as mighty as the xdms original but maybe usefull if you want it portable for other platforms.

shd, can you tell us more about "the salvaging broken DMS images" function of your xdms version? How does it work? Does it skip the broken track? Can it handle all kind of dms-errors? etc.

It's very good to have this feature since there are a lot of broken dms images out there!

[shd]

Originally Posted by Adderly

shd, can you tell us more about "the salvaging broken DMS images" function of your xdms version? How does it work? Does it skip the broken track? Can it handle all kind of dms-errors? etc.

It basically just ignores CRC checking but writes the correct amount of data to the disk. You will of course lose some data, but it tries to write as much data on the broken track as it can. One will get some garbage data too. After an error it continues with the next track. It's not sophisticated as it can't reason anything from the broken data.

[shd]

Originally Posted by poohbear

mkstemps is defined in %MINGW%\lib\libiberty.a, and a quick glance of the GNU mkstemps

I can't see mkstemps() on a UNIX system. What version of MinGW do you have? A person with

$ uname
MINGW32_NT-5.1

failed to compile a version having mkstemps().

gcc -liberty u_heavy.o xdms.o u_deep.o u_init.o u_quick.o
u_medium.o u_rle.o tables.o pfile.o maketbl.o getbits.o
crc_csum.o -o xdms
xdms.o:xdms.c.text+0x74c): undefined reference to `mkstemps'
collect2: ld returned 1 exit status

Please checkout the latest xdms from the CVS tree and test it. It automatically detects mingw and uses mkstemps() instead of mkstemp().

As far as I know, mkstemps() only depends on #include <unistd.h> and that header file is included from xdms.c.

[poohbear]

Originally Posted by shd

You should have emailed me. I can fix the problem directly in the source tree.

I only compiled it last night in response to Qube's question, but, yes, it would have been a good idea for me to mail you also. Thanks for preempting it!

Originally Posted by shd

One has to have a write /tmp directory, that's a basic requirement for UNIX programs.

Windows, I'm afraid. There's probably a Win32 API function to fetch Profile\Local Settings\Temp, but I don't have it to hand.

Originally Posted by shd

Next version (hopefully released soon) will have the fix.

Thank you!

[poohbear]

Originally Posted by shd

I can't see mkstemps() on a UNIX system. What version of MinGW do you have? A person with

$ uname
MINGW32_NT-5.1

failed to compile a version having mkstemps().

I don't have a uname with my MinGW distribution from 2003 (it could be that the other person has MSYS instead of MinGW). The gcc version is:

> gcc --version
gcc (GCC) 3.2.3 (mingw special 20030504-1)

Old, but I can't upgrade it for compatibility with other projects.

I have no idea of the status of mkstemp/mkstemps on systems. It could well be that mkstemps is the deprecated function. Darwin seems to support both, so perhaps I should switch after all. :-)

http://developer.apple.com/documenta...kstemps.3.html

Originally Posted by shd

Please checkout the latest xdms from the CVS tree and test it. It automatically detects mingw and uses mkstemps() instead of mkstemp().

As far as I know, mkstemps() only depends on #include <unistd.h> and that header file is included from xdms.c.

I can't see a CVS repository linked from:

http://zakalwe.fi/~shd/foss/xdms/

Could you provide a pointer? Thanks!

[Qube]

Wow, looks like I got a bit of interest rekindled here.

Is there any way that xdms could be updated in the future to allow unpacking of , for example, a trainer dms or patch over an existing adf file? This would reduce the need of firing up winuae to apply a dms patch to a disk image? Is this possible?

Q;

[shd]

Originally Posted by poohbear

I don't have a uname with my MinGW distribution from 2003 (it could be that the other person has MSYS instead of MinGW). The gcc version is:

That's very strange. Uname is supposed to be a mechanism to determine the kernel and OS.

I can't see a CVS repository linked from:

http://zakalwe.fi/~shd/foss/xdms/

Could you provide a pointer? Thanks!

Sorry, CVS instructions are now included on the page:

$ cvs -d :server:uadecvs@zakalwe.fi:/home/cvs/uade-cvsroot login 
$ cvs -d :server:uadecvs@zakalwe.fi:/home/cvs/uade-cvsroot co xdms 
$ cd xdms

But, it will not work without uname command, so we have to figure out something else.

[shd]

Originally Posted by Qube

Is there any way that xdms could be updated in the future to allow unpacking of , for example, a trainer dms or patch over an existing adf file? This would reduce the need of firing up winuae to apply a dms patch to a disk image? Is this possible?

Could you send me an example dms and an associated patch file for reference? It could be possible. Also, please tell me how you would want to use it; what kind of parameters for xdms or would you rather issue two commands? My email address is heikki.orsila@iki.fi, you can send the files there.

[poohbear]

Originally Posted by shd

That's very strange. Uname is supposed to be a mechanism to determine the kernel and OS.


Sorry, CVS instructions are now included on the page:

$ cvs -d :server:uadecvs@zakalwe.fi:/home/cvs/uade-cvsroot login 
$ cvs -d :server:uadecvs@zakalwe.fi:/home/cvs/uade-cvsroot co xdms 
$ cd xdms

But, it will not work without uname command, so we have to figure out something else.

Thanks for the CVS information. I identified the password using l33t h4x0ring skills. ;-)

As to uname, MinGW on its own is a port of GCC and friends, so one gets:

a2dll             dsw2mak           mingw32-g++.exe   redir.exe
addr2line.exe     exchndl.dll       mingw32-gcc.exe   reimp.exe
ar.exe            g++.exe           mingw32-make.exe  res2coff.exe
as.exe            g77.exe           mingwm10.dll      size.exe
c++.exe           gcc.exe           nm.exe            strings.exe
c++filt.exe       gccbug            objcopy.exe       strip.exe
cpp.exe           gcov.exe          objdump.exe       unix2dos.exe
dlltool.exe       gdb.exe           pexports.exe      unprotoize.exe
dllwrap.exe       gprof.exe         protoize.exe      windres.exe
dos2unix.exe      ld.exe            ranlib.exe
drmingw.exe       mingw32-c++.exe   readelf.exe

I ran the configure script under Cygwin which does have its own uname. That uname reports:

  CYGWIN_NT-5.1

I also have another uname from unxutils that reports:

  WindowsNT

In other words, I wouldn't hope for a reliable uname on a Windows machine!

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:

  gcc (GCC) 3.2.3 (mingw special 20030504-1)

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).

[Adderly]

Originally Posted by shd

Could you send me an example dms and an associated patch file for reference? It could be possible. Also, please tell me how you would want to use it; what kind of parameters for xdms or would you rather issue two commands? My email address is heikki.orsila@iki.fi, you can send the files there.

Wow, this feature would be great! Writing just the new tracks to an existing adf image!
May i suggest "a" as command for "apply DMS archive to existing disk image" or something like this.
-> xdms a xxxxx.dms +yyyyy.adf
Ofcourse the name of the adf image is not optional anymore with this function. I've included a dms image and a crackfix also as dms for a game released by Paradox for testing.

@poohbear: I hope you can manage it to give us a Windows/dos version!

[Adderly]

Originally Posted by Qube

Wow, looks like I got a bit of interest rekindled here.

Is there any way that xdms could be updated in the future to allow unpacking of , for example, a trainer dms or patch over an existing adf file? This would reduce the need of firing up winuae to apply a dms patch to a disk image? Is this possible?

Q;

Aye, Great thread!

[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!

[Paul]

This thread deserves to be in Coders Heaven forum, so thread moved

[shd]

Originally Posted by poohbear

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

Sorry for that.. Indeed, the password is uadecvs.

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

Ok. Fixed.

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. News to me. And the anonymous mingw users confirmed that to be true.

Please checkout the new version and see if it works now.

[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.