How can I force DMS to write a dms in spite of fatal errors?

[andreas]

Hi,

difficult one here. Here's a DMS image that's definitely broken in the middle, but apparently the root block only, so I may be able to restore that one.
But there's DMS! (Original ParCon, v2.20r)

Nothing to do with emulation or not: if there's a fatal error (CRC mismatch), DMS terminates in the middle of the writing process!

But I'd like to make it write the WHOLE disk to be able to fix some things! (note the blocks beyond aren't broken!)

The technique DMS uses for copying a certain track range is sub-optimal, too. It does that by skipping tracks outside that range, which will - tadaa! - again cause DMS to terminate when a SKIPPED (!) track has an error!

e. g.: you want to copy tracks 40-79, but you certainly know that track 29 is corrupt because of a CRC mismatch. DMS will now skip to track 40, and TERMINATE while still skipping, because of track 29! Haha! :cheese

Is there any way to stop DMS from doing that crap?
(newer version, maybe?)

[RetroMan]

Maybe you can try converting it to ADF on PC first (with XDms) and then write it back to floppy disc again :confused

[pcGTW_Webmaster]

I'm only guessing but it's possible that DMS uses some kind of solid compression and has to decompress the file from the beginning. In this case, you cannot skip this error in any way...

[Severin]

try the 'noval' option...

[andreas]

not working ... also tried 'noval' plus all the others (nozero etc.) to no avail.

[Severin]

bung it in the zone, I'll have a look at it...

[andreas]

thanks! ... done.

[RetroMan]

Just tested this dms with DMS 1.11 (Aminet) and I could write it back to floppy without a problem :confused

But it HAS some read/write error if I start it, but thats of course something you may fix :D

P.S : If I test the file (DMS TEST BROKEN.DMS) the archiv seems to be ok too :hoo

//update : Just for info usage, the following files are damaged -> DMSpell3.pic, View.lo and anim/title ;) Nice hint disk btw. :D

[Severin]

Same here, I just extracted it with on UAE with no errors, didn't even need to fire up the real amiga ;)

Are you sure you sent the right dms file?

[Codetapper]

DMS is a buggy piece of crap! You can simulate a broken DMS easily. Just make up a DMS file, and somewhere in it modify the bytes to something else (eg. write HOL RULES randomly into the hex).

Now DMS will test it and say it's OK (useless!) but if you try and write it back you will get the error.

[andreas]

OK @Severin, you were right.
It was the WRONG adf; well as I have been in a hurry today afternoon, I was merely able to check my text file with the hand-noted infos.

This time, I had more time to retest: there's a new one now in the zone with CRC error *while* unpacking (real DMS -- Amiga).
xDMS (PC) will behave similarly to DMS on the Amiga, break and leave back an (unusable) ADF with less than 880k by far!

@Retroman: There's already a 100% version of that hint disk in TOSEC, if you're so keen on it :) [DOCS dat]

[Severin]

Hmmm, yep, It's naffed alright, I even dug out the version it was written with (that has a few options later dropped), I can tell you it was created on an 040 based machine with no FPU, it took 14 seconds, created with V 2.03 evaluation version, etc :(

What is it? seems to be non-dos from the bit I managed to decompress...

[andreas]

King's Quest 4 Disk 2. :)

Well, if I was in need of it, I'd request it.
But I was only interested in a way to force DMS to write this image to the end in spite of the error, simply to have a working example of this procedure. It's not about the actual game. :rolleyes

Most archivers (like the infamous ARJ and the unforgettable PKZIP) were and are still able to do this kind of thing. DMS apparently isn't. :( :scream


Hmmm, yep, It's naffed alright, I even dug out the version it was written with (that has a few options later dropped), I can tell you it was created on an 040 based machine with no FPU

Cool findings! :D
Could be a nice thing to have that version as well.
Many guys here have several versions of WinUAE installed, why not have several versions of one archiver installed? :cheese

[pcGTW_Webmaster]

Originally posted by andreas
Most archivers (like the infamous ARJ and the unforgettable PKZIP) were and are still able to do this kind of thing. DMS apparently isn't. :( :scream
As I said, if this DMS was created using solid compression, you cannot skip this error.

RAR also supports solid compression and you'll get the same problem with a damaged RAR archive, when solid compression was used...

[Severin]

Here's DMS2.04 and DMSToy, have fun :)

[andreas]

Thanks! :great

Originally posted by WindowsKiller
As I said, if this DMS was created using solid compression, you cannot skip this error.
Urgh. :scream
I was almost fearing that.

[shd]

Difficult one here. Here's a DMS image that's definitely broken in the middle, but apparently the root block only, so I may be able to restore that one.
But there's DMS! (Original ParCon, v2.20r)

Care to send me the image? The latest xdms has some support for writing broken tracks and not aborting on that condition. Also, send me a dms image that contains an ascii header that caused you problems (that you mentioned in a much newer thread). -> heikki.orsila@iki.fi

[Adderly]

Some defect dms-images posted here: http://eab.abime.net/showpost.php?p=262947&postcount=18

[andreas]

@shd I can.
But first please tackle that issue I mailed you privately about.

One after another. Thanks. :)
Rome wasn't built in a day [tm] :cheese

[andreas]

As shd hasn't answered / mailed back for ages, I did it myself :D :evilgrin

Using DJGPP (http://www.delorie.com/djgpp/) and the excellent RHIDE, I managed to compile a win32 version of xDMS 1.3.2 today! :)

If anyone wants it too, gimme a shout :D
The only major modification I had to make was to alias the types unknown from MSDOS/Win32 side (USHORT, ULONG ...) by their standard type names (unsigned short, unsigned long) using a handful of #ifdefs. The rest compiled fine OOTB! :)

A smashing "nice work!" also to the new maintainer therefore!

[shd]

As shd hasn't answered for ages, I did it myself :D :evilgrin

Using DJGPP (http://www.delorie.com/djgpp/) and the excellent RHIDE, I managed to compile a win32 version of xDMS 1.3.2 today! :)



Since 2006-08-17 it has been possible to compile it for Windows using MinGW. See the CVS repository. MingW compiled programs are native Windows programs that do not need any special libraries.

[bippym]

If anyone wants it too, gimme a shout :D


I'm shouting

[andreas]

Since 2006-08-17 it has been possible to compile it for Windows using MinGW. See the CVS repository. MingW compiled programs are native Windows programs that do not need any special libraries.

Ah there you are!

So you are ... but can't be arsed to answer my e-mail with the bug report I sent on 17 August 2006, can you? :rolleyes
I'm known to be fairly patient, but half a year is even putting my patience at risk :cool

Well if MingW is able to compile the thing and get it down to less than ~ 175K size, let me know!

I'm at 178,901 bytes now with a bit of optimizing - almost twice the size of the 1.3 version!
Please replace your cdata.h with mine, as unless you're using MingW, dos/win32 does not know about Uxxxx types!

Lastly, there's nothing that keeps you from putting this mingW win32 build on your site. It will certainly not cause your server capacity to be exhausted :p

[shd]

So you are ... but can't be arsed to answer my e-mail with the bug report I sent on 17 August 2006, can you? :rolleyes
I'm known to be fairly patient, but half a year is even putting my patience at risk :cool
Maybe I forgot or planned to answer later. I don't remember which.

Anyway, I haven't done anything else for xdms, just look at ChangeLog at CVS.

Well if MingW is able to compile the thing and get it down to less than ~ 175K size, let me know!

I'm at 178,901 bytes now with a bit of optimizing - almost twice the size of the 1.3 version!
Size isn't important. It's 33 KiB on my amd64 GNU/Linux.

[shd]

size of the 1.3 version!
Please replace your cdata.h with mine, as unless you're using MingW, dos/win32 does not know about Uxxxx types!

What kind of devel environment is it? Do you compile by running ./configure script first, or something else? If you use the configure script, what does "uname -a" and "uname" say on your system?

Lastly, there's nothing that keeps you from putting this mingW win32 build on your site. It will certainly not cause your server capacity to be exhausted :p
Would you certify those compiled binaries with your name and email address? I couldn't build those.

[andreas]

Did I get you wrong?

You gave me the impression that I will get a win32 executable by accessing CVS. But apparently I won't...

So don't you have any Windows machine at all?
If so, I'd understand.

About .configure:

Again, I'm on NATIVE Windows, that is, I'm working without Cygwin!
Nor am I working with MingW. So there is no ".configure"!
I gave you a link above so you get a clue what DJGPP is (resembling classic Borland Turbo C/C++ product line), and I used a project file, adding the required files to the project, just as I would do it in MSVC.

Size isn't important. It's 33 KiB on my amd64 GNU/Linux.
Well, please read carefully.
I do not care about the size of the linux version. It's about the size of the win32 version. Forget about your linux world for one second. Please. At least try it. There is NOT only linux.

People would convert their DMS images from older CDs mainly on Windows, less probably Linux, so it would be about time (!) that this aeons-old version on Aminet gets replaced by a recent one eventually!

[thor]

andreas: install MinGW and MSYS and you can use ./configure and be able to build a native Win32 xdms.exe. File size is 56442 bytes.

[andreas]

Well, do you have it installed?
So you do it, and up it to Aminet!

I'm no "publicity whore", so if someone else does it, it'll be fine! :)
Hence the hard-to-overlook announcement "UNOFFICIAL" in the zone...I had some impression that the build appeared a bit big...

[thor]

Upped my MinGW build of the latest CVS sources to the zone. Do want you want with it.

[andreas]

thanks man! :)

As I have not done it myself, I can't upload it to Aminet...so why don't you do it so people do no longer have to download the old 1999 version? Please do it - it is really worth it, believe me!

@all: thor's version is 1.3.3, note that! :)

[thor]

It's 1.3.3 with that MinGW mkstemps fix. And as it's an unofficial build too, I will upload it to Aminet only if shd agrees

Edit: I see that the Aminet 1.3 version has binaries for Amiga and Linux too, so I don't know if it's a good idea to upload it without those

[shd]

Did I get you wrong?

You gave me the impression that I will get a win32 executable by accessing CVS. But apparently I won't...

Did I? Obviously we will distribute binaries on the web page, if we get binaries from someone, but development happens in the version control system (CVS).

You didn't answer my question about distributing those binaries by your name. If we are going to distribute binaries on my web page, the builder should be a known person. A chain of trust is needed.

So don't you have any Windows machine at all?
If so, I'd understand.
No. And even if I had the money to spend, I wouldn't pay Microsoft, so I won't use it.

About .configure:

Again, I'm on NATIVE Windows, that is, I'm working without Cygwin!
Nor am I working with MingW. So there is no ".configure"!
I gave you a link above so you get a clue what DJGPP is (resembling classic Borland Turbo C/C++ product line), and I used a project file, adding the required files to the project, just as I would do it in MSVC.
Open source development needs build automation so it would possibly be nice to have some project file for DJGPP envnronment and distribute that with the source. Would you send me the project file?

Well, please read carefully.
I do not care about the size of the linux version. It's about the size of the win32 version. Forget about your linux world for one second. Please. At least try it. There is NOT only linux.
Well, please read carefully. I do not care about the size of the windows version. It's about the size of the linux version. Forget about your windows world for one second. Please. At least try it. There is NOT only Windows.

People would convert their DMS images from older CDs mainly on Windows, less probably Linux Agreed.

[thor]

'strip xdms.exe' makes it even smaller (32256 bytes)

[shd]

It's 1.3.3 with that MinGW mkstemps fix. And as it's an unofficial build too, I will upload it to Aminet only if shd agrees
You don't need my approval for this. This is an open source project; distributing binaries is permitted for anyone. Just upload the binary with your name, as I didn't build it.

[thor]

I know, but I think good manners require asking even it isn't needed legally. But as I said, without at least the Amiga binaries I don't think it's a good idea to upload it to Aminet (which is mainly for Amiga and not for Win32 binaries ;) )

Replaced the larger xdms.exe with the stripped one in the zone

[andreas]

good work! :great

[shd]

I committed a patch into CVS that fixes datatypes on DJGPP environment. Thanks Andreas.

[andreas]

Thanks ...
and here's the project file! Uses -Os in gcc to get the build a bit sized-down...also -march=i386 as we're on x86. (i586 will make the build bigger => pointless)

[edit] (removed, as it contains individual paths, gotta investigate this first)

[shd]

Thanks ...
and here's the project file!
Where?

[andreas]

above...
after ignoring my one report for months, I had no idea you could be so fast :evilgrin

[shd]

Thanks ...
and here's the project file! Uses -Os in gcc to get the build a bit sized-down...also -march=i386 as we're on x86. (i586 will make the build bigger => pointless)

This looks a bit unworkable cause it contains hardcoded paths for a single system: e:/xdms132/src/cdata.h

Can you do anything about this?

We should have something that works for everyone. That is the reason for configure scripts on unix.

[andreas]

This should do the trick! :)
Please recheck.

[thor]

But there's still one problem if you would want to compile 1.3.3 with project files (of whatever IDE) as CVS version includes "xdmsconfig.h" in "xdms.c" and that is made by ./configure. So you would have to make one yourself. Easy to do, it just defines VERSION and for MinGW NO_MKSTEMP, but you can't just load the project into the IDE and compile.

I think the best solution is that the "xdmsconfig.h" would be omitted. The version number can be added as a compiler flag as it was in version up to 1.3.2. And that MinGW check is not done with that check in ./configure and defining NO_MKSTEMPS, but by using #ifdef __MINGW32__ in xdms.c.

[thor]

Fix for not being able to write the temp file (for x and z commands) under Windows in xdms.c as there is no /tmp:

add (needs to be before #include "cdata.h")
#ifdef _WIN32
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#endif
because of that you'll need to change FILE_END to something else in your files (or try to get MS change it in theirs :crazy)

and replace
strcpy(tname, "/tmp/xdmsXXXXXX");
with
#ifdef _WIN32
DWORD ret = 0;
DWORD bufsize = FNAME_MAXC-10;

ret = GetTempPath(bufsize, tname);
if (!ret || ret > bufsize) {
fprintf(stderr, "Couldn't get temp dir\n");
exit(-1);
}
strcat(tname, "xdmsXXXXXX");
#else
strcpy(tname, "/tmp/xdmsXXXXXX");
#endif