Hello,

I have noticed that the Volume Serial Number of the same CD is displayed
in different byte order on machines with XP and Win 98 - either using
"dir e:" command or by GetVolumeInformation() function from Win32 API.
But the VSN of a floppy disk is identical on both machines.
I have written an application that relies on this number so it is
important that the bytes are properly ordered. How to verify what is the
actual byte order, so that the Serial number of the same volume is
always the same?

regards,

Piotr

Suggest your application determines what platform it is running on to
resolve this issue.

Gutek wrote:

> Hello,
>
> I have noticed that the Volume Serial Number of the same CD is displayed
> in different byte order on machines with XP and Win 98 - either using
> "dir e:" command or by GetVolumeInformation() function from Win32 API.
> But the VSN of a floppy disk is identical on both machines.
> I have written an application that relies on this number so it is
> important that the bytes are properly ordered. How to verify what is the
> actual byte order, so that the Serial number of the same volume is
> always the same?
>
> regards,
>
> Piotr

Bob I napisał(a):
> Suggest your application determines what platform it is running on to
> resolve this issue.
>

This could be a solution provided that I am sure that Volume Serial
Numbers are ALWAYS reversed on Win 98 with respect to XP. But this is
not true for floppy disk, for example, as they appear to obey the same
byte order. Can somebody verify this for any CD, please?

regards,
Gutek

Years ago when Windows 98 still was the greatest I studied Volume Serial
Number and wrote little assembler programs to change the VSN when required.
You can change the VSN to anything as long as it is a valid HEX value.
On one of my old old computers with Windows 98SE the C: partition still
has ABCD-ABCD as VSN.
MicroSoft used Volume Tracking to distinguish volumes an not VSN.
If not able to do Volume Tracking Windows would use other methods.
The VSN didn't have any use anymore to check volumes.

I discovered Format and Diskcopy differ in the way they create a VSN.
Below I wrote at the time:

<QUOTE>
A VSN is generated by Format.COM and DiskCopy.Com from Dos date and Dos
time.
It is a double word (4 bytes) value stored in reverse notation on disk.
The VSN is stored at offset 0027h (FAT12 and FAT16) or 0043h (FAT32) in the
bootsector.

The routines used to generate a VSN stayed the same from Dos 5.0 - Dos 7.1

Routines in Format.Com and DiskCopy differ slightly.
Compared with Format.COM the High and Low word have changed place
Format: [Seconds/Hundredth] + [Month/Day of mo] = High word of VSN
[Hour/Minutes] + [Year] = Low word of VSN

DiskCopy: [Seconds/Hundredth] + [Month/Day of mo] = Low word of VSN
[Hour/Minutes] + [Year] = High word of VSN
</QUOTE>

Gutek wrote:
> Bob I napisał(a):
>
>> Suggest your application determines what platform it is running on to
>> resolve this issue.
>>
>
> This could be a solution provided that I am sure that Volume Serial
> Numbers are ALWAYS reversed on Win 98 with respect to XP. But this is
> not true for floppy disk, for example, as they appear to obey the same
> byte order. Can somebody verify this for any CD, please?
>
> regards,
> Gutek

Thanks for reply.

My problem, however, is related to VSN of CDs - and those I believe you
cannot change easily. I would like to distribute a number of CDs among
people and I create a database, where people register their CDs, so that
I knew who's got a particular copy. This process requires that all users
send me VSN of their CDs - it is prompted to them using
GetVolumeInformation() from API.
Now, on my old machine with Win 98, the VSN of the CD is prompted in
reverse byte order. If the user sends me the VSN in this order - the
database, which stores all numbers of distributed CDs, will not
recognize it. I can implement a mechanism which automatically restores
the proper order of bytes when needed, but I must know whether it is
normal or reversed. Is there a way, possibly using API, to check which
rule is used? And why the VSN of CD is reversed, but not of the floppy?

regards,

Gutek

I think I understood your problem but wanted to make clear the VSN is a
very old Dos relic MS didn't do much with in the later nineties.
And it was originally created for a different purpose, to check the same
disk was still in place, but replaced by Volume Tracking.

Gutek wrote:
> Thanks for reply.
>
> My problem, however, is related to VSN of CDs - and those I believe you
> cannot change easily. I would like to distribute a number of CDs among
> people and I create a database, where people register their CDs, so that
> I knew who's got a particular copy. This process requires that all users
> send me VSN of their CDs - it is prompted to them using
> GetVolumeInformation() from API.
> Now, on my old machine with Win 98, the VSN of the CD is prompted in
> reverse byte order. If the user sends me the VSN in this order - the
> database, which stores all numbers of distributed CDs, will not
> recognize it. I can implement a mechanism which automatically restores
> the proper order of bytes when needed, but I must know whether it is
> normal or reversed. Is there a way, possibly using API, to check which
> rule is used? And why the VSN of CD is reversed, but not of the floppy?
>
> regards,
>
> Gutek

Eric P. napisał(a):
> I think I understood your problem but wanted to make clear the VSN is a
> very old Dos relic MS didn't do much with in the later nineties.
> And it was originally created for a different purpose, to check the same
> disk was still in place, but replaced by Volume Tracking.
>

Is VSN deprecated or not, it is still the best method for me. I checked
what MSDN tells about this "Volume Tracking", but i doesn't seem to be
of any use to me. I need sth that uniquely identifies the CD, is
accessible through Win API, is independent among Windows versions and is
automatically added to a CD when burned. Could you please suggest some
other API function that meets these requirements?

If this is not a problem, can you (or anybody) check VSN of any CD on
your old Win 98 machine and then on XP, please? And if confirmed, can
you explain this, please?

Kind regards,

Gutek

Eric P. napisał(a):
> I think I understood your problem but wanted to make clear the VSN is a
> very old Dos relic MS didn't do much with in the later nineties.
> And it was originally created for a different purpose, to check the same
> disk was still in place, but replaced by Volume Tracking.
>

Could you give me some example source code of how to read directly the
bytes of the CD which store the VSN, please? I did some assembler before
so maybe I'll manage to figure it out somehow...

regards,

Gutek

dg1261 napisa³(a):
> "Gutek" <beztego_gutkowski@itego_vp.pl> wrote:
>
>>...can you (or anybody) check VSN of any CD on
>>your old Win 98 machine and then on XP, please?
>
>
> Gutek,
>
> I just checked a random data DVD, and got the following results from a "dir"
> command:
>
> Win98se: F001-5C78
> Win2000-sp4: 785C-01F0
> WinXP-sp2: 785C-01F0
>

Thanks,
Seems that this is a rule for Win9x systems. I think that one might
check the lpFileSystemNameBuffer variable from:

http://msdn.microsoft.com/library/de...nformation.asp

and apply GetVersion() to determine the win version. When the file
system is CDFS (or for any other than FAT, FAT32, NTFS) and GetVersion
indicates Win9x family we can switch the bytes. Am I right?

regards,
Gutek

"Eric P." <(E-Mail Removed)> wrote:
> Format: [Seconds/Hundredth] + [Month/Day of mo] = High word
> [Hour/Minutes] + [Year] = Low word

Eric,

Could you clarify what you mean by "format"? For example, is [Hour/Minutes]
and [Year] separate bytes of a word? Or is [Hour/Minutes] converted and
arithmetically added with [Year] to form a very large number that is
converted to a hexadecimal word? Perhaps a brief example of the conversion
would help illustrate the formula.

What I'm wondering here, is whether Gutek might be able to determine which
form of the VSN is being used by assuming the year 2005 is in there
somewhere.