What are you kidding??? Please change this back as it makes ReactOS worse than before. Now your ReactOS installation will conflict with an existing Windows or ReactOS installation. This is IMHO way worse than not supporting two broken applications.
Casper
-----Original Message----- From: ros-cvs-bounces@reactos.com [mailto:ros-cvs-bounces@reactos.com] On Behalf Of Richard Campbell Sent: 30. september 2004 08:40 To: ros-cvs@reactos.com Subject: [ros-cvs] CVS Update: reactos
CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/bootdata/ Changes by: rcampbell@mok.osexperts.com 04/09/30 08:39:49
Modified files: reactos/bootdata/: hivedef.inf hivesft.inf
Log message:
- For now, hardcode the all users profile path until we
get better user management code in place
- removed the %USERPROFILE% prefix, this will go in
combination with my other fix to hopefully get things working right again.
Eh, how so?
How do you propose this be fixed? First of all we shouldn't be relying on environment variables at all, this is incompatible with the way windows does it. This doesn't just break these installers (which aren't 'broken' to begin with btw, our user profile/user management code is broken)
I WILL roll back the change until i get the kinks worked out of some new code i'm working on that fixes all of this mess.
BTW, I wasn't aware you could actually install ReactOS with an existing windows installation to begin with.
Casper Hornstrup wrote:
What are you kidding??? Please change this back as it makes ReactOS worse than before. Now your ReactOS installation will conflict with an existing Windows or ReactOS installation. This is IMHO way worse than not supporting two broken applications.
Casper
-----Original Message----- From: ros-cvs-bounces@reactos.com [mailto:ros-cvs-bounces@reactos.com] On Behalf Of Richard Campbell Sent: 30. september 2004 08:40 To: ros-cvs@reactos.com Subject: [ros-cvs] CVS Update: reactos
CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/bootdata/ Changes by: rcampbell@mok.osexperts.com 04/09/30 08:39:49
Modified files: reactos/bootdata/: hivedef.inf hivesft.inf
Log message:
- For now, hardcode the all users profile path until we
get better user management code in place
- removed the %USERPROFILE% prefix, this will go in
combination with my other fix to hopefully get things working right again.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
You need to have the ReactOS setup expand them during installation. You might also need to modify mkhive to expand them too.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Richard Campbell Sent: 30. september 2004 19:02 To: ReactOS Development List Subject: Re: [ros-dev] RE: [ros-cvs] CVS Update: reactos
Eh, how so?
How do you propose this be fixed? First of all we shouldn't be relying on environment variables at all, this is incompatible with the way windows does it. This doesn't just break these installers (which aren't 'broken' to begin with btw, our user profile/user management code is broken)
I WILL roll back the change until i get the kinks worked out of some new code i'm working on that fixes all of this mess.
BTW, I wasn't aware you could actually install ReactOS with an existing windows installation to begin with.
--- Richard Campbell eek2121@comcast.net wrote:
BTW, I wasn't aware you could actually install ReactOS with an existing windows installation to begin with.
Yes, you can. I've done it. You just need to have an installation of Windows that uses FAT/FAT32 and not NTFS.
__________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Hi!
Maybe this is a stupid idea, don't know... Wouldn't it be possible to use a special registry type which we use for our strings with environment vars, which gets expanded but otherwise looks like REG_SZ?
On Thursday 30 September 2004 18:53, Casper Hornstrup wrote:
What are you kidding??? Please change this back as it makes ReactOS worse than before. Now your ReactOS installation will conflict with an existing Windows or ReactOS installation. This is IMHO way worse than not supporting two broken applications.
Casper
-----Original Message----- From: ros-cvs-bounces@reactos.com [mailto:ros-cvs-bounces@reactos.com] On Behalf Of Richard Campbell Sent: 30. september 2004 08:40 To: ros-cvs@reactos.com Subject: [ros-cvs] CVS Update: reactos
CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/bootdata/ Changes by: rcampbell@mok.osexperts.com 04/09/30 08:39:49
Modified files: reactos/bootdata/: hivedef.inf hivesft.inf
Log message:
- For now, hardcode the all users profile path until we
get better user management code in place
- removed the %USERPROFILE% prefix, this will go in
combination with my other fix to hopefully get things working right again.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Anich Gregor wrote:
Hi!
Maybe this is a stupid idea, don't know... Wouldn't it be possible to use a special registry type which we use for our strings with environment vars, which gets expanded but otherwise looks like REG_SZ?
The registry doesn't care about the content of a value. you can assign any type to it. However for this purpose there's REG_EXPAND_SZ
Regards Thomas
Doesn't the registry expand strings of type REG_EXPAND_SZ with environment vars, and leaves REG_SZ untouched? But still it tells the program which reads the key wether it is reading REG_SZ or REG_EXPAND_SZ and some lazy coders seem to rely on reading REG_SZ while we want the keys to be expanded so we have to make them REG_EXPAND_SZ which is why the programs fail?
So if we had another type, REG_FOO, we could make our registry code expand environment vars for this type, but return REG_SZ as type to the program instead of REG_FOO, or would that not work/be a bad idea?
-blight
On Friday 01 October 2004 14:27, Thomas Weidenmueller wrote:
Anich Gregor wrote:
Hi!
Maybe this is a stupid idea, don't know... Wouldn't it be possible to use a special registry type which we use for our strings with environment vars, which gets expanded but otherwise looks like REG_SZ?
The registry doesn't care about the content of a value. you can assign any type to it. However for this purpose there's REG_EXPAND_SZ
Regards Thomas _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Anich Gregor wrote:
Doesn't the registry expand strings of type REG_EXPAND_SZ with environment vars, and leaves REG_SZ untouched?
no it doesn't. It's the callers responsibility. The only case where the registry code (advapi only) touches the data is when setting or querying a REG_SZ or REG_EXPAND_SZ with an ansi (A) function, then it converts the data from unicode to ansi or vice versa and makes it null-terminated if necessary. But that's about it.
But still it tells the program which reads the key wether it is reading REG_SZ or REG_EXPAND_SZ and some lazy coders seem to rely on reading REG_SZ while we want the keys to be expanded so we have to make them REG_EXPAND_SZ which is why the programs fail?
That's not necessarily due to laziness of some coders. The program or library is fully responsible for processing the data it received from the registry - there's nothing we can do about it except copy bad design (as in registry values).
So if we had another type, REG_FOO, we could make our registry code expand environment vars for this type, but return REG_SZ as type to the program instead of REG_FOO, or would that not work/be a bad idea?
That is a bad idea, you'd have to modify advapi to do stuff it shouldn't do. now imagine a driver or program uses the ntoskrnl/ntdll versions directly...
Regards, Thomas
On Friday 01 October 2004 15:32, Thomas Weidenmueller wrote:
Anich Gregor wrote:
Doesn't the registry expand strings of type REG_EXPAND_SZ with environment vars, and leaves REG_SZ untouched?
no it doesn't. It's the callers responsibility. The only case where the registry code (advapi only) touches the data is when setting or querying a REG_SZ or REG_EXPAND_SZ with an ansi (A) function, then it converts the data from unicode to ansi or vice versa and makes it null-terminated if necessary. But that's about it.
But still it tells the program which reads the key wether it is reading REG_SZ or REG_EXPAND_SZ and some lazy coders seem to rely on reading REG_SZ while we want the keys to be expanded so we have to make them REG_EXPAND_SZ which is why the programs fail?
That's not necessarily due to laziness of some coders. The program or library is fully responsible for processing the data it received from the registry - there's nothing we can do about it except copy bad design (as in registry values).
So if we had another type, REG_FOO, we could make our registry code expand environment vars for this type, but return REG_SZ as type to the program instead of REG_FOO, or would that not work/be a bad idea?
That is a bad idea, you'd have to modify advapi to do stuff it shouldn't do. now imagine a driver or program uses the ntoskrnl/ntdll versions directly...
Regards, Thomas
Oh, didn't know that... should have checked that before i wrote such stupid suggestions ;) Thanks for clearing this up for me.
-
Anich Gregor -
Casper Hornstrup -
Richard Campbell -
ShadowFlare -
Thomas Weidenmueller