none
Use of OemRegistry.dll with WEC2013 RAM-based registry RRS feed

  • Question

  • The OemRegistry.dll shall be used to implement persistent storage of the RAM-based registry if OAL based implementation (WriteRegistryToOEM/ReadRegistryFromOEM) is not possible or desired. The DLL exports function like

    • ReadRegData
    • WriteRegData
    • RegistryOperation

    The function RegistryOperation is called during system startup several times with the dwOp parameters:

    • REGOP_START_RESTORE
    • REGOP_END_RESTORE
    • REGOP_DO_IMPORT

    After the call with REGOP_START_RESTORE the function ReadRegData is called until it indicates end-of-data wit a return value 0. If the data stream consists of the data that has been previously written in WriteRegData calls then all data is restored. But this data does not replace the default registry but it is added.

    The article Persisting Data with the RAM-Based Registry (Windows Embedded CE 6.0) describes explicitly that the function ReadRegData shall be implemented. You find in the article a link to the page File System Initialization of RAM-based Registry (Windows Embedded CE 6.0) that does not cover calls to the OemRegistry.dl functions at all.

    • How should a the OemRegistry.dll be used for a RAM-based registry?
    • What is the intention of the ReadRegFunction and the REGOPEN_END_RESTORE, REGOP_END_RESTORE, REGOP_DO_IMPORT sequence?


    • Edited by Harper23 Thursday, October 27, 2016 11:47 AM
    Thursday, October 27, 2016 11:28 AM

All replies

  • What do you mean by "How should a the OemRegistry.dll be used for a RAM-based registry?"  I can interpret that question in many different ways.

    If you mean how do you test your code?  Call the function RegFlushKey() from an application.

    If you mean how do you include it in your OS?  See https://msdn.microsoft.com/en-us/library/ee489958%28v=winembedded.60%29.aspx?f=255&MSPPError=-2147217396

    As far as the macros go, you would use those if you have some elaborate registry updating to do outside of the data flushed to your storage location.  For the basics, you don't need to worry about those.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Thursday, October 27, 2016 1:33 PM
    Moderator
  • What do you mean by "How should a the OemRegistry.dll be used for a RAM-based registry?"  I can interpret that question in many different ways.

    Hello Bruce,

    Thanks for your reply. You're right, I am too unspecific with the question. The OemRegistry.dll can be used to store the registry data to NOR flash with the WriteReadData function. So saving data is not a problem.

    The question arises how to restore the data. The OemRegistry.dll exports the ReadRegData function. It looks like it would be usable to read the data from NOR flash. But the DLL is not included in the description here.

    If this DLL is not part of the process that restores the registry, what is the sense behind the function ReadRegData?

    Testing the code is a different topic. Of course I can initiate saving registry data by a call to RegFlushKey. But this doesn't touch the registry restore process.

    if you have some elaborate registry updating to do outside of the data flushed to your storage location.

    What do you mean with "updating to do outside the data flushed"? Currently I just want to implement persistency without special features.


    • Edited by Harper23 Friday, October 28, 2016 5:45 AM
    Friday, October 28, 2016 5:35 AM
  • Why are you referring to old documentation that clearly used a different method?  Doesn't make sense.  If in doubt, try it.  Add some DEBUGMSGs to the code and see if it gets called - that would have been way quicker than asking here, wouldn't it?

    "What do you mean with "updating to do outside the data flushed"? Currently I just want to implement persistency without special features"  When you ask questions about features that you don't need, you will get answers about features you don't need - please don't ask why I answered it.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Monday, October 31, 2016 6:15 PM
    Moderator
  • Hello Bruce,

    I am very glad that you answer in the forum and help other users to solve tasks with WEC2013. Your input is highly appreciated. I am not a native English speaker so my postings are a bit clumsy. If this has somehow offended you, please excuse me, this wasn't intended.

    Why are you referring to old documentation that clearly used a different method? Doesn't make sense.

    This is a good point. Somehow I missed the point where Microsoft has documented this points for the WEC versions 7 and 2013. I was searching for the topic OEM registry implementation. I searched for "Compact 2013 RegistryOperation" and found https://msdn.microsoft.com/en-us/library/ee490573.aspx This page has also a link to the Registry Function (Compact 2013) page. I found just a list of the function, no hint what functions belongs to what (OAL, OemRegistry.dll, any other program that uses the registry), no description how they are related. That's all I found  in the reference section. I browsed through all the WEC2013 documentation and found nothing related. Microsoft has just failed to document how the RAM based registry should work in WEC2013, or they have managed to hide this very effienctly.  

    So I extended my search and accepted that only old versions are documented. And the description at the File System Initialization of RAM-based Registry (Windows Embedded CE 6.0) matches what I could discover with the kernel debugger. So my assumption was that this has not much changed in WEC2013 and so I am referring the old documentation. I would be glad to find a newer documentation. If you know about it, please give a hint.

    If in doubt, try it.  Add some DEBUGMSGs to the code and see if it gets called - that would have been way quicker than asking here, wouldn't it?

    Well I did so and could see that the OAL function ReadRegistryFromOEM as well as the function RegistryOperation in OemRegistry is called. I also implemented both and realised that the data returned from ReadRegistryFromOEM replaces the default registry (default.fdf) but the data returned from ReadRegData in OemRegistry.dll does not replace the default registry (instead everything returned by ReadRegData it is added).

    Since I did not found a WEC2013 documentation about how the OEM could implemenent the persistency I asked here. I found the two method to provide data for the registry but I am not sure how to use and when to use them. Obviously the question was not clear. I explained in more detail hoping that this now more readable.

    "What do you mean with "updating to do outside the data flushed"? Currently I just want to implement persistency without special features" When you ask questions about features that you don't need

    Sorry, I don't know what features I need. I am looking for the whole picture. You wrote about a different aspect of providing data. First I want to know how to return the saved the registry data to the running system. I read your repsonse as there is additionally possibility to modify the registry data. I fear my English skills failed to catch this correctly and suspected that the ReadRegData in OemRegistry is for a different pupose you mentioned. Can you give me a hint?

    Many Thanks,
    Harper

    Tuesday, November 1, 2016 6:14 AM