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 Schrödingers_cat is alive or version > 98 {
    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 Schrödingers_cat is alive or version > 98 {
    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 Schrödingers_cat is alive or version > 98 {
    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

In article <47c232de$1@news.povray.org>, dne### [at] sanrrcom says...
> 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.
> 
Well, strictly its probably not. Though if you want to restore the 
files, deleting them means you still *can*, while something that mangles 
the registry is most likely to be "fixed" during start up, when the odds 
of things being overwritten is high, and any glitch is going to be 
permanent. I.e., by the time you realize that you need to fix 50 files 
worth of data you can't fix it.

-- 
void main () {
  If Schrödingers_cat is alive or version > 98 {
    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

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.

It's an attempt to solve vista issues. Note that I do not own a copy of
vista myself and don't want to spend ages mucking around with a 'does this
help?', 'does that help?' sort of thing.

If enough folk care about it I'll allow the import/export of INI file
settings or something (all the code for reading the INI file is still there
so as to allow option importation, exporting is also still trivial).

The fact is that the vast bulk of Windows programs store their settings in
the registry, this is clearly what Microsoft want them to do, and I really
don't have the time or energy to fight Vista [or whatever they come up with
next] issues, especially when I don't have a copy of it (and nor am I
inclined to throw away money buying what is clearly still considered by
most as a downgrade to XP).

Note that only the windows-specific settings have been moved to the
registry. All standard POV-Ray ini file operations have been retained.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> It's an attempt to solve vista issues.

  Is the problem that a program cannot write anything in its own
installation directory anymore in Vista? Having to program for Windows
I have encountered this problem.

  The "right" solution for Vista-compatible programs is to write things
in a subdirectory inside the user settings directory. If I'm not mistaken,
there's an API function which returns this directory. (I don't really know
because the library I'm using does this for me. I can check how it does it
if you want, as I have access to the source code of said library.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> It's an attempt to solve vista issues.
> 
>   Is the problem that a program cannot write anything in its own
> installation directory anymore in Vista? Having to program for Windows
> I have encountered this problem.

I honestly don't know the full cause, I've not seen the problem myself. I
do know that the commonly-suggested solution is to migrate legacy setting
files to the registry, so that's been my approach. If that solves things,
then I'm quite happy to attempt to "back up", as it were, and see where
things start to break again. (In other words, I'd rather solve it sooner
than later, which gives me the leeway to start experimenting with what
Vista will allow without having to be concerned that Vista users still
can't use the program).

>   The "right" solution for Vista-compatible programs is to write things
> in a subdirectory inside the user settings directory. If I'm not mistaken,
> there's an API function which returns this directory. (I don't really know
> because the library I'm using does this for me. I can check how it does it
> if you want, as I have access to the source code of said library.)

Thanks, no need - I already do this. The tools INI file is already expected
to be in the new location <userdir>\Application Data\POV-Ray for Windows.
Later on, the include files and other renderer files such as INI files will
move there too. (I will allow for the include files to be in both places,
but the installer will set up a local set in case the user wants to edit them).

There's some installer-related work to be done here to get things right for
new users who use POV-Ray on a system for the first time after the program
is already installed (basically a sub-installer process will need to run
and set up the required files for them in their profile automatically).

-- Chris

Post a reply to this message

Patrick Elliott wrote:
> 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 

Well that's not going to be a registry problem - it's likely a coding
error. The registry is neither good nor evil in my opinion, it's just the
way Microsoft wants things done now and I'm a little too tired to want to
argue :(

I did make the registry settings a more or less exact clone of the
pvengine.ini ones (i.e. the names etc). The net result of this is that the
code that stores and retrieves the settings can be easily made agnostic as
to where they come from/go to. With a few tweaks I could probably make it
support both (at user option). The API is the same as I abstract the calls
to the registry functions/INI functions behind a wrapper.

Note in case it's not absolutely clear to others reading this thread: the
settings being discussed are windows-specific for the UI portion of the
POVWIN program. They are not the base POV-Ray settings, which remain in INI
files as always.

-- Chris

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> 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

What do you mean, that under Vista an application can't read/write its own files
any more?
While I used the registry in the past, at the moment I'd go for an ini-file in
XML format. Allows to go tree-structured if necessary.

Steven

Post a reply to this message

stevenvh <nomail@nomail> wrote:
> What do you mean, that under Vista an application can't read/write its own files
> any more?

  Read yes, write no, at least not by default.

  There were some other problems as well, AFAIK.

-- 
                                                          - Warp

Post a reply to this message

en ce 2008/04/13 09:14 :)   ->
> Thorsten Froehlich <tho### [at] trfde> 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
> 
> What do you mean, that under Vista an application can't read/write its own files
> any more?
> While I used the registry in the past, at the moment I'd go for an ini-file in
> XML format. Allows to go tree-structured if necessary.
> 
> Steven
> 
> 
No application, exept for installers, can write an *.INI file to the programm 
files folder. This also apply to some other sencible extentions.
*.POV and *.INC, as well as graphical files are not recognized as sencible 
files, and thus you are allowed to write those.

-- 
Alain
-------------------------------------------------
Please hassle me, I thrive on stress.

Post a reply to this message

stevenvh escribió:
> While I used the registry in the past, at the moment I'd go for an ini-file in
> XML format. Allows to go tree-structured if necessary.

XML is way overrated.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:

> I did make the registry settings a more or less exact clone of the
> pvengine.ini ones (i.e. the names etc). The net result of this is that the
> code that stores and retrieves the settings can be easily made agnostic as
> to where they come from/go to. With a few tweaks I could probably make it
> support both (at user option). The API is the same as I abstract the calls
> to the registry functions/INI functions behind a wrapper.
>
> Note in case it's not absolutely clear to others reading this thread: the
> settings being discussed are windows-specific for the UI portion of the
> POVWIN program. They are not the base POV-Ray settings, which remain in INI
> files as always.
>

Is this still possible? :)  I think this might enable a user to more easily
tweak an installation.
Charles

Post a reply to this message