Originally Posted by haps
The processing volume text is shifted all the way to the right when scanning disks as the following screenshot shows. This happens on both nix and windows.
Oh, actually this is purpose.
It actually looks quite good with a very small but readable font here on the DOS console.
I thought (!) that it's better to have the volume names on the right than mingled with the other text rattling down the screen in multi-file batch mode ... but maybe that was a wrong thought...
BTW, Cygwin is running fine here now.
#error does NOT seem accepted by cygwin gcc!
I knew quite well why I decided to comment that out. When I comment that out in typedefs.h, it works.
Maybe that is GCC 3 only? I'm using v4.
In file included from adfstruct.h:8,
typedefs.h:50:2: error: #error It just does not work.
OK I managed to figure out what the problem is!
It's the macro xformHton*() and xformNtoh*() family. These are used for my getSecData* group of functions, and they were always zero!
This will make the BAM key to "invalid" (-1), no wonder that your disks were recognized wrongly!
Not that it calculates wrongly, at least in Cygwin there seems to be a BUG!!
This will make it work:
plus move that xform* stuff into adffile.h, otherwise we would have to #include typedefs.h which often creates new linking problems.
Totally crazy! Why do I have to manually #undef BIG_ENDIAN when LITTLE_ENDIAN is defined? Maybe I should report to the list with a small test program.
0.1.4alpha attached, source only.
On native Linux, it might even be necessary to include <endian.h>. If you really can be arsed to debug around a bit, then please check getSingleSecDataLong()
which returns single long words of all that precious block data.
If it's zero, *NONE* of the macros are chosen. I've just hacked in a short printf() in either of those and got nil. Until I #undef'd BIG_ENDIAN for fun's sake ...