<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Writing this from my laptop I do not currently have all the various
checkouts to look at the exact changes myself. But enquiring based
on the reports I have read.<br>
<br>
<a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=23523">http://bugs.freepascal.org/view.php?id=23523</a><br>
<blockquote type="cite"><a name="bugnotes" id="bugnotes">From FPC
trunk r23202 log:<br>
----<br>
* Include regdef.inc only if XMLREG is defined (non-Windows
platforms). On Windows it is not needed since the Windows unit
is included and it has all necessary declarations. Keeping
duplicate declarations in regdef.inc on Windows is dangerous
since it leads to out of sync problems.<br>
* Cleanup regdef.inc to contain only necessary types and
constants to work with registry unit on non-Windows platforms.<br>
---</a></blockquote>
<br>
I could not find any remarks on the user changes for trunk<br>
<br>
It appears this change breaks existing units. Technically easy to
fix, it complicates user code by adding a need for fidef in the uses
clause, so that compiling on windows includes the windows unit
(which would break compiling on none windows.)<br>
<br>
I understand that code duplication should be avoided.<br>
Given that before registry code only required one unit, and no
undef, I did wonder if a simple forward declaration (as
replacement) was considered, and if so, why if was not chosen.<br>
<br>
That is as an example in 2.4 the include file in unit registry
defines it's own <br>
HKEY_LOCAL_MACHINE = HKEY($80000002);<br>
<br>
That of course is not good, as it duplicates the define in windows,
with the risk of not being updated, should the value change.<br>
<br>
But it could have defined<br>
HKEY_LOCAL_MACHINE = windows.HKEY_LOCAL_MACHINE <br>
<br>
Then the compilation of other units would not have been broken<br>
<br>
<br>
</body>
</html>