Debate(?): Is RegOpenKey unsupported by any version of Windows?

Is RegOpenKey not supported by any version of Windows? The documentation indicates that RegOpenKey is "only for compatibility with 16-bit versions of Windows". Therefore in How can I read data from registry using VC++6 someone said "Be sure not to use deprecated API calls like RegOpenKey()." and said that RegOpenKey "just isn't supported on newer systems". Then instead of correcting the statement that it currently is not supported on any version of Windows, the discussion continues. If someone can verify for me that RegOpenKey is in fact supported by all versions of Windows, then I think that will end the discussion and decrease the chances of such foolishness being repeated.



I am sorry, but I feel a need to respond when someone responds to a mistake by making more erroneous statements. It really helps me to deal with it if others can respond with the true facts.

I am making this a separate thread because it is better not to confuse or unnecessarily burden the original poster, and so that this issue is seen by more members than it would be if it were in the original thread, and so that the issue can be communicated more directly.

Edit: The other thread has already been edited so this issue is less important.

I'm sure all versions of Windows do support this function. The MSDN says:

Quote:

---

Client: Included in Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, and Windows 95.
Server: Included in Windows Server 2003, Windows 2000 Server, and Windows NT Server.

---

But if MSDN says you better use RegOpenKeyEx, then I would use RegOpenKeyEx.
Another quote from MSDN

Quote:

---

This function is provided only for compatibility with 16-bit versions of Windows.

---

This means that if Microsoft removes the RegOpenKey function, all 16 bit programs that uses the registry (probably almost all programs) will stop working. I think microsoft doesn't want to do this right now, because they will probably get a lot of angry customers that are still using old 16 bit software.

Here is a little bit more from the other thread that is relevant here.

First, Microsoft is not reliable when they say something indicating that a function will soon be unsupported. An example is the GlobalAlloc function, in which (in the other thread) I quote the MSDN saying that it is provided only for support of 16-bit Windows and now it says something different. I also say that RegOpenKey is used by MFC in more than a dozen places. Therefore we probably should submit something to MSDN saying that the documentation needs to be revised.

I also say that therefore if RegOpenKey is not supported by any version of Windows, then that version will also not support programs compiled using versions of VC 6 at the earliest and probably the later versions of MFC too.

Another point made in the other thread is that the registry did not even exist for most of 16-bit Windows.

Quote:

---

from MSDN
This function is provided only for compatibility with 16-bit versions of Windows.

---

Saying 16-bit versions of Windows is different than saying 16-bit applications. Wasn't Windows 3.xx the last version of windows that was 16-bit? So that would mean the statement on MSDN is false or misleading since Windows 3.xx didn't have a registry.

So I think either 32-bit or 16-bit apps run in Windows 2000 or greater may or may not have slight complications with registry security.

After Windows 3.1 there was Windows For Workgroups, which was essentially Windows 3.1 with support of networks. I am not sure if Windows For Workgroups included the registry API but probably it did. That is probably the only support of the registry provided by 16-bit Windows.

For what it is worth, IBM says (and I believe them) that the majority of the differences between Windows 3.0 and Windows 3.1 are fixes for bugs found by IBM when porting Windows to exist as a subsystem of OS/2.

thanks for the update guys, I'll buy billy bob the last remaining hold out a NT upgrade, settled?

Your given a new API, how about using it in your new code on those new fangled OS's they keep talking about.

/Not another MickeySoft conspiracy...