Announcement

**Scott Turchin** · 2 Jul 2001, 10:03 PM

I had read where MS wants people to go back to INI files because the registry is getting too bloated...

But, do like I do, there are a few you have ot worry about:

Code:

local osinfo as OSVERSIONINFO

osinfo.dwOsVersionInfoSize = SizeOf(osinfo)
GetVersionEx osinfo

If osinfo.dwPlatformId = %VER_PLATFORM_WIN32_NT Then
   'NT 4.0 and Windows2000
   g_sRegKey = "Software\Microsoft\Windows NT\CurrentVersion"
Else
   g_sRegKey = "Software\Microsoft\Windows\CurrentVersion"
End If

That's a big one there
'
'
Another way I do it:

Function GetRegistrationInfo(wRegUser As String,wRegCompany As String) Export As Long
Local RegKey As String
osinfo.dwOsVersionInfoSize = SizeOf(osinfo)
GetVersionEx osinfo
If osinfo.dwPlatformId = %VER_PLATFORM_WIN32_NT Then
   RegKey = "Software\Microsoft\Windows NT\CurrentVersion"
Else
   RegKey = "Software\Microsoft\Windows\CurrentVersion"
End If
wRegUser = GetSetting(%HK ,ByVal  RegKey, "RegisteredOwner","")
wRegCompany = GetSetting(%HK ,ByVal RegKey,"RegisteredOrganization","")
End Function

'
'
'
Otherwise this part stays the same:
HKEY_LOCAL_MACHINE\SOFTWARE\Computer Creations Software\WinLog


That's my Winlog key, doesn't matter if it's on NT/Win2k or ME/9x....


Basically read the Win32api bible or whatever book, there are a few to consider.

Also note!
'
'
When you delete a key in WinNT/Win2k  you MUST delete all subkeys first..
You do not have to do this on 9x/ME, but on NT/2k you DO....otherwise supposedly they won't delete (haven't tested it and don't want to, MS says to delete all subkeys)..


Scott

------------------
Scott

**Stuart McLachlan** · 3 Jul 2001, 02:33 AM

Originally posted by Scott Turchin:
I had read where MS wants people to go back to INI files because the registry is getting too bloated...

You wouldn't have a reference would you, I've been in many discussions over the pros and cons of registry v ini files ( and the consequent need for full un-instal programs which bloat you distributions)

------------------
Check out my free software at http://www.lexacorp.com.pg(all written in PB/DLL)

**Clay Clear** · 3 Jul 2001, 03:48 AM

Thanks, Scott! I really appreciate your replies to my two
postings over the past few days! Yes, I have every intention
of ordering, at a minimum, Charles Petzold's book, AFTER
perviewing the samples from it that I d/l'd from PB's Download
section the other day. If I can decipher the coding techniques,
I'll learn from those first. Like I said in my other posting
that you replied to, my programs (so far, anyway) are "parlor
trick" (utilities) programs that only require a minimum of DDT
programming. I won't get into fullblown apps until I learn a LOT
more about 32-bit Windows programming. When I start into that,
I'll DEFINITELY order the book at that time.

I've been using my Registry (Win98 SE) for quite a while for
my own private apps that I've written for myself. I just needed
to make SURE what would/wouldn't be safe to do with programs
that I release to the Public.

Yeah, the HKEY_LOCAL_MACHINE\Software... key was the main one
that I were mainly interested in, as that's the only one my
programs do/would use. I'm aware that programmers are
SUPPOSED to put USER info in the HKEY_CURRENT_USER (HKEY_USER,
technically) key, and machine info in the HKEY_LOCAL_MACHINE,
BUT, my programs, to date, aren't that complicated, so HKLM
is all I need.

Thanks a lot for the info about deleting the keys!

One more question for you, Scott, if you don't mind: do you
know of a reference (on the 'Net, a book, etc.) that would
go into details about what's different between WinNT/2000
and Win9x/ME that programmers need to know about? I want to
make SURE that I've got every conceivable angle covered
BEFORE I tell my end users that it's OK to use my programs
on WinNT/2000.

Thanks, Scott! You've been a GREAT help!

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]
[email protected]

**Clay Clear** · 3 Jul 2001, 03:56 AM

Scott,

One more note - I favor the Registry over INI files, regardless
of what MS says. For one thing, I have little respect for MS
programming ideologies. (sorry, Mr. Gates! ) Another thing
is, if I were to move to INI files (and, yes, I know how to use
them programmatically), it'd be harder for my users to apply
upgrades (MAYBE???), whereas my programs can internally handle
upgrades to the Registry. For example, if an upgrade to one of
my softwares required a new INI file to be installed, the user
would have to be sure to move it to the Windows (or whatever
they named it) directory; if not that, I'd have to write a new
SETUP program for them that'd do it, for each upgrade (OK,
maybe THAT I can make "generic" ), for those users who don't
know their Windows directory from their floppy drive. With
the registry, on the other hand, my upgrades could handle the
changes/deletions/additions internally, programmatically,
without the need for end-user-intervention.

Anyway, 'nuff said!

I'm going to print out this topic, so I have a hardcopy of
your replies to my Registry questions.

Thanks, Scott!

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]
[email protected]

**Scott Turchin** · 3 Jul 2001, 09:20 AM

As for the differences, I didn't buy peltzoid, I bought the Win32 API Bible, it lists the differences between api calls, shows NT only or 9x only api calls etc....
Good book, but very basic, goes as far as moving mem and that sort of stuff and building dialogs, but it is in C, and a CD comes with it, you can build little apps etc.....
It's comparable to Peltzoid (sp?)...

As for registry/ini, I guess each has their advantage. I never, or rarely put my INI in the windows directory, always stays with the app..
I'm working on a management console for Winlog now, and it will use ONE ini file for up to 250 computers, or more possibly, one change being made will affect all 250 users to cut back on admin work....so there is one advantage to them

Here's a good registry key for ya, instead of using the Startup folder, this does the same thing but sooner during the login sequence...

Under user or local machine:

g_sStartKey = "Software\Microsoft\Windows\CurrentVersion\Run"

'
'
'
And I have most of the source from up here, except enumerating keys, let me know if you need any posted...

------------------
Scott

**Clay Clear** · 3 Jul 2001, 09:47 AM

Thanks, again, Scott.

Yeah, I've been aware of the Run (called Autorun in Win95,
I *think*...been so long since I've used that OS, can't be
sure of my memory of it...will have to go to my buddy's house
and write down the key keys...he bought my Win95 pc a couple
years ago )...as I was saying, I've been aware of that Key
for a LONG time...in fact, one program (another "parlor trick"
program) that I just wrote, and will release to my adoring
Public <chuckle>, is a single program that loads at Windows
bootup, and asynchronously runs all the programs the users have
entered into its CFG file...it uses ShellExecute...then,
immediately after it runs the last program, it terminates itself...
even if it doesn't prove to be a popular d/l on my site, *I*
make HEAVY use of it, so it was n't written in vain...Ok, I'm
wandering...my point is that I'll write a SETUP program to
go with it that will establish the boot program in the Run key...
once I learn how to programmatically create my own LNK files
from scratch, I'll make the setup program give the user the
option of using the Startup Folder or the Run key...maybe I'll
just stick with the LNK file when the time comes, as that would
make it MUCH more friendly to the average 'puter user, at
least as far as their being able to delete it...'course, I can
put the uninstall feature into the setup program for BOTH the
Registry version AND the LNK one...

The Win32 Bible wouldn't do me any good, as I have NO knowledge
of C/C++, so wouldn't be able to port it over to PB...

Your statement about the INI file has me thinking...you make
a good point...I think what I'll do is use INI files for
day-to-day (dynamic) settings, and use the Reg for persistent
settings (the paths to the INI, CFG, etc. files, and other
permanent settings)...that should keep the perspective fresh...

Anyway, I apologize for my windy messages this AM...I've been up
all night coding, so my mind digresses (ain't old age FUN???
<grin> )

Regards,

Clay

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]
[email protected]

**Clay Clear** · 3 Jul 2001, 10:20 AM

Scott,

This will probably be my last message to you today, as I really
need to get to bed.

I just realized the usefulness of your idea of keeping INI,
CFG, etc. files in the same directories as the apps - by using
GetCurrentDirectory() in the apps, I'd have a MUCH faster method
of locating the support files, especially if I required that
the support files be a certain name for each app (at least as
far as the CFG files)...it's been my policy to give the user
free-reign in naming their CFG files, and they would pass the
full path/name of the CFG's to the app as a commandline
argument...but, I think I'll go to requiring a set name for
each app's CFG file...that way, it makes the finding of it a lot
more automated... The only exception would be my programs
that allow multiple CFG's...I try to avoid writing such
programs as I don't like the overhead in the code, but, for some
types of pgms, it's a good idea...there's no overhead *IF* the
CFG files' paths/names are passed on the cmdline...I guess I'll
use that method for programs that accept multiple CFG's, and
use required CFG names for apps that don't...

Anyway, to cut this short (I'm digressing, again ), by using
YOUR method, I can write programs that have minimal Registry
requirements...about the only things that'd be stored there
would be the paths to the INI files & CFG files, *IF* I give
the users the options of selecting separate directories, which
I've done so far...hmmm...that's another bit of overhead in the
programs...

OK, I'll end this message after the next few lines suffice it
to say that I'm going to recode ALL my programs to use INI's for
dynamic settings data storage, and make minimal use of the
Registry...I'll also REQUIRE that the INI's and other support
files be in the same folder as the apps' executables...and,
except for my pgms that accept multiple CFG's, I'm going
to require that the CFG files be a set name...now I'm glad that
I hadn't gotten my programs uploaded to my website, as I'd have
to repeat it after recoding them... (I really don't like
doing that kind of work - I *hate* writing DOC files! <laugh> )

OK, I'm done now. I really apologize for my many, long-winded
messages...

Have a good day!

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]
[email protected]

**Matthew Berg** · 3 Jul 2001, 02:34 PM

do you know of a reference (on the 'Net, a book, etc.) that would go into details about what's different between WinNT/2000 and Win9x/ME that programmers need to know about?

You could try the article Problems Encountered by Some Windows 95 Applications on Windows NT on MSDN.

I have a copy of an article called "Tips to Ensure Your Windows 95 Application Runs Under Windows NT 4.0" on an old MSDN CD which may or may not contain similar information. Unfortunately, I couldn't find a reference to it on the MS web site.

**Clay Clear** · 3 Jul 2001, 02:40 PM

OK, will give that article a try! Thanks, Matthew! I'll go visit
the MS site myself and do some digging, also. Unfortunately,
when I were on there digging up information on Registries last
week, I observed that most of the articles were on WinNT/2000.
There were hardly any hits in my searches on Win98, which is
the OS I'm currently running. Therefore, I can only imagine how
void it is on Win95 stuff.

------------------
Clay C. Clear

http://www.v3space.com/a/a39/202/

[email protected]
[email protected]

Announcement

WinME Registry vs. Win95/98 Registry?

WinME Registry vs. Win95/98 Registry?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment