Announcement

Collapse
No announcement yet.

WinME Registry vs. Win95/98 Registry?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • WinME Registry vs. Win95/98 Registry?

    Are the Windows Registries for WinMe, Win95, and Win98 the
    same, functionally speaking? According to MSDN, the Reg API
    Calls exist the same for Win98 and Win2000. I don't want to
    write programs for Win2000, YET, as I have no means to test or
    debug the programs (I am running Win98 SE), and I don't want to
    take the chance of trashing my end users' OS's. However, for the
    Win95/98 programs I write, I want to start using the Registry
    to store program info. I would like to be able to do that for
    WinME, as well, but, I don't know if it'd be safe to do so with
    the same programs that are used on Win95/98.

    Thanks in advance!


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

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

    [email protected]
    [email protected]angenet.com

  • #2
    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
    Scott Turchin
    MCSE, MCP+I
    http://www.tngbbs.com
    ----------------------
    True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

    Comment


    • #3
      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)

      Comment


      • #4
        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]

        Comment


        • #5
          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]

          Comment


          • #6
            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
            Scott Turchin
            MCSE, MCP+I
            http://www.tngbbs.com
            ----------------------
            True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

            Comment


            • #7
              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]

              Comment


              • #8
                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]

                Comment


                • #9
                  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.
                  If you try to make something idiot-proof, someone will invent a better idiot.

                  Comment


                  • #10
                    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]

                    Comment

                    Working...
                    X