Announcement

Collapse
No announcement yet.

Windows & 16bit..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tyrone W. Lee
    replied
    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 www.explore-rpg.com


    ------------------
    Explorations v3.0 RPG Development System
    http://www.explore-rpg.com

    Leave a comment:


  • Lance Edmonds
    replied
    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!

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

    Leave a comment:


  • Tyrone W. Lee
    replied
    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
    systems.

    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
    http://www.explore-rpg.com

    Leave a comment:


  • Cecil Williams
    Guest replied
    Tyrone,

    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!!!

    Cheers,
    Cecil

    ------------------

    Leave a comment:


  • Tyrone W. Lee
    replied
    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
    http://www.explore-rpg.com

    Leave a comment:


  • Tom Hanlin
    replied
    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
    dependencies!

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Fred Oxenby
    replied
    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
    declarations

    ------------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se



    [This message has been edited by Fred Oxenby (edited May 04, 2001).]

    Leave a comment:


  • Tyrone W. Lee
    replied
    True..

    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
    http://www.explore-rpg.com

    Leave a comment:


  • Borje Hagsten
    replied
    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).]

    Leave a comment:


  • Tyrone W. Lee
    replied
    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
    http://www.explore-rpg.com

    Leave a comment:


  • Borje Hagsten
    replied
    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.


    ------------------

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Tyrone W. Lee
    started a topic Windows & 16bit..

    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:

    Kernel
    GDI
    User
    User32

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

    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
    http://www.explore-rpg.com
Working...
X