#14 Version 1.3.4 under Windows 98/Me

closed
nobody
None
5
2006-07-06
2006-05-31
No

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.

Discussion

  • Matt Hilliard
    Matt Hilliard
    2006-06-01

    Logged In: YES
    user_id=969951

    Hmm.

    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.

    Matt

     
  • Logged In: YES
    user_id=798648

    Example:
    RegistryKey root = new
    RegistryKey("Software\\ODBC\ODBC.INI\\SomeName");
    root.exists(); // returns false under win98
    RegistryValue value = root.getValue("SourceDB"); // value is
    null under win98. This is normal because root doesn't exist
    for library.

    I think that something big changed between 1.3.2 and 1.3.3
    inside RegistryKey.dll which affects win98.

     
  • Matt Hilliard
    Matt Hilliard
    2006-06-03

    Logged In: YES
    user_id=969951

    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.

     
  • Logged In: YES
    user_id=798648

    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.

     
  • Matt Hilliard
    Matt Hilliard
    2006-06-03

    Logged In: YES
    user_id=969951

    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
    suspect.

     
  • Logged In: YES
    user_id=798648

    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
    e-mail.

     
  • Matt Hilliard
    Matt Hilliard
    2006-06-07

    Logged In: YES
    user_id=969951

    OK.

    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:
    http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

    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.

     
  • Logged In: YES
    user_id=798648

    Well I run into onother problem now. This is a sample code:

    RegistryKey root = new
    RegistryKey("Software\\ODBC\\ODBC.INI\\ZaradeRoot");
    RegistryKey data = new
    RegistryKey("Software\\ODBC\\ODBC.INI\\Zarade");
    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
    at ca.beq.util.win32.registry.RegistryKey.getValue(Native
    Method)
    at
    com.birosoft.zarade.obrasci.ViewPart$1.widgetSelected(ViewPart.java:91)

    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.

     
  • Matt Hilliard
    Matt Hilliard
    2006-06-09

    Logged In: YES
    user_id=969951

    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.

    Matt

     
  • Matt Hilliard
    Matt Hilliard
    2006-07-06

    • status: open --> closed