Hello all,

I'm still using OE6 to read/write newsgroup messages, and have written a
small program which retrieves the message count for each subscribed
newsgroup, so I can easily see if new messages are available for them.

The thing is, at some point I need to provide a username and password. The
OE6 account already has them, but can't seem to be able to retrieve them for
my "new messages" checking program.

Any idea where-and-how I can retrieve them ?

I've already taken a peek at the 'CredRead' and family functions
(advapi32.ddl), but those return nothing. Presumably OE6 uses another
method.

Regards,
Rudy Wieser

On Mon, 5 Feb 2024 11:16:21 +0100, "R.Wieser" <address@is.invalid>
wrote:

>Hello all,
>
>I'm still using OE6 to read/write newsgroup messages, and have written a
>small program which retrieves the message count for each subscribed
>newsgroup, so I can easily see if new messages are available for them.
>
>The thing is, at some point I need to provide a username and password. The
>OE6 account already has them, but can't seem to be able to retrieve them for
>my "new messages" checking program.
>
>Any idea where-and-how I can retrieve them ?
>
>I've already taken a peek at the 'CredRead' and family functions
>(advapi32.ddl), but those return nothing. Presumably OE6 uses another
>method.

Nirsoft probably has an utility to retrieve them. Filemon or
Regmon it and see where it searches.
Don't have OE installed, so can't test it myself.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012
Google Fuchsia - 2021

Shadow,

>>The thing is, at some point I need to provide a username and password.
>>The OE6 account already has them, but can't seem to be able to retrieve
>>them for my "new messages" checking program.
>>
>>Any idea where-and-how I can retrieve them ?
....
> Nirsoft probably has an utility to retrieve them. Filemon or
> Regmon it and see where it searches.

Ah, I see that I should have been a bit clearer.

I have both the needed username and password, and currently have them
hardcoded in my "new messages" program. But that means that when I
add/change an account I need to edit the program by hand. And as I'm lazy
(as all programmers are :-) ) I would like to skip that step, and have the
program retrieve that information by itself.

After posting my question I did some "googeling", and found that the account
data gets stored in the registry here :

HKEY_CURRENT_USER\Software\Microsoft\Internet Account Manager\Accounts

It holds all kinds of stuff, but the accounts password is not among them.
Although there is a "NNTP Password2" key present, its data doesn't live up
to it.

Regards,
Rudy Wieser

On Mon, 5 Feb 2024 13:03:35 +0100, R.Wieser wrote:
>
> Although there is a "NNTP Password2" key present, its data doesn't live up
> to it.

What do you mean? It's there in plain sight. Unencrypted and unobfuscated.

JJ,

>> Although there is a "NNTP Password2" key present, its data doesn't live
>> up
>> to it.
>
> What do you mean? It's there in plain sight. Unencrypted and unobfuscated.

When I compare the keys data with the actual password (the first thing I
did, duh) they do not match. At all.

The keys data starts with 0x01,0x02. My password as all ASCII.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> I'm still using OE6 to read/write newsgroup messages, and have written
> a small program which retrieves the message count for each subscribed
> newsgroup, so I can easily see if new messages are available for
> them.
>
> The thing is, at some point I need to provide a username and
> password. The OE6 account already has them, but can't seem to be
> able to retrieve them for my "new messages" checking program.
>
> Any idea where-and-how I can retrieve them ?
>
> I've already taken a peek at the 'CredRead' and family functions
> (advapi32.ddl), but those return nothing. Presumably OE6 uses
> another method.

https://www.nucleustechnologies.com/blog/know-your-outlook-password-location/

Not even those with admin privileges for their Windows account can see
the hidden crypto hive in the registry. regedit.exe doesn't show
everything.

As I recall, Pstore got deprecated (replaced with Data Protection API;
see https://en.wikipedia.org/wiki/Data_Protection_API), and made
read-only in Windows Vista, so programs could find their old login
credentials in Pstore, but you couldn't change them. That meant some
programs still using Pstore couldn't store their credentials as of
Windows Vista.

https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_Vista
Protected Storage (PStore) has been deprecated and therefore made
read-only in Windows Vista. Microsoft recommends using DPAPI to add
new PStore data items or manage existing ones.[35] However existing
applications such as Outlook 2002 which used PStore are unable to save
passwords as a result. Any application that tries to create new PStore
data items will fail."

You're still back on Windows XP, so Pstore (pstore.exe) is still used
there. I've never had to delve into Pstore, and it's way too late for
me to start now. OE would have the hints needed to extract its
credentials from Pstore along with code to provide the hints of what
items to extract. You can start learning about Pstore here:

https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore
(Considering this is only for Windows XP and Server 2003, I'm surprised
Microsoft hasn't taken down this web page since they remove lots of docs
for old Windows versions when they get discontinued.)

I've not looked into getting a list of Pstore providers used to access
protected data in Pstore. The article above has a sub-article on how to
code to get a list of those. Pstore corruption is one of the causes for
OE to be very slow; see:

https://support.microsoft.com/en-au/topic/olexp-outlook-express-performance-is-slow-a5548db3-b7e0-689a-475b-91c535dbefc6

However, the step suggesting to delete the ProtectedStorage registry key
means losing all credentials stored there for any program using Pstore.
I'm surprised even back in Windows XP that the key wasn't protected with
access privileges that you had to change, like take Ownership, apply,
and then change/add users with full control privileges. Maybe the
registry wasn't so well protected back in Windows XP from user mistakes.
I'm not sure if any non-Microsoft programs (and any other than Outlook
98 and OE) used Pstore. DPAPI was available back in Windows 2000, so it
overlap and superseded Pstore.

OE supported plug-ins; for examples, see:

https://www.mapilab.com/outlook_express/

At one time for a short time, Microsoft provided documentation on OE
plug-ins, but they yanked it, because they considered it too flaky.

https://en.wikipedia.org/wiki/Outlook_Express#Extensibility

I don't know if anyone grabbed the doc, and I don't know the URL to see
if web.archive.org has an old page with the doc. Possibly a script
could ask a plug-in to ask OE to get the login credentials to put in a
temp file that a script could read, and then destroy the file (not just
delete, but erase its sectors). Looks some devs came up with their own
API to write add-ins for OE, like:

https://www.add-in-express.com/programming-outlook-express/

Rather than delve into all that trying to gain expertise in something
that is dead, why not hard code the login credentials into your script?
Yeah, you end up exposing the login credentials in what is likely text
to define a script, so you might need to figure out how to do something
of reduced Pstore functionality by encrypting the login credentials into
a file, and somehow obfuscating your decrypt key(s).

While Nirsoft has some tools to get at protected data (see
https://www.nirsoft.net/password_recovery_tools.html), some only work
wit DPAPI. His Protected Storage PassView tool (pspv.exe) looks for
passwords stored in Pstore. I have some of his tools, but didn't keep
this one since Pstore died with Windows XP/Server 2003.

Vanguard,

Thank you for the links and explanation to them.

Further googeling (following some hunches) resulted in finding the registry
key to where the OutLook Express accounts is stored. Although the name is
there the password isn't stored there.

> Not even those with admin privileges for their Windows account
> can see the hidden crypto hive in the registry.

I'm going to assume that the crypto hive is protected by the OS, meaning
that low-level access to the registry thru NTDLL won't help either.

> replaced with Data Protection API;
> see https://en.wikipedia.org/wiki/Data_Protection_API

Alas, that page talks a lot, but doesn't tell me anything. After having
read it I do not even know which (XPsp3) DLLs are involved :-|

The problem with all I find is that I've still got zero in regard to
information (sample code) to what to use and how to apply it.

> https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore

The problem with MS is that, contradicting the domans name, that site works
well enough when you know what to do but need to check how to call the
functions, but not all that much when you are trying to figure out what you
need do to arrive at a goal. :-(

I could try and and see what all those enums return, but I would be
stumbling in the dark. Probably will try anyway though, its the best thing
I currently got (not that hard when you got nothing :-) ).

I don't think I will mess up the store in any way, as all I need is read
access.

As for the possibility to write some plug-ins for OE ? I am not trying to
extend OE - how would I access the results from another program ?

> why not hard code the login credentials into your script? Yeah, you
> end up exposing the login credentials

Thats currently what I'm doing, and not all worried about exposing them.

The thing is the above solution means that I have to manage the data
(username, password) at (several) different places, and would like to bring
that back to just a single one.

Having to deal with encryption (thru pstore or other) is how it was
implemented in Outlook Express, and I have no other choice(?) than to do the
same.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> Vanguard,
>
> Thank you for the links and explanation to them.
>
> Further googeling (following some hunches) resulted in finding the registry
> key to where the OutLook Express accounts is stored. Although the name is
> there the password isn't stored there.
>
>> Not even those with admin privileges for their Windows account
>> can see the hidden crypto hive in the registry.
>
> I'm going to assume that the crypto hive is protected by the OS, meaning
> that low-level access to the registry thru NTDLL won't help either.
>
>> replaced with Data Protection API;
>> see https://en.wikipedia.org/wiki/Data_Protection_API
>
> Alas, that page talks a lot, but doesn't tell me anything. After having
> read it I do not even know which (XPsp3) DLLs are involved :-|
>
> The problem with all I find is that I've still got zero in regard to
> information (sample code) to what to use and how to apply it.
>
>> https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore
>
> The problem with MS is that, contradicting the domans name, that site works
> well enough when you know what to do but need to check how to call the
> functions, but not all that much when you are trying to figure out what you
> need do to arrive at a goal. :-(
>
> I could try and and see what all those enums return, but I would be
> stumbling in the dark. Probably will try anyway though, its the best thing
> I currently got (not that hard when you got nothing :-) ).
>
> I don't think I will mess up the store in any way, as all I need is read
> access.
>
> As for the possibility to write some plug-ins for OE ? I am not trying to
> extend OE - how would I access the results from another program ?
>
>> why not hard code the login credentials into your script? Yeah, you
>> end up exposing the login credentials
>
> Thats currently what I'm doing, and not all worried about exposing them.
>
> The thing is the above solution means that I have to manage the data
> (username, password) at (several) different places, and would like to bring
> that back to just a single one.
>
> Having to deal with encryption (thru pstore or other) is how it was
> implemented in Outlook Express, and I have no other choice(?) than to do the
> same.
>
> Regards,
> Rudy Wieser

If you find the documentation on writing OE plug-ins, perhaps there was
a function to ask OE for login credentials. OE gets the data from its
Pstore data, and returns to the plug-in. Seem far fetched that plug-ins
would have access to that info since that seems a security hole.

Without the hints in OE itself on how it uses Pstore, and what key it
used to seed the encryption, not sure you'll get it outside of OE.

Vanguard,

> If you find the documentation on writing OE plug-ins, perhaps there
> was a function to ask OE for login credentials. OE gets the data
> from its Pstore data, and returns to the plug-in.

And than I would need to find a way to have another program communicate with
such a plug-in, a way that is not given to exist.

> Seem far fetched that plug-ins would have access to that info since
> that seems a security hole.

And then there is that ofcourse.

> Without the hints in OE itself on how it uses Pstore, and what
> key it used to seed the encryption, not sure you'll get it
> outside of OE.

:-) Thats what this question is all about : if someone knows how to
retrieve/extract the sought for data from OE6, sparing me (possible
fruitless) hours-upon-hours scouring possible leads in the hope to find such
a hint.

I already checked what DLLs and functions thereof it exports, but none are
geared towards encryption.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> Thats what this question is all about : if someone knows how to
> retrieve/extract the sought for data from OE6, sparing me (possible
> fruitless) hours-upon-hours scouring possible leads in the hope to find such
> a hint.

Seems way too much works for just one instance of OE, so my guess is you
use your script on many instances of OE.

If all you need is the password(s) from OE from one instance, why not
use Nirsoft's Protected Storage Passview (pspv) tool already mentioned
(https://www.nirsoft.net/utils/pspv.html)? It has command-line
arguments to save the passwords into a file. Your script could call it
via command-line, and then your script would parse the output file to
find the OE passwords. I don't what its output file looks like
regarding syntax to know if there are separate sections for each type of
app that uses Pstore, or if all passwords in Pstore get dumped out en
masse without any indicator of the app to which they belong. Since I'm
on Windows 10, there is no Pstore there to dump anything out of it.
You'd have to see what pspv showed you.

From the GUI version of pspv, there is a column called "Resource Type",
and the example shows "Outlook Express" as one of those. So, perhaps
the command-line arg to output to a file will also show Resource Types.
My guess is the output will be records (lines) with fields, and one of
the fields would be the resource type.

I'd watch pspv to see if it was issuring pstore.exe commands. If so,
you could see the syntax of those commands to use in your script. Else,
you could contact Nir Sofer (nirsofer@yahoo.com) to see if he was
conducive to showing you his source code for pspv.

Note that Pstore is only used if the user selects to save the password
when they access an account using OE. If the user elects to manually
enter it each time, the password does not get saved in Pstore.

Vanguard,

>> Thats what this question is all about : if someone knows how to
>> retrieve/extract the sought for data from OE6, sparing me (possible
>> fruitless) hours-upon-hours scouring possible leads in the hope to find
>> such
>> a hint.
>
> Seems way too much works for just one instance of OE,

Indeed*, hence my question. An example of what needs to be done and how
would fix.

* though I'm a hobby programmer, and just/might/ go thru all that trouble
just to see if I can actually do it. You know, like some people like to put
a 10.000 piece puzzle together.

> so my guess is you use your script on many instances of OE.

Nope. Just one.

And what "your script" are you talking about ?

> why not use Nirsoft's Protected Storage Passview (pspv) tool already
> mentioned (https://www.nirsoft.net/utils/pspv.html)?

Reasons:

1) Knowledge. I like to know how its done.

2) Interoperability. it won't work well together with my program (which is
GUI based)

3) Having a hobby. I dislike using other peoples (small) programs when I can
write them myself (also see #1).

Regards,
Rudy Wieser

Vanguard,

>> https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore
>
> The problem with MS is that, contradicting the domans name, that site
> works well enough when you know what to do but need to check how to call
> the functions, but not all that much when you are trying to figure out
> what you need do to arrive at a goal. :-(

To make a point :

I just enumerated the "PStoreProviders" using IEnumPStoreProviders::Next",
but am now looking at ... I have no idea, and MS webpage about it* doesn't
explain it either.

*
https://learn.microsoft.com/en-us/windows/win32/devnotes/ienumpstoreproviders-next

Worse, the "[out] LPWSTR *rgelt" argument is described as :

"A pointer to a string in which to return the provider type name."

As its an "LPWSTR" I'm /assuming/ it returns a pointer to a string manages
it itself. But the phrasing "A pointer to a string in which to return"
seems to indicate I have to provide space for such a string myself.

To check I just provided a pointer to some space and compared that with what
got returned, and they differ. Which seems to indicate my first hunch was
correct, and the "A pointer to a string in which to return" *should* have
been written as "in which a pointer to a string is returned".

.... which still is wrong, as it looks like some /value/ is returned (the
first four bytes are 0x1C 0x00 0x00 0x00. Not at all looking like a string,
wide or not).

Ofcourse, with the MS webpages giving zero indication to what that code
might mean.

Second, very similar issue : I thought I could take a look at what
"IEnumPStoreItems::next" would return (and get lucky and get the password).
For that I need to call the "IPStore"s "EnumItems" method. But although MS
provided a list of methods*, there is no indication of if that list is in
VTable order. As such I can't even create the needed VTable.

* https://learn.microsoft.com/en-us/windows/win32/devnotes/ipstore

And than there is the problem that that "EnumItems" method needs "pItemType"
and "pItemSubtype" arguments, which are not described anywhere either. And
without them I don't stand a chance of even getting the enumeration started.
:-(

IOW, even when I go to the horses mouth to get my information I do not get
everything thats needed (and have to scour the internet to hopefully find
it).

And by the way : I've not seen the msimn.exe or msoe.dll import the
pstore.dll anywhere.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> And what "your script" are you talking about ?

Reread your first message. Says you're using a program. Well that
could be compiled C, or some other language, a script, or whatever that
executes code whether compiled or intrepreted. Can your program call
external programs, like to run pspv.exe with command-line args?

>> why not use Nirsoft's Protected Storage Passview (pspv) tool already
>> mentioned (https://www.nirsoft.net/utils/pspv.html)?
>
> 3) Having a hobby. I dislike using other peoples (small) programs when
> I can write them myself (also see #1).

Then I suggest writing to Nir Sofer to ask if he will show you his code;
else, you're into learning Pstore programming. I only know about Pstore
because of problems with OE back in XP many years ago. I never go into
delving into Pstore nor using any code to extract data from it.
Microsoft's articles describe what it is, and describes some functions
(already gave the URL to the MS article, but really isn't where you go
for programming guidance unless you really want to learn from the ground
up by trial and error. Pstore was a Windows XP-only thing, became read
only in Windows Vista, and dropped in Windows 7, so not sure if you'll
find many hits in online search on Pstore programming.

Vanguard,

>> And what "your script" are you talking about ?
>
> Reread your first message. Says you're using a program.

Indeed, "a program". Not "a script".

> Well that could be compiled C, or some other language, a script,
> or whatever that executes code whether compiled or intrepreted.

Again, indeed.

But somehow you decided that my program must have been of the subtype
"script". How come ?

> Can your program call external programs, like to run pspv.exe
> with command-line args?

Nope, sorry.

> Then I suggest writing to Nir Sofer to ask if he will show you
> his code;

:-) If he wanted to share it I would have already found his sourcecode.
Outlook Express is over two decades old.

Hmmm... that pspv.exe program is just 52 KByte. Perhaps I should pull it
thru the disassembler and see what I can glean from it ..

> else, you're into learning Pstore programming.

Yeah, about that : I just spend some time trying to "google" that IPStore
objects vtable. I can find some partial Linux info, but nothing about the
one in Windows. And without that VTable I don't know how to call a named
method. And without being able to do that ...

> Pstore was a Windows XP-only thing, became read only in Windows
> Vista, and dropped in Windows 7

Yep. Every webpage about its functions, methods, constants and types has
that info directly below its title. Almost as if they wanted to make sure
you could not miss it. :-)

I would have thought that the information itself would, if not on an MS
website, still be floating around somewhere. It looks like I was wrong in
that.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> Vanguard,
>
>>> https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore
>>
>> The problem with MS is that, contradicting the domans name, that site
>> works well enough when you know what to do but need to check how to call
>> the functions, but not all that much when you are trying to figure out
>> what you need do to arrive at a goal. :-(
>
> To make a point :
>
> I just enumerated the "PStoreProviders" using IEnumPStoreProviders::Next",
> but am now looking at ... I have no idea, and MS webpage about it* doesn't
> explain it either.
>
> *
> https://learn.microsoft.com/en-us/windows/win32/devnotes/ienumpstoreproviders-next
>
> Worse, the "[out] LPWSTR *rgelt" argument is described as :
>
> "A pointer to a string in which to return the provider type name."
>
> As its an "LPWSTR" I'm /assuming/ it returns a pointer to a string manages
> it itself. But the phrasing "A pointer to a string in which to return"
> seems to indicate I have to provide space for such a string myself.
>
> To check I just provided a pointer to some space and compared that with what
> got returned, and they differ. Which seems to indicate my first hunch was
> correct, and the "A pointer to a string in which to return" *should* have
> been written as "in which a pointer to a string is returned".
>
> ... which still is wrong, as it looks like some /value/ is returned (the
> first four bytes are 0x1C 0x00 0x00 0x00. Not at all looking like a string,
> wide or not).
>
> Ofcourse, with the MS webpages giving zero indication to what that code
> might mean.
>
> Second, very similar issue : I thought I could take a look at what
> "IEnumPStoreItems::next" would return (and get lucky and get the password).
> For that I need to call the "IPStore"s "EnumItems" method. But although MS
> provided a list of methods*, there is no indication of if that list is in
> VTable order. As such I can't even create the needed VTable.
>
> * https://learn.microsoft.com/en-us/windows/win32/devnotes/ipstore
>
> And than there is the problem that that "EnumItems" method needs "pItemType"
> and "pItemSubtype" arguments, which are not described anywhere either. And
> without them I don't stand a chance of even getting the enumeration started.
> :-(
>
> IOW, even when I go to the horses mouth to get my information I do not get
> everything thats needed (and have to scour the internet to hopefully find
> it).
>
> And by the way : I've not seen the msimn.exe or msoe.dll import the
> pstore.dll anywhere.

Before going off on a red herring, have you used Nirsoft PSPV to check
if there is anything in Pstore (for the Windows account under which you
are logged into since Pstore is a per-user crypto cache)? Along with
its Resource Type column that should show 1, or more, entries named
"Outlook Express", it should also show non-blank username and password
credentials. If PSPV doesn't list any Pstore entries, somehow OE is
saving the login credentials elsewhere. Everything I read, and for
resolution of some problems with account logins in OE, Pstore was used
by OE to store login credentials. If PSPV doesn't show any login creds
for OE, there's nothing there to pull out.

Vanguard,

> Before going off on a red herring, have you used Nirsoft PSPV
> to check if there is anything in Pstore (...) ?

You have a point, and I did not do so until just now. There are multiple
"outlook express" entries. And yes, one with the (accountname, username
and) password I am looking for.

Though I already found out that pstorec.dll is used (and the pstore object
created), it didn't tell me if something has been stored in it.

> (for the Windows account under which you are logged into since
> Pstore is a per-user crypto cache)?

:-) It would not be much of a /protected/ store if the different users could
just take a peek at each others (username and) passwords. IOW, I already
assumed it would be linked to the users account.

I just realized : as the pspv program is GUI (and not console) based, how
did you think you could retrieve (get it to return) the password ?

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> I just realized : as the pspv program is GUI (and not console) based, how
> did you think you could retrieve (get it to return) the password ?

It has command-line args to dump to file. That's why I wondered if your
program could call an external program to create the output file, and
then your program would parse the output file to extract the OE creds.

https://www.nirsoft.net/utils/pspv.html
Scroll down to the "Command-line options" section.

Vanguard (and others),

>> Thats what this question is all about : if someone knows how to
>> retrieve/extract the sought for data from OE6, sparing me (possible
>> fruitless) hours-upon-hours scouring possible leads in the hope to find
>> such
>> a hint.
>
> Seems way too much works for just one instance of OE,

I got lucky, and found the order of methods of the iPStore vtable in an
incomplete PowerBasic snippet. That helped quite a bit. Combined with a few
other incomplete snippets I was able to figure out what needed to be done to
get a list of OE (mail and news) passwords (and some other stuff).

Looking /back/ its not at all complex. When I was looking /forward/ however
....

I stil have to go thru the OE accounts data in the registry to retrieve the
data needed to select the correct password to extract, but that should not
be a problem.

Or, with /way/ less words : "mischief managed". :-)

Regards,
Rudy Wieser

Vanguard,

>> I just realized : as the pspv program is GUI (and not console) based, how
>> did you think you could retrieve (get it to return) the password ?
>
> It has command-line args to dump to file.
....
> https://www.nirsoft.net/utils/pspv.html
> Scroll down to the "Command-line options" section.

Thanks. I did not notice those before.

> That's why I wondered if your program could call an external program
> to create the output file, and then your program would parse the output
> file to extract the OE creds.

My current program reads the username and password from an INI file. I
could imagine a (VB)script running the psvp program, reading the output and
stuffing the read items into the INI file, and than start my program.

A bit of a downside : the psvp program does not seem to mark email and
newsgroups differently (even though the registy "Accounts" entries make it
rather clear which type they are - pop3/smtp vs nntp). The generated INI
would be a bit murky ...

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> A bit of a downside : the psvp program does not seem to mark email and
> newsgroups differently (even though the registy "Accounts" entries
> make it rather clear which type they are - pop3/smtp vs nntp). The
> generated INI would be a bit murky ...

Other than the Resource Type that identifies the credentials belong to
Outlook Express, doesn't the Resource Name identify the account? I'm
going by the Nirsoft PSPV sample shown at its web site. The column
headers shown in PSPV are:

Resource Name
Resource Type
User Name/Value
Password

The Resource Name looks to be the account name. It won't help if you
give e-mail and newsgroups accounts the same name. However, I don't see
the Resource Name, or another field shown, that identifies the type of
account, just its name.

If the registry entries identify type of account, and also give the
account name, you could pair up the registry account name for NNTP
accounts with the PSPV Resource Names. You'd have a table of registry
account names of NNTP type, pair the account name to the PSPV Resource
Name, and then get the password from the matching PSPV entry.

Pstore was just to secrete the passwords (and usernames), and really
that's all it did. Supposedly the program using Pstore would know which
Resource Name to use for which account, but maybe it got that from the
accounts list in the registry.

Vanguard,

>> A bit of a downside : the psvp program does not seem to mark email
>> andnewsgroups differently (even though the registy "Accounts"
>> entries make it rather clear which type they are - pop3/smtp vs
>> nntp). The generated INI would be a bit murky ...

> It won't help if you give e-mail and newsgroups accounts the same name.

That.

> If the registry entries identify type of account, and also give the
> account name, you could pair up the registry account name for NNTP
> accounts with the PSPV Resource Names.

Oh man, thats hacks and more hacks ...

Yes, it could be done that way. No, there is not a single hair on my head
which would think of creating such a "solution". Sorry.

Luckily I have some finished pstore code, as well as most of the registry
account-retrieval code. A bit more work tomorrow and I will have a nice
function which I can feed a newsgroup-servers name and get its username and
password back.

Regards,
Rudy Wieser