Windows & 16bit..

[Tyrone W. Lee]

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

[Tom Hanlin]

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

[Borje Hagsten]

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.


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

[Tyrone W. Lee]

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

[Borje Hagsten]

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).]

[Tyrone W. Lee]

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

[Fred Oxenby]

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).]

[Tom Hanlin]

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

[Tyrone W. Lee]

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

[Cecil Williams]

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

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

[Tyrone W. Lee]

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

[Lance Edmonds]

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>

[Tyrone W. Lee]

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