RE: [ros-cvs] CVS Update: reactos

[Casper Hornstrup]

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(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Richard Campbell
>  Sent: 30. september 2004 08:40
>  To: ros-cvs(a)reactos.com
>  Subject: [ros-cvs] CVS Update: reactos
>  
>  CVSROOT:	/CVS/ReactOS
>  Module name:	reactos
>  Repository:	reactos/bootdata/
>  Changes by:	rcampbell(a)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.

[Richard Campbell]

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(a)reactos.com 
> > [mailto:[e-mail]] On Behalf Of Richard Campbell
> > Sent: 30. september 2004 08:40
> > To: ros-cvs(a)reactos.com
> > Subject: [ros-cvs] CVS Update: reactos
> >
> > CVSROOT:	/CVS/ReactOS
> > Module name:	reactos
> > Repository:	reactos/bootdata/
> > Changes by:	rcampbell(a)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(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
>   
>

[Casper Hornstrup]

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(a)reactos.com 
>  [mailto:[e-mail]] 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.

[ShadowFlare]

--- Richard Campbell <eek2121(a)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

[Anich Gregor]

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(a)reactos.com
> >  [mailto:[e-mail]] On Behalf Of Richard Campbell
> >  Sent: 30. september 2004 08:40
> >  To: ros-cvs(a)reactos.com
> >  Subject: [ros-cvs] CVS Update: reactos
> >
> >  CVSROOT:	/CVS/ReactOS
> >  Module name:	reactos
> >  Repository:	reactos/bootdata/
> >  Changes by:	rcampbell(a)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(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev

[Thomas Weidenmueller]

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

[Anich Gregor]

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(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev

[Thomas Weidenmueller]

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

[Anich Gregor]

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.