JRegistryKey 1.3.4 doesn't access registry under
Windows 98/Me OS. Therefore it is not compatibile with
Windows 9x familly. I tried with 1.3.2 and it works. I
will check compatibility for 1.3.3 soon.
Logged In: YES
What kind of behavior is "does not access the registry"? Do you get an error
message or an exception or is it something more subtle such as returning
null values for non-null registry keys?
If you could look at 1.3.3, that would be great. While we had a 98 box back
at BEQ, I no longer have access to that machine for testing. I've had a 98 box
buried someplace at home for about 4 years now, and its a fair bit of work to
get at. Both 1.3.3 and 1.3.4 are minor bug fix releases--nothing should be
significantly changed, so if you're not encountering the bugs in question
(explicitly passing in null values or making calls to getStringValue() or
toString() when using implicit DWORD types), you should be ok with 1.3.2.
I would like to get a handle if things break in 1.3.3 or 1.3.4 before I go
hunting for things, and a better idea of how exctly they are breaking.
Logged In: YES
RegistryKey root = new
root.exists(); // returns false under win98
RegistryValue value = root.getValue("SourceDB"); // value is
null under win98. This is normal because root doesn't exist
I think that something big changed between 1.3.2 and 1.3.3
inside RegistryKey.dll which affects win98.
That looks OK to me.
I would expect false and null for the stings you're using under 98 too. I'm
actually suprised you got anything for 1.3.2--that looks suspicious to me. I'm
not sure we have the same idea of what's breaking here. Nothing big changed
from 1.3.2 to 1.3.3--in fact all the noted changes are to the java code and
nothing at all to the native dll. I'm not saying its not broken, I'm just saying I
don't see what the problem is.
Well it seems that I have made some little confusion about
versioning. I have JRegistryKey1_0.zip file. It contain
JRegistryKey.dll with size of 36.864 bytes. When I replaced
1.3.4 dll with that I have got message that library 1.3.4
can't use dll version 1.3.2. So I mean tha this dll version
is 1.3.2. But when I downloaded 1.3.2 I saw that DLL which
works for me on Win98 is not that file. Actually library nad
dll version which works for me on Win98 platform is 1.0.
About your answer. Why RegistryValue should be null for
Win98? How you expect I be able to get registry value from
Win98? Same code for 1.0 works fine with Win98 registry and
WinXP. I expect same with latest release too.
Hmm. I'm not sure where you got that zip file, but it wasn't here, so I can't
tell you anything about it :(
Version 1.0 is comes in a file called "jRegistryKey-binaries-1.0.zip" and its
entirely possible someone has taken some of our stuff and relabelled it. If its
the only one that works with 98, we've got somehwere to start looking, but
unfortunately I'm pretty sure that one you have is not 1.3.2 either.
The key you passed isn't on my system. Ever if I fix the "\\ODBC\ODBC.INI"
typo in your string, and prefix a root key of HKLM, so we get
HKLM\\SOFTWARE\\ODBC\\ODBCINST.INI\\ ...that key isn't on my 98SE
machine, so I would still expect a false.
Now, assuming even if that string SomeName maps to something in there
which actually exists, for example, "Microsoft Access Driver (*.mdb)", there
still isn't a value of "SourceDB" anywhere in there that I can see, so asking jRK
for that value would always give me a null.
Nothing you've described here is (that I can see) is erronious. That fact that
you got code from someone who isn't us, but that does what you want, I find
Ok If you create FoxPro ODBC connection you will get such a
key. But this is not point. I tried next code also and
result was the same:
RegistryKey root = new RegistryKey("Software");
root.exists(); // returns false also on Win98, but it sholudn't
I checked dll version from that file with one from yours and
are binary identical. I don't know where I found that file
but if you want I can send it to you. Just tell me on what
When we switched to unicode back at 1.3.0, we killed all
non-unicode versions of windows. This has been verified and
fixed in 1.3.4a which is now linked to MSLU. Details here:
Now, on MY 98SE system that was all that was required, but
if this isn't enough, you may need to download the DLL from
microsoft and include this in java.library.path accordingly.
Let me know.
Well I run into onother problem now. This is a sample code:
RegistryKey root = new
RegistryKey data = new
RegistryValue rootValue = root.getValue("SourceDB");
RegistryValue dataValue = data.getValue("SourceDB");
Last line causes next exception:
ca.beq.util.win32.registry.RegistryException: Attempt to
query registry key failed with error code 234
This is not happen only if SourceDB of second key is empty
string. So if I manually set that string to be empty using
regedit then value is read and set using JRegistryKey. If I
then start again this code I'm getting a exception. I don't
know what error code 234 could be.
It a microsoft error, and its also a microsoft bug.
The String mapping of system error 234 is "More Data is Available."
I suspect this indicates they think we're not allocating sufficient space for a
read, however the space allocated is sized dynamically, after querying for how
much we need, so if that's the case, windows is lying to us about the size.
I traversed my own registry until I found one that exhibited the same problem
(this is actually quite rare)--only when we quary a value with no data. First,
we query the size of the data, and the query returns a size of 2 for what is
otherwise a non-existant value. Perhaps they store this as a null nibble. We
then malloc 2 bytes and pass the 2 back as the data size when we query the
registry. None the less, it fails with this error on my system for a specific key.
I don't know how to work around this because its clearly an undocumented
problem with windows 98, with no way of differentiating between keys with
this problem and keys that don't, aside from the error itself. Nonetheless,
you can catch that exception and proceed however you like.