Jump to content

BIG windows 7 surprize


dirty
 Share

Recommended Posts

Man like most of people in the world i downloaded Windows from net Build 7600 thought it was official release.

i believe build 7600 was RTM release.

Autoit @OSVersion for this Windows 7 returns "WIN_VISTA", so i thought YEAH !!! i dont have to write code separate for Windows 7. To bad i was wrong.

I recently got lucky and made friends with guy working at Microsoft, he bought me Windows Ultimate 32/64bit from Microsoft members store for only $50.00 plus tax.

As soon as i installed Fresh copy of "LEGAL" Windows 7 64bit and opened my favorite programming language "AUTOIT" for editing some codes, i noticed that my Windows returns WIN_7 and not WIN_VISTA anymore.

Thats not the biggest issue here caz i could just copy and paste Vista codes and count them as Windows 7 and they would work, the surprise comes Windows 7 dealing with registry.

Keep in mind that this effects only Local user registry path or "HKEY_LOCAL_MACHINE"

Normally Built 7600 or RTM Windows 7 Release would write registry files just the way you'd expect, for example:

64bit program writing registry into "HKEY_LOCAL_MACHINE\Software\something"

and 32bit it saves it into "HKEY_LOCAL_MACHINE\Wow6432Node\Software\something"

You must have Legal Windows 7 64bit installed to test this.

Ok knowing that try this:

1st Create and import to registry this:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\AAA]

2nd create new autoit script (VERY IMPORTANT i am not joking)

RunWait (@WindowsDir & '\regedit.exe /E "test.reg" "HKEY_LOCAL_MACHINE\Software\AAA"')
MsgBox(0,'','exported from registry')
RunWait (@WindowsDir & '\regedit.exe /S "test.reg"')
MsgBox(0,'','imported into registry')

and compile (x86) and compile with options and use X64 version of autoit3

/aut2exe. Both files should be named differently :huggles:

seriously just create new one please.

3rd Knowing you have "HKEY_LOCAL_MACHINE\Software\AAA" in your registry run compiled X64

4th Look into registry and you will see no changes made. AAA is right were it was before you run the script "HKEY_LOCAL_MACHINE\Software\AAA"

5th run compiled X64

6th Check registry and see that now AAA is under "HKEY_LOCAL_MACHINE\Software\Wow6432Node\AAA".

Why is this problem ? Well its confusing because not all 32bit apps creating keys in "HKEY_LOCAL_MACHINE\Software\Wow6432Node", instead they stay in "HKEY_LOCAL_MACHINE\Software" thus making it possible to write a script which will save correct registry keys.

Most of my apps that deal with registry files are not working right because of that.

not only this but also same problem with program files folder.

32bit app for some reasons using normal C:\Program Files folder when instead it has to use C:\Program Files(X86) as it did with RTM Windows 7. And because this was 32bit app i compiled code for 32bit OS which saves data from C:\Program Files if OS is 32bit and C:\Program Files(X86) if OS is 64bit, so when this script is executed it saves none existing data from C:\Program Files instead of C:\Program Files(X86) as it should.

This is so weird i am not sure if its me or everyone.

At this point i cant decide what to do, use Windows 7 RTM or rewrite everything to what works on my windows version ?

BTW Windows version is 6.1.7600 build 7600 just like RTM i believe.

I cant decide because probably more users are using RTM windows then one i have.

For example:

RunWait (@ComSpec & ' /c xcopy /E/D/Y "%PROGRAMFILES%\Common Files\Native Instruments\Helper" "saved\Program Files\Common Files\Native Instruments\Helper"',"",@SW_HIDE)

is a part of code for 32bit application which runs in 64bit environment.

Because script is compiled without X64 box checked (or 32bit) code should save files from C:\Program Files(X86) to Saved folder and thats what it does, but somehow this program "Native instruments" has saved its junk into C:\Program Files instead of C:\Program Files(X86) as it did with Windows 7 64bit RTM release.

So how the hell do i modify this code to copy files from C:\Program Files instead of C:\Program Files(x86) without changing the code to much ?

Can someone confirm this ? my head hurts its late and i gotta wake up early for work :D

Edited by dirty
Link to comment
Share on other sites

Well after countless times of figuring it out, solution is simple.

Autoit needs few more flags for FileCopy to eliminate the need for RunWait('"' & @ComSpec & '" /c Xcopy', '', @SW_HIDE)at all.

Or maybe there is another way to copy system, hidden or files by date using autoit instead of Xcopy ?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...