Vista compatibility - HKU instead of HKLM

It seems that the new OS requires users to make changes on their profile hives, rather than using the HKEY LOCAL MACHINE hive as we've been doing up to this point.

My request is to move the base HKLM to HKU (The current user hive) used by HoJoPE - this wouldn't break compatibility with XP/Win9x, but would make older scripts using HKLM rendered obsolete or need to be updated - also editing .reg files to point to HKU instead of HKLM

Can a beta modified nativeEX barebone be made available? - I will also modify wb to load hives into HKU using reg.exe from vista, so this is all experimental - not sure yet if will work as exepcted..

It seems that the new OS requires users to make changes on their profile hives, rather than using the HKEY LOCAL MACHINE hive as we've been doing up to this point.

My request is to move the base HKLM to HKU (The current user hive) used by HoJoPE - this wouldn't break compatibility with XP/Win9x, but would make older scripts using HKLM rendered obsolete or need to be updated - also editing .reg files to point to HKU instead of HKLM

Can a beta modified nativeEX barebone be made available? - I will also modify wb to load hives into HKU using reg.exe from vista, so this is all experimental - not sure yet if will work as exepcted..

I suggest to

• define %BaseReg% in script.project
  • HKLM for XP projects
  • HKU for Vista projects
• change all 'RegWrite,"HKLM",... to 'RegWrite,%BaseReg%, ...
• change 'RegHiveLoad,"name","file"' to 'RegHiveLoad,"name","File",%BaseReg%'
  If %BaseReg% is missing, it defaults to HKLM

If the HKU way shows as impossible, every 'old' project can still be processed inspite of the changes

Peter

This is just an experiment, if it works then we can take from this point and expand it - ntuser.dat is available all the way down to win95, so it should be safe to use it instead of HKLM..

Why not change to HKCU for every OS?
It's just a mount point. Isn't it?

Yes it is only a mount point - sorry I've confused the HKEY word - I meant HKCU

@Nuno

There is a new web server psc.boot-land.net/Beta.

It contains a 100% copy of the actual nativeEx_barebone with the changes I suggested above.

With <script.project>[Variables]%BaseReg%=HKLM (delivered) it boots into qEmu like nativeEx_barebone.

To try a different mount point:

• Define <script.project>[Variables]%BaseReg%=????
• Change RegHiveLoad to either

• hardcoded ???? instead of HKLM

• accept ???? as optional fourth argument like descibed above

Good luck!

Peter

Thank you, I will try it - fingers crossed over here..

Why not change to HKCU for every OS?
It's just a mount point. Isn't it?

Until now we have the hardcoded mount poin HKLM.
We would change into the hardcoded mount point HKCU.

Do old OSs like NT4, W98 or ME work with it?
I did not test and I'm sure you did not test either.

What about new OSs coming next years?

A professional solution is to define the mount point depending on OS.

Peter

Yes, I agree with you - unfortunately, ms dazzles everything up..

Running without administrative skills renders reg.exe useless, altought now I can see all written keys inside the HKCU portion of the registry - but still no good results..

Until now we have the hardcoded mount poin HKLM.
We would change into the hardcoded mount point HKCU.

Do old OSs like NT4, W98 or ME work with it?
I did not test and I'm sure you did not test either.

It works on NT4, W98SE and XP. Guess it will too, on the other ones you mentioned.

What about new OSs coming next years?

A professional solution is to define the mount point depending on OS.

Peter

You mean in the future when there are still registries, but no current users anymore?
But sure, variables are usually better than hardcoding, the question is only, if they are neccessary?

Yes, I agree with you - unfortunately, ms dazzles everything up..

Running without administrative skills renders reg.exe useless, altought now I can see all written keys inside the HKCU portion of the registry - but still no good results..

You mean you need administrator rights under Vista to access HKCU? How does one install software?

You can write the current user's profile hive - ntuser.dat, more informations can be found here:
http://msdn2.microso...y/aa965884.aspx

This was a link provided by Jaclaz in our discussion here:
http://www.boot-land...?...ost&p=11106

Another option is renaming the EXE to MyApplication-Setup.exe or add a new .manifest file wich will force the user to enter administrative permissions.

Another way is pressing the right-click button on your mouse over the application and select the "Run as Administrator" option..

You can write the current user's profile hive - ntuser.dat, more informations can be found here:
http://msdn2.microso...y/aa965884.aspx

Another option is renaming the EXE to MyApplication-Setup.exe or add a new .manifest file wich will force the user to enter administrative permissions.

Another way is pressing the right-click button on your mouse over the application and select the "Run as Administrator" option..

I don't understand. The virtualisation does not affect HKCU, cause one does not need administrator rights to access it, so no need for redirecting things
That's why i see also no reason for switching to administrator mode by any other means.
Somehow i can't follow you.
HKCU should be readable and writable, without need for any changes to the rights.

I'm still testing a lot of these changes myself so it will take a bit more to completely understand what is going on.

Unfortunately I am now sure that my testings were not done correctly - trying out a wb from last month with UAC disabled built a perfectly working boot disk (something I hadn't seen since I've shifted to this new OS) based on liveXP.

Then I went back to my work folder and tried to repeat the steps with the new beta and the same project - BSOD again..

Replaced the one month old wb with the latest beta, repeated the build process and - voilá, boot again..

Just to ensure the results were clean, I've deleted the target folder and all work files inside the project, and the same results appeared.

Conclusion: the project seems to be the reason for the faulty results, I'm now restarting my tests...

@MedEvil,

You can't load registry hives into HKCU - only the root hives like HKLM, HKU. From MSDN for RegLoadKey:

hKey
[in] Specifies the key where the subkey will be created. This can be a predefined reserved handle value, or a handle returned by a call to RegConnectRegistry. The predefined reserved handle values are:
HKEY_LOCAL_MACHINE
HKEY_USERS

This function always loads information at the top of the registry hierarchy. The HKEY_CLASSES_ROOT and HKEY_CURRENT_USER handle values cannot be specified for this parameter, because they represent subsets of the HKEY_LOCAL_MACHINE and HKEY_USERS handle values, respectively.

The problem with accessing registry hives directly is that the format is undocumented and tends to change between releases of the OS. New fields were added in Vista which means that even loading a Vista hive from XP can result in registry corruption unless you have a kernel hotfix.

We're getting locked away from changes to modify hives ourselves, maybe the wiser path is to invest time creating non-api dependant ways to manipulate hives - at least for the sake of being supported on future OS releases wich will surely become more restrictive with time..

It's a big loss for MS because in long terms this will mean that even more applications will also become less dependant on Win32API wich in time can be easilly ported to mac or *nix because they're not binded to specific features from Windows OS's.

For future reference, Jaclaz has collected some very nice links to read on the XP/Vista sub-forum regarding to registry here:
http://www.boot-land...?showtopic=1703

It is well known that currently also commercial software suppliers are not yet Vista compatible.
A couple of hardware pieces do not yet run under Vista becaure the drivers are not yet adapted.

Why should we actually waste our effort in trying to run WinBuilder under Vista?

There are still a lot of wishes, suggestions and bugs due to WinBuilder running under W2000 / XP.
These should be fullfilled / fixed with higher priority.

It is not always a proof of cleverness, if somebody changes a running system in order to become 'actual'.
Sometimes it can be a proof of stupidity.

Peter

Well, wb will run perfectly under vista if we disable UAC - the goal here was finding a way to make it run under UAC.

Adding internal support for reading and writing hives inside wb seems the logical step for stable results, otherwise we will be getting way too many problems inside Vista, results can become more stable regardless of platform once we can control how hives are handled all by ourselves and avoid any more needs to use super-administrative powers to run wb.

Further reading from the MS expectatives, applications will become more and more isolated within themselves, not to mention processes that are interfered with virtualizations.

I think that there is a real need to worry right now since people will soon start to shift over to vista, and solutions should take their own research time to be well planned and designed.

Sometimes it's already hard enough to explain people how to select a valid Windows Install CD source and we still read reports of cases where OEM versions cause confusion - Imagine asking everyone to disable UAC.

The way to do things right is depending on ourselves and not on win32 API anymore..

Adding internal support for reading and writing hives inside wb seems the logical step for stable results, otherwise we will be getting way too many problems inside Vista, results can become more stable regardless of platform once we can control how hives are handled all by ourselves and avoid any more needs to use super-administrative powers to run wb.

The current WinBuilder using win32 API runs fine with W2003 and XP SP2.

About the use of Vista e.g. Paraglider and Jaclaz seem to have the same opinion like me: Never intentionally!

In my opinion is is wise first to fix the current bugs / missing features like StrFormat, ShellExecuteWait, RegGetNext, upload issues etc., and after that with a really stable WinBuilder release go to replace the API by ???

Peter

Nuno,
I read Peter's comment as:
"wouldn't it be better to concentrate our efforts on making XP/2003 based Winbuilder stable before venturing in support for Vista?"

And I actually do agree that the next goal in the "roadmap" should be to have a Release 1.0, i.e. evolve from a definite start point, rather than from a previous tentative intermediate level.

I don't want to make this appear as a rant or as a critic to all the good work done, believe me , but in the last two or three months I have lost more time trying (please note, NOT succeeding) to keep up with the continuos changes in names, builds, syntax, development models and what not than in actually experimenting with a build.

Even testing is nearly impossible, as soon as something works, the script, or the syntax, or both is changed and I am not able anymore to recreate the build properly.
Moreover, there is clear evidence, lately, of promising scripts and ideas "abandoned" and of other ones re-written twice (independently) by various .script developers.

With Vista, it seems to me clear, by the amount of bugs and insecurity reports, hacks and workarounds already around for it, the Microsoft will soon be compelled to issue several hotfixes and, most probably, a Service Pack in second or third quarter 2007.

It is very probable that, being aimed primarily to security, they will affect the privileges and UAC features workarounds we are now discussing.

So, I too find a necessity (and try my best in helping finding) a way to independently manage the Registry, but I don't see it as a priority.

Please note that the idea of going forward in steps is not really new, see here:
http://www.boot-land...?...c=639&st=25
http://www.boot-land...p?showtopic=440
http://www.boot-land...?...pic=644&hl=
everyone agrees, approving the pragmatic approach, and the next thing happening is:
http://www.boot-land...?...=652&st=166

...so after all, it is a rant ....



jaclaz

Yes, I completely agree that the current bugs and missing features should be repaired and worked as fast as possible, but the predictable OS API and restrictions will soon grow to become a very unstable factor on all our builds.

At the moment wb's script engine only needs win32 API for the registry manipulation, this is the reason why I'm worried about it and would prefer to leave this dependency the sooner as possible too..

If you directly create the hives without using the win32api how can you be sure that you have correctly reverse engineered the format of the hive as its undocumented. I could see the potential for all manner of weird bugs that you will have no chance of debugging. Given that registry formats change with new versions of the OS and even with service packs what do you actually gain. You will always be dependent on some api even if its only the one supported by the compiler runtime.

If you need ideas about what to do next how about making it compatible with pebuilder. So I could drop winbuilder into the pebuilder directory. Then run it and it automatically processes the pebuilder inf files and produces exactly the same iso that pebuilder would have created.

in the last two or three months I have lost more time trying (please note, NOT succeeding) to keep up with the continuos changes in names, builds, syntax, development models and what not than in actually experimenting with a build.

Even testing is nearly impossible, as soon as something works, the script, or the syntax, or both is changed and I am not able anymore to recreate the build properly.
Moreover, there is clear evidence, lately, of promising scripts and ideas "abandoned" and of other ones re-written twice (independently) by various .script developers.

Those are just sympthoms of a general problem we're having.
We're no longer have the forum as a place where to share and discuss ideas and scripts are released.
Today we see in the forum and on the servers, the actual development of the scripts. They are still passed off as new endversions but they aren't.

If we're honest we're no longer going from version 001 to version 002 of a script, as we claim, but from version 001 to version 001.0000001.

None, but those of us, who have the time to spend all day at the forum, are any longer able to follow what's going on.
The result is the feeling of everything being in a state of flux, the loss of overview and worst of all, the loss in interest.
Have you noticed that the number of scripts not directly related to anyone of the projects droped in the same amount that the project related scripts started changing quicker and quicker?

I also believe that the fact that we all of a sudden get more and more independend projects, grounds in the same problem.
With the new download servers, scripts get changed away right under our buns.
People feel, that the only way for them to regain some form of control over their build, is to have an own independend project. People not able to do so will most likely drop out.
The main problem with this is, that we're nowhere near the point that we could allow ourself to create branches. There's still too much work to be done on the basis.
And the loss and waste of scripting power is substantial!


Yesterday i found 3 scripts with the same name, all claiming to be version 001, written by at least two different developers, all 3 different, none without rather obvious bugs.
I think we need some sort of CVS. Don't get me wrong, i'm not talking about a real fullblown CVS. But we need some place where all scripts are stored for people to download them, fix/change them and reupload them. Everyone has to be able to get an easy overview, if there already exists a script and what is the latest version, not to mention be allowed to fix it and share it for the benefit of us all.
The various threads that exist to different scripts are not able to deliver a quick overview.

Last but not least, i have to say that i'm sorry. Cause i think it's partly my fault that things start falling apart. Before January we had one repository and just links in the different projects. This forced people to work close together, because every script had to work with every other one. There was just no room for a bunch of different createISO.scripts for example.
To my excuse i can only say that, when i recommended the system now in use, i was not aware that there exists no other structure here, able to coordinate development.

That's my rant.

If you need ideas about what to do next how about making it compatible with pebuilder. So I could drop winbuilder into the pebuilder directory. Then run it and it automatically processes the pebuilder inf files and produces exactly the same iso that pebuilder would have created.

If you want to create exactly the same ISO as pebuilder would, why don't you just use pebuilder?