In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
file is now integrated into the Windows registry. I'm curious as to why 
this was done? The editor I can understand due to it's tight integration 
with the Windows GUI manager. But why the pvengine.ini? Thx.

Post a reply to this message

In article <47c08fb8$1@news.povray.org>, jho### [at] northrimnet says...
> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
> file is now integrated into the Windows registry. I'm curious as to why
 
> this was done? The editor I can understand due to it's tight integration
 
> with the Windows GUI manager. But why the pvengine.ini? Thx.
> 
Gah.. Good question. Most people in *any* sort of open source and/or 
user modifiable code are moving away from that. There is even discussion 
on the client I use for muds on when/if/how it should move its setting 
out of there. The registry creates more problems than it solves usually, 
and in the case of the client I mentioned, there is some bizarre bug 
which causes the client to forget what the window sizes are, if you have 
more than one open at a time. And that is not even mentioning stuff like 
being able to export settings and import them to a different machine, 
use programs across multiple machines, off of flash drives, and so on, 
especially if you have restrictions on certain types of software 
installs, and so on. It is, quite simply, a major pain in the ass that I 
wish MS hadn't come up with, and completely absurd as a solution to much 
of anything (especially now that XP and Vista "both" use user specific 
folders for documents now, which means those kinds of settings could be 
stored just like on *nix systems). In other words, the stupid reason 
they came up with it in the first place, isn't necessary any more.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> In article <47c08fb8$1@news.povray.org>, jho### [at] northrimnet says...
>> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
>> file is now integrated into the Windows registry. I'm curious as to why 
>> this was done? The editor I can understand due to it's tight integration 
>> with the Windows GUI manager. But why the pvengine.ini? Thx.
>>
> Gah.. Good question. Most people in *any* sort of open source and/or 
> user modifiable code are moving away from that. There is even discussion 
> on the client I use for muds on when/if/how it should move its setting 
> out of there. The registry creates more problems than it solves usually, 
> and in the case of the client I mentioned, there is some bizarre bug 
> which causes the client to forget what the window sizes are, if you have 
> more than one open at a time. And that is not even mentioning stuff like 
> being able to export settings and import them to a different machine, 
> use programs across multiple machines, off of flash drives, and so on, 
> especially if you have restrictions on certain types of software 
> installs, and so on. It is, quite simply, a major pain in the ass that I 
> wish MS hadn't come up with, and completely absurd as a solution to much 
> of anything (especially now that XP and Vista "both" use user specific 
> folders for documents now, which means those kinds of settings could be 
> stored just like on *nix systems). In other words, the stupid reason 
> they came up with it in the first place, isn't necessary any more.
> 
I agree with your most of your points. I've always been an advocate of 
keeping as much out of the registry as possible. Contrary to popular 
belief, many programs do not remove their registry entries completely, 
leading to bloated registries and other problems. I've done a lot of 
"registry surgery" over the years...
Another aspect is integration with other programs, such as modelers. I 
would think it more convenient to read the pvengine.ini file and parse 
it than to root around in the registry checking keys...
I'd much rather see it retain it's old form, easy to edit and modify.

Post a reply to this message

Jeff Houck wrote:
> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
> file is now integrated into the Windows registry. I'm curious as to why 
> this was done? The editor I can understand due to it's tight integration 
> with the Windows GUI manager. But why the pvengine.ini? Thx.

Vista compatibility :-(

	Thorsten, POV-Team

Post a reply to this message

Patrick Elliott wrote:
> In article <47c08fb8$1@news.povray.org>, jho### [at] northrimnet says...
>> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
>> file is now integrated into the Windows registry. I'm curious as to why 
>> this was done? The editor I can understand due to it's tight integration 
>> with the Windows GUI manager. But why the pvengine.ini? Thx.
>>
> Gah.. Good question. Most people in *any* sort of open source and/or 
> user modifiable code are moving away from that.

You have no real clue what you are talking about, do you?

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Jeff Houck wrote:
>> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini 
>> file is now integrated into the Windows registry. I'm curious as to 
>> why this was done? The editor I can understand due to it's tight 
>> integration with the Windows GUI manager. But why the pvengine.ini? Thx.
> 
> Vista compatibility :-(
> 
>     Thorsten, POV-Team

Ah, I see... Then I'm assuming this will alleviate some of the issues 
with the "security model" now implemented in Vista... especially as 
applied to User Account Control. Symantec has a very good paper on the 
subject and goes into more detail concerning DEP and ASLR too.
Thx Thorsten for the info...

Post a reply to this message

In article <47c11106$1@news.povray.org>, tho### [at] trfde says...
> Patrick Elliott wrote:
> > In article <47c08fb8$1@news.povray.org>, jho### [at] northrimnet says...
> >> In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini
 
> >> file is now integrated into the Windows registry. I'm curious as to wh
y 
> >> this was done? The editor I can understand due to it's tight integrati
on 
> >> with the Windows GUI manager. But why the pvengine.ini? Thx.
> >>
> > Gah.. Good question. Most people in *any* sort of open source and/or 
> > user modifiable code are moving away from that.
> 
> You have no real clue what you are talking about, do you?
> 
> 	Thorsten
Ok, maybe I should say "some", not most. But seriously, the registry is 
a major pain in the @$$#$#@$ ass. Its not secure when you need it to be, 
too secure on new Windows platforms, when you don't want it to be, its 
more easily corrupted than small stand alone files, and damn harder to 
simply fix by recreating the part that broke (since it can break the 
registry so bad you can't fix any of it), etc. It imho, has been, and 
will always be, more trouble than its worth. A fair number of people are 
starting to recognize the same thing and abandon it, in favor of going 
back to something more like the old .ini method. So, I exaggerated, sue 
me.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <47c110cd$1@news.povray.org>, tho### [at] trfde says...
> Jeff Houck wrote:
> > In the latest Beta 3.7.beta25 change log, it mentions the pvengine.ini
 
> > file is now integrated into the Windows registry. I'm curious as to why
 
> > this was done? The editor I can understand due to it's tight integratio
n 
> > with the Windows GUI manager. But why the pvengine.ini? Thx.
> 
> Vista compatibility :-(
> 
> 	Thorsten, POV-Team
Umm. All one needs if the local the users documents folder is in, then 
write your user files there. This is how most programs do it under *nix, 
storing settings for the "user" in the "user's" document/program area. 
Why bow to MS' broken system, when all its going to do is make it a 
nightmare later on, when you find some case where you need access to 
that stuff, but its not there. Heck, for that matter, the OS is doing 
that anyway. User specific keys are now *stored* in a registry file 
"in" the users own document path, rather than in the old monolithic mess 
they had prior. But, it still means you are putting all your eggs in one 
basket and can break the damn thing too easy making it near impossible 
to fix dozens of such keys, especially if someone manages to glitch the 
file, or even delete it. Recreating "one" file specific to the program 
yours using, is manageable, not recreating one huge file that used to 
contain stuff for 50 some odd programs. Its just nuts imho.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> Why bow to MS' broken system, 

MS doesn't want you to bow to MS's broken system. That's why there's 
both ...\local data\application settings and ...\application settings, 
depending on whether it's machine-local or not.

> Recreating "one" file specific to the program
> yours using, is manageable, not recreating one huge file that used to 
> contain stuff for 50 some odd programs. 

Me, I've never seen why this is more of a problem than (say) 
accidentally deleting /etc. But still, moving configuration into the 
registry at *this* point is still a generation behind.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New nous apporta ses lumieres en ce 2008/02/24 22:15:
> Patrick Elliott wrote:
>> Why bow to MS' broken system, 
> 
> MS doesn't want you to bow to MS's broken system. That's why there's 
> both ...\local data\application settings and ...\application settings, 
> depending on whether it's machine-local or not.
> 
>> Recreating "one" file specific to the program
>> yours using, is manageable, not recreating one huge file that used to 
>> contain stuff for 50 some odd programs. 
> 
> Me, I've never seen why this is more of a problem than (say) 
> accidentally deleting /etc. But still, moving configuration into the 
> registry at *this* point is still a generation behind.
> 
A viable alternative would be to still use the INI files, but place them in the 
user's folder, or the "all users" folder.
The first way, the settings will be user specific on a multi user machine.
The second way is more like the current 3.6 aproach, the same settings affect 
all users equaly on a given machine.
The advantage, you only have to copy your current ini files to the new location.

-- 
Alain
-------------------------------------------------
History, in general, only informs us of what bad government is.
Thomas Jefferson

Post a reply to this message