If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
ABSTRACT
This investigation shows that the "rdisk()" parameter in the boot.ini file represents a hard drive in terms of its displacement from the head of the hard drive boot order in the BIOS. The value of n in "rdisk(n)" expresses this displacement, where n is an integer value starting with 0, and where "rdisk(0)" represents the hard drive which is at the head of the hard drive boot order, i.e. the hard drive at zero displacement from the head of the hard drive boot order. The BIOS used in the investigation was the Phoenix Technologies BIOS as supplied in Dell Dimension desktop PCs. HARDWARE Dell Dimension XPS-R450 with a Phoenix Tech BIOS, (3) Maxtor DiamondMaxPlus 9 hard drives connected to (1) SIIG IDE PCI controller card used in the 1st half of the investigation, and connected to (1) motherboard IDE controller used in the 2nd half of the investigation. HARD DRIVE CONFIGURATION IDE channel 0, Master - 80GB hard drive IDE channel 0, Slave - 40GB hard drive IDE channel 1, Master - 120GB hard drive Each HD had a Master Boot Record (MBR), each HD had as its partition #1 a Primary partition that 1) had a Boot Sector, 2) was marked "Active", and which 3) contained the boot files ntldr, boot.ini, and ntdetect.com . SOFTWARE CONFIGURATION Microsoft WindowsXP Pro installed in partition #1 of each HD. boot.ini file in the 80GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 2, part 1" /fastdetect boot.ini file in the 40GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 2, part 1" /fastdetect boot.ini file in the 120GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 2, part 1" /fastdetect Each of the above boot.ini file entries under the line "[operating systems]" specified an OS in partition #1 of one of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)". The character string between the quotes in each OS entry became a line in the on-screen menu displayed by ntldr at boot time, and it was to aid in identifying which HD got control from the BIOS (i.e 80GB, 40GB, or 120GB) and which "rdisk()" value each line corresponded to. A file with a name identifying the HD which contained it was put on the Desktop of each OS. This was to aid in identi- fying the HD of the OS that was loaded. EXPERIMENT Each HD was in turn put at the head of the BIOS's hard drive boot order and the PC was started. Each of the three entries in the on-screen boot menu was selected in turn, and the OS that loaded was recorded. Since the boot.ini files contained entries only for the partition #1 on each HD, the experiment was a specific test for the meaning of the "rdisk()" parameter. Then the order of the 2nd and 3rd HD in the hard drive boot order was reversed in the BIOS, and the above experiment was repeated. Then, the hard drives were disconnected from the IDE PCI controller card and connected to the IDE controller on the motherboard, and the entire experimental sequence detailed above was repeated. A total of 36 boot-ups were executed. RESULTS The following results were identical for both the PCI IDE controller case and for the motherboard IDE controller case: HD boot order: 80GB, 40GB, 120GB boot menu entry selected: HD the OS booted from: (80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1 (80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1 (80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1 HD boot order: 80GB, 120GB, 40GB boot menu entry selected: HD the OS booted from: (80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1 (80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1 (80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1 HD boot order: 40GB, 80GB, 120GB boot menu entry selected: HD the OS booted from: (40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1 (40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1 (40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1 HD boot order: 40GB, 120GB, 80GB boot menu entry selected: HD the OS booted from: (40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1 (40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1 (40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1 HD boot order: 120GB, 40GB, 80GB boot menu entry selected: HD the OS booted from: (120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1 (120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1 (120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1 HD boot order: 120GB, 80GB, 40GB boot menu entry selected: HD the OS booted from: (120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1 (120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1 (120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1 DISCUSSION The OS always booted from the hard drive having a position in the hard drive boot order expressed as the n in "rdisk(n)" parameter of the boot.ini file entry. This correspondence persisted throughout all all permutations of the hard drive boot order and despite which IDE controller the HDs were connected to. Whether this is the case in other less common BIOSes is unknown by this investigator. But since the Phoenix Technologies' BIOSes are used by many large PC manufacturers, it is probably a very common meaning of "rdisk()" among modern PCs running a Microsoft Windows operating system. *TimDaniels* |
#2
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
Timothy Daniels wrote:
ABSTRACT This investigation shows that the "rdisk()" parameter in the boot.ini file represents a hard drive in terms of its displacement from the head of the hard drive boot order in the BIOS. The value of n in "rdisk(n)" expresses this displacement, where n is an integer value starting with 0, and where "rdisk(0)" represents the hard drive which is at the head of the hard drive boot order, i.e. the hard drive at zero displacement from the head of the hard drive boot order. The BIOS used in the investigation was the Phoenix Technologies BIOS as supplied in Dell Dimension desktop PCs. HARDWARE Dell Dimension XPS-R450 with a Phoenix Tech BIOS, (3) Maxtor DiamondMaxPlus 9 hard drives connected to (1) SIIG IDE PCI controller card used in the 1st half of the investigation, and connected to (1) motherboard IDE controller used in the 2nd half of the investigation. HARD DRIVE CONFIGURATION IDE channel 0, Master - 80GB hard drive IDE channel 0, Slave - 40GB hard drive IDE channel 1, Master - 120GB hard drive Each HD had a Master Boot Record (MBR), each HD had as its partition #1 a Primary partition that 1) had a Boot Sector, 2) was marked "Active", and which 3) contained the boot files ntldr, boot.ini, and ntdetect.com . SOFTWARE CONFIGURATION Microsoft WindowsXP Pro installed in partition #1 of each HD. boot.ini file in the 80GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 2, part 1" /fastdetect boot.ini file in the 40GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 2, part 1" /fastdetect boot.ini file in the 120GB HD: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 0, part 1" /fastdetect multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 1, part 1" /fastdetect multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 2, part 1" /fastdetect Each of the above boot.ini file entries under the line "[operating systems]" specified an OS in partition #1 of one of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)". The character string between the quotes in each OS entry became a line in the on-screen menu displayed by ntldr at boot time, and it was to aid in identifying which HD got control from the BIOS (i.e 80GB, 40GB, or 120GB) and which "rdisk()" value each line corresponded to. A file with a name identifying the HD which contained it was put on the Desktop of each OS. This was to aid in identi- fying the HD of the OS that was loaded. EXPERIMENT Each HD was in turn put at the head of the BIOS's hard drive boot order and the PC was started. Each of the three entries in the on-screen boot menu was selected in turn, and the OS that loaded was recorded. Since the boot.ini files contained entries only for the partition #1 on each HD, the experiment was a specific test for the meaning of the "rdisk()" parameter. Then the order of the 2nd and 3rd HD in the hard drive boot order was reversed in the BIOS, and the above experiment was repeated. Then, the hard drives were disconnected from the IDE PCI controller card and connected to the IDE controller on the motherboard, and the entire experimental sequence detailed above was repeated. A total of 36 boot-ups were executed. RESULTS The following results were identical for both the PCI IDE controller case and for the motherboard IDE controller case: HD boot order: 80GB, 40GB, 120GB boot menu entry selected: HD the OS booted from: (80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1 (80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1 (80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1 HD boot order: 80GB, 120GB, 40GB boot menu entry selected: HD the OS booted from: (80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1 (80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1 (80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1 HD boot order: 40GB, 80GB, 120GB boot menu entry selected: HD the OS booted from: (40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1 (40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1 (40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1 HD boot order: 40GB, 120GB, 80GB boot menu entry selected: HD the OS booted from: (40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1 (40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1 (40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1 HD boot order: 120GB, 40GB, 80GB boot menu entry selected: HD the OS booted from: (120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1 (120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1 (120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1 HD boot order: 120GB, 80GB, 40GB boot menu entry selected: HD the OS booted from: (120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1 (120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1 (120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1 DISCUSSION The OS always booted from the hard drive having a position in the hard drive boot order expressed as the n in "rdisk(n)" parameter of the boot.ini file entry. This correspondence persisted throughout all all permutations of the hard drive boot order and despite which IDE controller the HDs were connected to. Whether this is the case in other less common BIOSes is unknown by this investigator. Still lying. The Phoenix bios is in fact the least common of the 3 majors. But since the Phoenix Technologies' BIOSes are used by many large PC manufacturers, Bugger all, actually. it is probably a very common meaning of "rdisk()" among modern PCs running a Microsoft Windows operating system. Wrong, as always. And have fun explaining why ALL the documentation of the ARC path naming convention fails to mention the hard drive boot order at all when documenting the rdisk() parameter. There has GOT to be a reason for that. AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. |
#3
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
"Rod Speed" non-sequitured:
....have fun explaining why ALL the documentation of the ARC path naming convention fails to mention the hard drive boot order at all when documenting the rdisk() parameter. There has GOT to be a reason for that. AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. All I did was report reality. What does it matter what some obscure specification says? Do you run a spec or a PC? *TimDaniels* |
#4
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
"Rod Speed" wrote:
ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. Maybe. But Dell is a MAJOR brand. *TimDaniels* |
#5
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
Timothy Daniels wrote
Rod Speed non-sequitured Lying, as always. ....have fun explaining why ALL the documentation of the ARC path naming convention fails to mention the hard drive boot order at all when documenting the rdisk() parameter. There has GOT to be a reason for that. AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. All I did was report reality. No you didnt. You reported what YOU see on a badly implemented system and claimed that that proved that the rdisk() param is the boot drive order number on all systems out there. That is just plain wrong. What does it matter what some obscure specification says? It matters because it proves that your claim that the rdisk() parameter is ALWAYS the boot order sequence number is just plain wrong when that spec for the boot.ini file, written by the designers of that boot.ini file dont even mention the boot order sequence number with rdisk() Do you run a spec or a PC? Never ever could bull**** its way out of a wet paper bag. |
#6
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
"Rod Speed" wrote:
AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. What's so hard about that? In my normal system, which contains 8 or 9 bootable clones, the boot.ini file in each primary partition contains a generic boot.ini file that has 10 optional entries (the max for my BIOS). The comment character string in each entry indicates its rdisk() and partition() value, and knowing where the desired clone is in the boot order, I can boot to any clone in the system. Which is harder - knowing the position of a HD in terms of IDE channel no. and Master/Slave setting, or knowing where the HD is in the hard drive boot order? But the Phoenix BIOS, in fact, accomodates geriatric users such as yourself. It has as a DEFAULT hard drive boot order which is tied to the physical position of each hard drive: Master, IDE channel 0 Slave, IDE chennel 0 Master, IDE channel 1 Slave, IDE channel 1 Thus, if one doesn't want to adjust the hard drive boot order (or doesn't know how), one can just rely on the default hard drive boot order. To change which hard drive is at the head of the order, one must physically rearrange the hard drives. But hey(!), some people *like* restrictions more than convenience. *TimDaniels* |
#7
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
Timothy Daniels wrote
Rod Speed wrote ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. Maybe. No maybe about it. But Dell is a MAJOR brand. Irrelevant to your original pig ignorant claim that the rdisk() param ALWAYS refers to the boot order sequence number, on all systems, regardless of the bios. ALL you have actually shown is that ONE particularly badly designed system does it that way. And that is a terminally stupid way to design it too, because even someone as stupid as you should be able to grasp that if the rdisk() param does refer to the boot order sequence number, you have to edit the boot.ini whenever you change anything in the boot order sequence that shifts the drive that line in the boot.ini refers to in the order. That is just plain completely ****ed. |
#8
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
Timothy Daniels wrote
Rod Speed wrote AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. What's so hard about that? Never ever said anything about being hard. Just stupid to need to edit the boot.ini files when a change is made to the boot order. If you do want multiple copys of bootable OSs available to boot between quickly, the only approach that makes any sense at all is to select which system to boot from the boot.ini, and to have that boot.ini duplicated on at least two physical drives, so that even if one of the drives does die, the worst you have to do is to change the boot order in the bios and continue to select the system to boot from the boot.ini menu. You would by definition know that some of the menu items arent available when they are on the dead drive. It makes absolutely no sense to have to edit the boot.ini to be able to boot the system you want to boot after the boot order has been changed. It makes a hell of a lot more sense for the rdisk() parameter to be the physical drive on the particular controller specified in the boot.ini instead with that only needing to be edited if drives are rearranged on a particular controller in the master/slave sense. In my normal system, Which has always had a completely ****ed mindlessly silly config. which contains 8 or 9 bootable clones, Mindlessly silly for starters. the boot.ini file in each primary partition contains a generic boot.ini file that has 10 optional entries (the max for my BIOS). It makes a hell of a lot more sense for all those boot.ini files to be identical and reflect the location of the bootable systems regardless of the boot order specified in the bios. Then regardless of which physical drive is booted by the bios boot list, the user just selects from the same boot.ini menu which particular system he wants to boot. The comment character string in each entry indicates its rdisk() and partition() value, You dont need to bother if the boot.ini files are all identical and the rdisk() value is the physical drive on the particular controller. and knowing where the desired clone is in the boot order, I can boot to any clone in the system. You dont have to know if the boot.ini files are all identical and the rdisk() param doesnt vary with the boot order in the bios. Which is harder - knowing the position of a HD in terms of IDE channel no. and Master/Slave setting, That only has to be known when writing the single boot.ini file that is on every bootable drive. No need to have to know that when a drive has failed and you have changed the boot order in the bios to get it to get the bios to boot a drive. AND what matters is that there is absolutely no point in the rdisk() parameter referring to the entry in the bios boot order list at all. None, zero, nada, ziltch. Its just a completely ****ed and stupid way to design a system. or knowing where the HD is in the hard drive boot order? But the Phoenix BIOS, in fact, accomodates geriatric users such as yourself. No it doesnt, the ****ed approach it uses fails when the drive you normally have the bios boot is no longer bootable for whatever reason. In that case you have to BOTH change the boot sequence, AND edit the boot.ini thats on that drive. That is completely ****ed. It has as a DEFAULT hard drive boot order which is tied to the physical position of each hard drive: Master, IDE channel 0 Slave, IDE chennel 0 Master, IDE channel 1 Slave, IDE channel 1 The default order is completely irrelevant when configuring the system so you can quickly boot anything thats on other than a drive which has failed or has been unplugged etc. Thus, if one doesn't want to adjust the hard drive boot order (or doesn't know how), one can just rely on the default hard drive boot order. Useless if the reason for the multiple bootable OSs is to allow you to quickly boot something useful on a drive failure. To change which hard drive is at the head of the order, one must physically rearrange the hard drives. Terminally stupid approach. But hey(!), some people *like* restrictions more than convenience. What a terminal ****wit you have always been, child. |
#9
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
"Rod Speed" wrote in message
Timothy Daniels wrote: [snip] DISCUSSION The OS always booted from the hard drive having a position in the hard drive boot order expressed as the n in "rdisk(n)" parameter of the boot.ini file entry. This correspondence persisted throughout all all permutations of the hard drive boot order and despite which IDE controller the HDs were connected to. Whether this is the case in other less common BIOSes is unknown by this investigator. Still lying. The Phoenix bios is in fact the least common of the 3 majors. But since the Phoenix Technologies' BIOSes are used by many large PC manufacturers, Bugger all, actually. it is probably a very common meaning of "rdisk()" among modern PCs running a Microsoft Windows operating system. Wrong, as always. And have fun explaining why ALL the documentation of the ARC path naming convention fails to mention the hard drive boot order at all when documenting the rdisk() parameter. There has GOT to be a reason for that. And here's that wet paper bag for Roddy. AND its a stupid way to implement a system anyway because the boot.ini file would have to be changed when the boot order is changed. ALL the evidence points to the fact that its a terminal stupidity that has been perpetrated in the Phoenix bios and that it doesnt get mentioned just because the phoenix bios is by far the least commonly used of the big 3. And another one. Roddy grasping at fibres. |
#10
|
|||
|
|||
meaning of "rdisk()" in boot.ini file
"Rod Speed" floundered:
It makes a hell of a lot more sense for all those boot.ini files to be identical and reflect the location of the bootable systems regardless of the boot order specified in the bios. Then regardless of which physical drive is booted by the bios boot list, the user just selects from the same boot.ini menu which particular system he wants to boot. As I explained, each bootable partition in my PC has a generic boot.ini file that allows booting from ANY of 10 partitions in the system. That means if one HD fails, the boot.ini file in any partition in any of the remaing HDs could be used without editing a thing. All you have to know is where the clone is that you want to boot. The boot.ini file doesn't have to know anything - indeed, they're all the same. The comments in each entry tell you the values of rdisk() and partition(), and you just choose the one having the path that you want. I'm sorry that this has never occurred to you, but I'm happy to educated you on modern techniques. *TimDaniels* |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
BenQ Dw1620 Dvd burner problem | oops | Cdr | 2 | May 20th 05 04:40 AM |
aopen cdrw - 'session fixation error'? | c p | General | 0 | May 10th 05 08:47 PM |
Fixing HDD errors | perrin | Storage (alternative) | 3 | March 27th 05 02:17 AM |
PartitionMagic Question | Harvey Gratt | Storage (alternative) | 43 | February 5th 05 08:20 PM |
Help! - The dreaded buffer underrun | XPG | Cdr | 5 | August 31st 03 06:27 PM |