No announcement yet.

Windows 95/98/NT/2000 compatibility

  • Filter
  • Time
  • Show
Clear All
new posts

  • Windows 95/98/NT/2000 compatibility

    Lately a number of people have inquired about my DLL component's
    (compiled with PB/DLL 5) compatibility with Windows 2000 and
    other platforms. I can tell them that I've tested the DLL with
    Windows 95 and 98, and I have customers who reported using it
    with NT. I haven't heard yet from customers who mentioned using
    my DLL with Win 2000, although I'm pretty sure there must be some
    out there.

    Rather than explain that my DLL will probably work with 2000,
    I want to able to confidently say Yes, it will work under Win2K.
    Someone had asked about PB/DLL 6.0 and Win2K. How about PB 5.0
    (and how about PB/CC?).

    I noticed that there's an $OPTION (or #OPTION in PB 6)
    metastatement. Does the default Option 4 work only
    with 95/98 and NT 4, or is it just a lowest common denominator
    for that and 2000 as well? Is Option 3 an even better lower
    common denominator if you want to include NT 3 users? Would
    there be any performance penalty for non-NT 3 users with
    option 3? Is there a particular performance advantage in
    compiling a special DLL with Option 5 for Windows 2000 users?

    Daniel Corbier
    UCalc Fast Math Parser
    Daniel Corbier
    uCalc Fast Math Parser
    uCalc Language Builder

  • #2

    While I can't answer your question about the $OPTION compiler
    directive, I can say this much :

    Win 2K compatibility has a lot more to do with API calls than
    anything else. In each version of Windows, Microsoft has added
    new API calls, phased out obsolete API calls and modified some
    API calls.

    It is important to get the latest docs on the API to make sure
    you are using API calls correctly for the latest version,
    but are still compatible with the earlier versions.

    You need to have your DLL "Tested" thoroughly on "all platforms"
    if you want to guarantee Win 2K compatibility. There is no other
    way. This is why a good "Beta" program for your software is
    important, since you can make sure that you have Beta testers for
    every platform.

    When I was beta testing my DLL (GUI runtime) I specifically asked
    Beta testers what platforms they were using, so I could have it
    tested on Win 95/98/NT and 2K .

    Chris Boss
    Computer Workshop
    Developer of "EZGUI"


    • #3
      There are no direct API calls in my DLL component, and I don't
      have a line of ASM code either. All of it is native PB code.
      So hopefully that wouldn't be an issue.

      The current version of my component was thoroughly beta tested
      for a very long time (in excess of 10 months). It was released
      before Windows 2000 was out, and using PB 5.0. It won't be a
      while before I can release the next version. I'm mostly trying
      to find out about compatibility of the version that is already
      out. And then there will be Windows Me, and whatever future
      version that will come after. So I want to have a general sense
      of compatability issues with PB and the various Windows versions
      out there.

      I do have an online questionnaire for my products that people
      fill out. And now that I look at it, I realize that I ask
      all kinds of questions, but now which operating system they're
      using it with. So I'll have to look at that.

      Daniel Corbier
      UCalc Fast Math Parser
      Daniel Corbier
      uCalc Fast Math Parser
      uCalc Language Builder


      • #4

        Have any of your end users reported problems with any platform ?

        If you don't get any reports of problems, then likely your OK.

        If you don't make any API calls, then the only possible problem
        would be when your DLL calls the OLE API from the runtime code
        generated by the compiler for variable length strings. I doubt
        you would have any problem with this, since not only does PB
        depend on the OLE DLLs, so does VB and VB works on all platforms.

        If your DLL works on NT, it will likely work on Win 2000, since 2000
        is more like NT than 95/98.

        Usually the biggest problems are with API calls changing on a new
        platform, so I can't imagine you having any problems with a DLL
        that doesn't make any API calls.

        I do know that DLLs created with PB 5.0 (as well as 6.0) work on
        WIN 2000. My DLL, EZGUI has been successfully used on all platforms
        and was Beta tested on Win 2K, NT, 98, 95 and there weren't any
        platform related problems.

        Chris Boss
        Computer Workshop
        Developer of "EZGUI"