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.