I seem to be missing a key peice of info. I was wondering in 0.2.3 how to setup the USB thumb drive to a specific drive upon boot up like in the previous versions it used to be refered to as Drive U: now it seems it is refered to after the primary particitian or basically in my system drive D: which happens to be where I store my program data and where programs get installed. Is there some provision or way to setup the thumb drive to a specific drive letter?

Thanks in advance to any advice you may have or particular post you was able to find to help me in this endevour.

MkMigrateInf.cmd has been updated as per this topic:
http://www.msfn.org/board/2-t131770.html

What Windows did you run the program under? Was it the same Windows as before, when it worked? Was it the same USB stick?
Please attach migrate.inf in ~BT directory on the USB stick.

Oh I am sorry, I ran the program on XP Pro SP 3 to do an XP Pro SP 3 install. I currently have Windows 7 on my lappy and figured that using XP to make the install was the safest especially when making an XP install. I have been using the same 2 gig. USB stick the whole time - setup as an NTFS bootable device (currently), back then I was using 16 bit bootable device for speed.

As far as to your other question, I was using your version 0.1 (not the beta) until just recently until I happen to come across your site a couple of days ago and noticed that you had an update. And then felt the urge to find my pilots liscence due to the number of options available for prepping the USB device. LOL! As far as the 0.1 it was still using U: drive reference, but I didn't have HP formating tool set the device to NTFS bootable device either. So it could be the fact that I switched to NTFS, not exactly sure. Are you thinking that this could be a bios thing?

For some reason this has failed. So I am now trying it a new install that is just a plain Jane install, meaning no Extra emenities added into the install like IE8, dotNet, the patches and NLite reg tweaks. I just have SP3 slipstreamed into the install. That is it.

BTW sorry for the LLOONNGG explanation earlier, I didn't realise what you was asking until I read Pipsters thread. Truly interesting. Anyway to better answer your question, I ran your program on a fresh install of XP Pro SP3 to make a new install of XP Pro SP3 after which I noticed that some of my programs where being installed on the USB thumb drive. The thumb drive used is an ULTRA 2 gig. which has been used extensively for these purposes.

FYI the link in your message post 70 of thread titled, "USBstick take letter D and not U, I choose to assign U to the USBkey.." points to the last page of the thread not to page 3 post 56 where the command file can be found by cdob, if this is even the file you was mentioning earlier. It took me quite a while to find this file in the thead. But it is truly an amazing story. Poor Poor Pipster.... LOL! Sorry couldn't resist. ROTFL!!! He truly made a great test subject.

It still failed. I still get D: not U: as the reference to the drive.

I am now trying HP's Prep tool, but still using 0.2.3 to make the install on the USB without copying the Migrate file. It still failed. And failed when I copied the migrate.inf file over.

Let me try with 16 bit fat, where it worked before with HP's prep tool and 0.1 version of the program, but this time will be with 0.2.3 and its prep tool without the migrate.inf file. Well it failed here too. I get D: instead of U:.
And I again tried copying the migrate.inf file, it still failed yet again.

Not sure what to try next.

I have been just going to the text part of the install and I get the D: to the thumb drive. Also before when it did work with 0.1 version, my drive topology was:

c: Partition 1 (XP Install)
D: Partition 2
E: Partition 3 (Hidden)
F: DVD

U: USB Thumbdrive

Currently on XP:

C: Partition 1 (XP Install)
D: USB Thumbdrive
E: Partition 2
F: DVD
G: Partition 3 (Hidden)

When I ran the MkMigratge_b.cmd each time (even on 16 bit fat), it could not find #7, and had to make adjustments.

I hope all of this helps. It is getting pretty late for me here. So I am going to turn in.

Attached is Click to view attachment.

Thanks so much for any help you can provide to this.

@Macster
Which ParentIdPrefix does USB Thumbdrive use at regular windows?

Oh sorry for the late responce. ParentIDPrefix for the current install of XP is 8&9013452&0. (Sorry, this is for the Sony 256 MB.)

Edit:

Oops, I gave you the wrong one. I accually have two USB Thumb Drives.

1. Sony 256 MB Thumb
2. Ultra 2 GB Thumb.

Both of these have been used on the current XP install.

The ParentIDPrefix for the Ultra 2 GB is 8&35debb9c&0.

Try the attached migrate.inf, place it in ~BT directory on the USB stick.

Did USB stick get letter U: ?

Yep, I got U: ... reference to the Ultra thumb on fat 16 and NTFS. It is amazing one Byte can make that much difference. WOW! So why did you change it from a 7 to an 8? I don't have a hex descriptor, (but I can read ASCII on occasions and mainly numbers) so I do not know where this playes in the file. It would appear that you guys are able to detect why this is happening (meaning the D: instead of the U: stuff).

Now I have another question, as soon as I install XP again would the ParentIDPrefix change? If so, would it make the file you just gave me obsolete? <already answered)

Thanks all the same.

Edit:

I just answered one my questions about the file being obsolete, I guess it still maintains the ParentIDPrefix after a ReInstall of XP. So does migrate.inf reintroduce the ParentIDPrefix or does the install come up with it and migrate.inf utilizes that same ID?

@macster
@ilko_t

What if I split the group of posts and make a new separated "specific 7& vs. 8&" thread, in order to "lighten" the present "general" one?

jaclaz

Good idea

I did some more "cleaning by splitting" of recent issues.

Maybe it's time to do a "global" splitting, like I did on boot-land for Amalux's Tutorial (which was going as well "out of control"):
http://www.boot-land.net/forums/index.php?showforum=31

jaclaz

I wonder- what would happen if we put in migrate.inf both values 7 and 8 pointing to the same drive letter?
If not possible- maybe put first entry, with 7 as U: and 8 for say W:, would that cover all possibilities?
Has anyone seen prefix starting with 6, or 9?

@Jaclaz- thanks for cleaning up

@macster

Did you prepare on AND install Windows to the same machine?
If yes- does it have USB card reader?
If no- does both machines have USB card readers?
Can you test with the attached migrate.inf, does USB stick get letter U:? If doesn't work- change the second U: to W:.

Poor Poor Macster, sorry couldn't resist too. A new tester volunteered.

I haven't found a full ParentIdPrefix explanation.

Windows store drive letter at HKLM\SYSTEM\MountedDevices.
Migrate.inf contains these drive letter settings.
Assumption: current running windows and new installed use the same MountedDevices string.

This assumption is false today.
E.g. Windwos 7 use a different MountedDevices. http://www.msfn.org/board/index.php?s=&...st&p=863404

A string RemovableMedia#7&*&0 is used very often.

There is a example machine with ControlSet007 http://www.msfn.org/board/index.php?s=&...st&p=852520

A new installed windwos useOld and new windows crates different ParentIdPrefix.
RemovableMedia#8&*&0 hat to be changed to RemovableMedia#7&*&0.

Another example shows a different behaviour http://www.msfn.org/board/index.php?s=&...st&p=880180
ParentIdPrefix 8&35debb9c&0 is used at current running and new installed windows.
This is different to the previous example.

A clear solution is missing so far.

@ilko_t
I've only RemovableMedia#7&*&0.
U: and W: is a good idea as a work arround.

Added:
I've found a machine with

NextParentID 1168ba30.7 reminds to ParentIdPrefix 7&1168ba30.
And the dword seems to be a counter to RemovableMedia#?&*&N
New assumption: this counter is set to zero at new installation.
If a error occour (bad connections) and windows redetect the hardware, this counter is increase by one.

Added 2:
Overall there is a new approach, set up to three letters. Thanks to ilko_t.
U: MountedDevices as read from current running windows, XP style assumed
T: RemovableMedia adjusted: counter set to zero: RemovableMedia#?&*&0
S: RemovableMedia adjusted: counter set to zero and 7 set: RemovableMedia#7&*&0

Yes, I was able to prepare two installs for the same system in series and they both got the U: reference with the same file. Thanks.

As fas as a USB card reader, I really don't understand what you mean. I have a USB hub connected to system as well as other USB printers (HP Deskjet 932C, HP Photosmart C3180 All-in-one) but these don't don't have drivers loaded as of yet when your program was running. If you are meaning a USB SD memory chip reader (the type that goes into phones and cameras), I have one of those on the C3180, but like I said earlier the drivers weren't loaded for it and I didn't see anything in the Device Manager in regards to this not being identified. Further more the printer has of yet to be turned on, it is kept off until needed - so XP doesn't even know of its existance until I turn it on. I hope this helps.

@cdob

I am trying your last version of the MkMigrate script. I will let you know if it works. thanks.

@cdob

Script output:

call === MontedDevices as read
call === convert MountedDevices, adjust RomovableMedia
warning: MountedDevices does not contain RemovabledMedia#7
fixing S: to RemovableMedia#7

copying file to the XP install .~bt forder.

Well I got U: (with NTFS) this time. Interesting?

Cause my current topology was (before running the XP install):

C: Partition 1 (XP)
D: Partition 2
E: DVD
F: Partition 3 (Hidden)

U: Thumb

Thanks to the file that ilko_T gave me.

I am wondering if it has anything to do with the ambient topology. Whether the install is reading some of the registry (or the partition tables on the HD) as far as the placing of particians and such? Cause before I was getting D: for the thumb when the thumb was already set at D:.

Edit:

Well I tried changing the drive reference to the USB to Z: in Windows, reran the script, and it still came up with U: during the install, so it would appear that it is fixed.

Thanks, U: was expected at your machine.

Remember ParentIdPrefix 8&35debb9c&0 is used at current running windows and new installed windows.


S: should work at cases, if a change is required.
Compare http://www.msfn.org/board/http-msfn-org-bo...p;view=findpost

Thanks cdob.
Maybe add W: with 8&*&0 for cases when stick is prepared on machine using 7&*&0, and installed on machine using 8&*&0.

Actually I dislike the current work around, that's not a nice solution.
I seek and prefer a ParentIDPrefix explanation still.

I addition searching the net I found further hints:
a digital camera and MP3 player use ParentIDPrefix&6.
Even some memory sticks seems to use ParentIDPrefix&6.
Do we support install XP from a digital camera?
This would require ParentIDPrefix 6 7 8 and all possible combinations. Seems redicilous.

I realy, realy like to get a ParentIDPrefix explanation.
I prefer to get some further custom reposts. Sorry, therefore I won't add W: currently.

Any clean solution is highly welcome, has to support running Winwos 2000, XP, Vista and 7.

You are right, as always. Clean explanation would be nice.
However, wouldn't 6,7 and 8 & ParentIDPrefix & 0 cover all possible cases when USB/memory stick is prepared on 2k/xp/2k3 machine? This means 3 letters...

And maybe it would also solve the "racism" issue about letter V: :

• U:
• V:
• W:

Yes , I do like it better than:

• U:
• W:

And the "Association for the promotion of a wider use of letter V in drive assignments" will probably stop nagging me.




jaclaz

Here is a bit more information:
http://bbs.driverdevelop.com/read.php?tid=96099
http://translate.google.com/translate?hl=e...GGGL_en___GB229


Here is good explanation of the device tree:
http://msdn.microsoft.com/en-us/library/aa489660.aspx


Osronline have a nice program DevTree, which can display tree from PNP manager perspective, free registration is required for download link:
http://www.osronline.com/article.cfm?article=97

About the algorithm calculating the hash- in AutoIt forum helped with it and provided similar code to calculate it in AutoIt, now I can understand the C macro used to calculate it:
http://www.autoitscript.com/forum/index.php?showtopic=104426

Can you figure out why exactly the level changes in some occasions? Which one is the missing "hop"? How an internal card reader for example would move one hop up, getting level 6 for example?

I seem not able to connect to the autoit place.
And of course I do not understand the C code.

Anyway keep going.

jaclaz

I'm a human only and the crystal ball is empty

Well maybe another kernel, hal or ACPI configuration does interfere too?

Device tree is a good explanation in general: does match in most cases.

Of coure there exeptions.

Given removable USB Stick direct attached to USB port: ParentIdPrefix 7&*&0

Driver stack:
1 ntoskrnl.exe, hal.dll
2&daba3ff&0 acpi.sys
3 pci.sys - no ParentIdPrefix
4&11cdd0bd&0 usbehci.sys
5&38c8e674&0 usbhub.sys
6 usbstor.sys - no ParentIdPrefix
7&776bc3a&1 disk.sys

Next remove USB Stick, attach a USB hub. And insert USB Stick to the USB hub.
Device tree is one step deeper: I expected ParentIdPrefix 8&*&0
However ParentIdPrefix stays at 7&*&0.
A double usbhub.sys dosn't matter, driver is loaded and used once.

I recogiced strange behaviour using a USB controller without a SerialNumber.
This is a fixed USB hard disk. MountedDevies does NOT use ParentIdPrefix.

Windows PNP the hard disk for each USB port.



Recogince the main difference:
USB hard disk, ParentIdPrefix 6&28d260fd&2 usbstor.sys. (6th driver in stack)
USB stick, ParentIdPrefix 7&776bc3a&1 disk.sys (7th driver in stack)

Idea:
Drive SerialNumber and relating windwos configuration (GlobalDisableSerNumGen, IgnoreHWSerNum*) may be importand.

A USB stick with a serial number get ParentIdPrefix 7&*&0 at the same USB port.

I don't pocess a USB stick without a serial number and can't test this.


Finally: yes, the driver stack does set ParentIdPrefix N&*&*.
Windows may connect ParentIdPrefix to different drivers. True reason is unkown.


Added, more ideas:
A addional (non windows default) driver in stack may cause ParentIdPrefix 8&*&*.
A default windows installation set ParentIdPrefix 7&*&0.
A end user install some addional USB driver into driver stack: ParentIdPrefix is changed to 8&*&*.

You've got a lovely knowledgeable crystal ball, I have no doubts

Well, just post some details of the USB sticks you have handy as seen by Chipgenius and I can surely give you a link to a manufacturer tool for at least one of them with which you can zero out the serial number.

@ilko_t
Today I was able to reach the Autoit forum link, so you have something theoretically capable of generating the hashes and you are keeping it for yourself?

jaclaz

Not sure which one you have in mind, but is it the attachmen t in post #97?
http://www.msfn.org/board/solved-usbstick-...p;view=findpost
http://www.msfn.org/board/index.php?act=at...st&id=26992

And BTW- not only theoretically capable, practically as well

I must have read it wrongly, in there, which is here :
http://www.msfn.org/board/solved-usbstick-...80-page-96.html
(stoopid board software is still working, or better NOT working on a random base)
You said you had a C program which you couldn't translate to AutoIT.
On the AutoIt board you posted an AutoIt program:
http://www.autoitscript.com/forum/index.ph...104426&st=8

that seemingly has glitches in it, as seen in later posts.

So I will try to rephrase :
Have you got now a fully working AutoIt program?
If yes, you should also have understood the algorithm behind it, which is what I would be interested in, NOT into the CODE (C or AutoIt or whatever) that implements the algorithm.

jaclaz

Say string="abs"

1. Uppercase it
2. Put the ASCII code for each symbol in an array
3. For each element in the array calculate $iHash = 37 * $iHash + $Array[$i]
4. Output is the hexadecimal value of the modal of the positive(abs) result of (314159269 * $iHash) divided by 1000000007.

Apparently in the above calculations C value types uint and int should be used to store results in, or values get different presentation. Still can't quite figure out this part, despite all the reading the last couple of days.