No announcement yet.

Windows & 16bit..

  • Filter
  • Time
  • Show
Clear All
new posts

  • Windows & 16bit..

    As many of you have probably read I have written a VERY large game
    application in 16bit VB3 and PowerBasic 2.0.

    My application runs fine on Windows 3.1, 95, 98, and ME (upgraded)
    But a guy from Brazil downloaded my software ran it and recieved
    a "File Not Found" error.

    When I asked him to look in his Windows System directory for
    these files:


    He didn't have them. He had GDI.EXE in his System32 directory, but
    not in his Windows/System directory. I took my application and ran
    it on a Pentium 1Ghz with Windows 2000NT and all HELL broke loose. The
    program recieved bogus ERRORS! The most significant of these errors
    was the fact that the program attempted to set the value of a Timer
    control but the System says its not available. When the program
    goes to debug and I hit F8 on the line in question it executes.
    Apparently the control isn't avaiable or able to be seen by windows.
    If I wait a second, in debug mode and hit F8 it executes the
    line of code. - Like my 1Ghz is executing my code too fast or something.

    So my question/problem is this:

    What the hell is going on? Is Microsoft going to totally drop 16bit
    support? Can someone explain to me, as a developer what I should do?
    I hate to think all of my work will be trashed because of no-16bit

    Furthermore, why would there be versions of windows with missing files?

    I'm lost and I need direction on what to do and where to go with respect to
    development. Rewriting can take a long time and I'd be pissed to
    find out more problems will occur because of new Windows versions.

    Explorations v3.0 RPG Development System
    Explorations v9.10 RPG Development System

  • #2
    Microsoft would be quite happy to drop 16-bit support. However, it's not exactly
    practical just yet!

    Yes, there are differences between the operating systems, and that's something
    you need to be able to deal with. Normally, this is not a huge problem, you just
    have to do a bit of tweaking here and there.

    I would guess that the timer control you mention is not something that comes with
    Windows at all. It's probably a VB control. In cases where you rely on nonstandard
    DLLs or controls, you need to be sure to include them with your product (assuming
    that they're distributable, which should be the case for the controls that came
    with VB).

    Tom Hanlin
    PowerBASIC Staff


    • #3
      Yes, the timer control, like all the others, are VB "custom controls".
      To me it sounds like something else has failed before this error and
      caused a resource loss, or whatever. Same thing can easily happen in
      any version of Windows - when resources are low, system flips out and
      strange things start to happen.

      Not sure, but doesn't NT systems come with possibility to install with
      or without 16-bit support? Also-also, isn't there a limit to how much
      memory it sets aside for 16-bit thunking - something that is possible
      to increase/decrease?

      NT is mystery to me - never really had to bother with it, but - I have
      sold my VB3 app' with 16-bit PB DLL's even to MS offices here in Sweden,
      and they run it succesfully in their systems, so VB3 is definitely still
      supported by NT/2000.

      Anyway, a few hints: in your VB code, if you use API declares - make sure
      they refer to files without extention, like "GDI" for gdi.exe and "USER"
      for user.exe, etc. Read this somewhere, long ago, when Win95 was released.

      Also make sure the user has correct version of VBRUN300.DLL installed, and
      that it is intact. There are a few slightly different ones, think latest
      update came 1995. Windows has been known to be able to trash files without
      reason, so I usually tell people to clean out old installation of program,
      reboot computer and reinstall. That usually fixes most "issues", because
      people often never reboot and ends up with lots of old crap in their systems.



      • #4
        Maybe thats the problem..

        How do you control the amount of memory set aside for 16bit thunking?

        I have loaded Vb3 (editor) on this Windows NT 2000 and I've notice
        that the system can see 2 of my .DLL's when it gets to the third
        it says "file not found"

        It appears that the system can't see/load it. So if there is a way to
        control how much memory is dedicated to 16bit thunking this may
        solve ALL my problems..

        Problems like this is why I'd like, and actually am forced to go 32bit.

        Explorations v3.0 RPG Development System
        Explorations v9.10 RPG Development System


        • #5
          Don't know NT - probably via some ControlPanel setting? However, when such
          errors occur, they usually trigger a GPF. At least that's my experience of it.

          "File not found" sounds like another problem. If two of your DLL's are found,
          maybe the declaration of the third is different? Maybe worth experimenting
          with how the file name is written, Upper case, with or without extension, etc.
          (files created in 16-bit environment usually has UCASE names..)

          [This message has been edited by Borje Hagsten (edited May 04, 2001).]


          • #6

            In fact, I don't believe its a setting. I beleive its either PB or Windows.
            This DLL, works fine on my computer with Windows ME installed.
            The fact is if I make start a new Project and try to link to
            the .DLL the system can't see it.

            The .DLL is called WRITER.DLL and I will give anyone the .DLL
            and the source code with Windows2000 to figure out what the
            hell is going on..

            Explorations v3.0 RPG Development System
            Explorations v9.10 RPG Development System


            • #7
              If you are looking in a directory for a file, system files are not
              shown by default! You have to instruct Explorer to explicit show ALL files
              In NT you also have to explicit name the library-file Lib "USER32.DLL" in

              mailto:[email protected][email protected]</A>

              [This message has been edited by Fred Oxenby (edited May 04, 2001).]
              mailto:[email protected][email protected]</A>


              • #8
                If you're getting a "not found" error on a DLL, but the DLL is actually present,
                the problem is that the DLL isn't able to load successfully. The most common
                reason for this is, the DLL relies on other DLLs which aren't present. Check the

                Tom Hanlin
                PowerBASIC Staff


                • #9
                  Yes!!! That is what it is.. except all the .DLL's are present. When The
                  VB application starts it takes the following action.

                  Gets the current path of execution.
                  Links to UTIL100.DLL in that path - successful
                  Links to DRAW.DLL in that path - successful
                  Attemps to link to WRITER.DLL - unsuccessful.

                  WRITER.DLL uses a few functions from UTIL100.DLL and DRAW.DLL.
                  But Windows is not able to accept the link from WRITER to any of
                  the other .DLL's I thought it may be a sharing issue because VB
                  linked to the .DLL's first but when I only attempt to link
                  to WRITER.DLL I still get a "File Not Found Error"

                  What controls the default path of a .DLL when executed. Apparently
                  Windows is thinking "WRITER.DLL" is not in the same directory
                  with the others, but it is..

                  What can be done to control *exactly* where the .DLL's will
                  look for other .DLL's? Can I dynamicaly specify a drive path in a
                  declare statement?

                  DECLARE Sub Dash_Line LIB Path$+"draw.dll" Alias "Dash_Line" (ByVal hDCMain as WORD, ByVal x1%, ByVal y1%, ByVal x2%, ByVal y2%, ByVal line_color as DWORD, ByVal THICK%)

                  I don't think that will work..because at what point in the execution does Path$
                  get set?

                  Explorations v3.0 RPG Development System
                  Explorations v9.10 RPG Development System


                  • #10

                    Windows searches for the dll linkage either load or run time
                    in the following manner:

                    1. The directory from which the application loaded.
                    2. The current directory.
                    3. Windows 95 and Windows 98: The Windows system directory. Use theGetSystemDirectory function to get the path of this directory.
                    4. Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

                    5. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
                    6. The Windows directory. Use theGetWindowsDirectory function to get the path of this directory.
                    7. The directories that are listed in the PATH environment variable.

                    From what you are describing, you definitely have a linkage
                    problem somewhere as Tom pointed out. Hope this helps!!!




                    • #11
                      I've read the docs on what order Windows is "supposed" to load .DLLs.
                      But that facts still remain:

                      All the .DLL's are in the same directory.
                      It works on Win95, Wind98, WinME, (and probably Win3.1) operating

                      The only thing I can assume is that you can't link a PBDLL16
                      to another PBDLL under Win2000 and higher OS's. Though I believe
                      I will probably recieve the same error with PBDLL32..

                      Explorations v3.0 RPG Development System
                      Explorations v9.10 RPG Development System


                      • #12
                        AFAIK, Win2K does not support 16 to 32 bit thunking as it could cause a system instability or a security risk. Does your 16-bit DLL use some form of 32-bit thunking?

                        BTW, you fears about moving completely to 32-bit are without merit. You'll find many things much easier in 32-bit... guaranteed!

                        PowerBASIC Support
                        mailto:[email protected][email protected]</A>
                        mailto:[email protected]


                        • #13
                          Well, I figured out the problem. 16bit DLL's can't link to anything.
                          other than the registered 16bit .DLL's (namely the ones that come
                          with windows.)

                          There is a place under the Windows registry called Known16bitDlls
                          and I believe, these are the only accepted DLL that can be linked to.

                          However this DOESN'T affect VB linking to 16bit DLL's. What I did was
                          compile my 3 DLL's into 1, with the use of the $SEGMENT command
                          and everything ran fine.

                          So my Windows2000 problems are solve for now.. So I can take my time
                          for my next version and 32bit convert..

                          Wheeew.. I was getting really worried..

                          Tyrone Lee

                          Explorations v3.0 RPG Development System
                          Explorations v9.10 RPG Development System