Break WebGadget Dependency on ATL.DLL

[StarHawk]

Substantial costs have been incurred because of the dependency by the WebGagdet on the ATL.DLL

The problem, as most DLL hell programs are, is Microsoft's and not Purebasic. Go to Microsoft's web site and do a DLL lookup on the ATL.DLL file. You will find about 10 different versions of this file, worse, Microsoft stopped the ANSI support and now releases in UNICODE only. Worse than worse, Microsoft shipped this atl.dll with about 8 products other than Windows, and Windows users who thought, oh, I have Windows ME, I should be able to install Microsoft Office, etc.. etc... have an incompatible DLL. Worse than worse, than worse, is that other ignorant programmers have created installation packages (for older Windows operating systems) that right over the System atl.dll with a newer atl.dll that works with their program but can break other programs. Microsoft itself did this with Internet Explorer version 6.0+ being installed on a Windows ME computer. Many Windows ME people had to actually try and downgrade Internet Explorer back to 5.5.

This error of an incompatible ATL.DLL shows up on the WebGadget command which always returns a 0 and an error trap of ATL.DLL not found.

For now, I'm pondering dropping support for all Windows older than Windows XP.

I understand that one of the attractive aspects of Purebasic is its small exe size; however, if this is masked behind DLL hell dependency, its not worth it when you release a commercial program only to get dozens of e-mails about problems with the ATL.DLL

Do consider breaking the webgadgets dependency on the ATL.DLL module. I know this is more work to create, and may add a considerable amount of K (perhaps about 80K) to an exe, but it would allow developers to create a more stable, platform wide compatible product.

[Karbon]

Or you could distro a compatible version yourself.... I never thought about this - I use a webgadget and might run into this too!

Any reason we can't bundle atl.dll with our own software?

Breaking all dependencies would be good, though.

[StarHawk]

Check out the Purebasic Help file on the WebGadget control. Yes, the Atl.dll in the Compilers folder needs to be installed in your executables path, so you are distributing this DLL with your installation. But this does not correct the dependency on the "real" dll in the users System folder that is somehow interlinked with the Internet Explorer browser version 4 or greater as specified in the Help file on the WebGadget control.

Not only did I distribute this file, I created an installation package that attempts to load the ATL.DLL in the users System folder first, if this DLL is incompatible it will fail to load and so will then load the Atl.dll packaged with the installation. This solution did not work either.

The worse thing you can do to a user is to grab an atl.dll version that works with your computer (operating system) and then installs this version over the version in the Windows/System folder on a computer with a different operating system than your own. Very bad programming technique at best, loss of customer confidence and reports filed against you to the Better Business Bureau at worst. This could effectively "break" other programs that require the correct atl.dll module. Again, Microsoft has a dll lookup engine. I don't have the URL handy at the moment. But go to the Dll Lookup Web page and type in atl.dll. You will get a list of all the different versions of this file and which ones were shipped with different operating systems, and Microsoft Server, and Microsoft Office, etc...

Breaking the atl.dll dependecy would be a huge task. Imagine, you would need to somehow create the ability to view html code (latest), full Java support, etc. inside the native browser.. talk about reinventing the wheel!

I don't know what the answer is, but there has got to be a better way than to rely on the atl.dll

In the meantime, I have a "meeting of the minds" to figure out if we should cut support for everything but Windows XP to avoid this sort of "angry customer" problem in the future. If you think of a solution, let me know.

[freak]

The atl.dll doesn't contain the html displaying control. The WebGadget is
actually an ActiveX object from IE. atl.dll contains functions to display
such ActiveX objects in a window.

I'm not sure, if there is a way around this though...

Timo

[Fred]

From the MSDN:

If the string specifies a path but the file does not exist in the specified directory, the function fails.
If a path is not specified and the filename extension is omitted, the default library extension .DLL is appended. However, the filename string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for the file in the following sequence:

1. The directory from which the application loaded.
2. The current directory.
3. Windows 95: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.

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.

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

It means it has to work if you put it just in your exe Directory. But may be it conflict with a previously loaded ATL.dll. In this case, I can rename the DLL to WebATL.dll for example and it should solve this problem.

[Karbon]

Sounds like that might be a good idea... Any problem with that?

[StarHawk]

I have no problem with this, it's certainly worth the ole college try.

The strange thing is is that not all of my Windows ME clients have this problem. Only a few. So if it was an issue of Purebasic having the same filename, logic suggests that it would be an error that would occur more frequent.

If someone has a few minutes and is planning to release a commercial product using a WebGadget control they ought to check this out:

http://support.microsoft.com/default.as ... llinfo.asp

In filename type in atl.dll

Notice ANSI, the atl.dll that comes with Purebasic, format is completely dropped and all the releases are Unicode. A Unicode program runs slightly faster than an ANSI one, but only runs on Windows NT.

One major draw back to ASCII was you could only have 256 different characters. However, languages such as Japanese and Arabic have thousands of characters. Thus ASCII would not work in these situations. The result was Unicode which allowed for up to 65,536 different characters. Since Unicode is more complex it is not implemented on many Operating Systems. In terms of Microsoft; Windows NT, Windows 2000, Windows XP, and Windows 2003 support Unicode as will all future releases of Windows.

If you only run Windows NT/2000/XP you will probably want to download Unicode versions, but ANSI versions also should work.

If you only run Windows 95/98/ME you must download ANSI versions.

So what may be happening is that some how these few Windows ME people who have had this problem (several other Windows ME people the Purebasic WebGadget works just fine on) installed a bad program or a program that was for Windows XP that they wanted to see if it worked on their computer, overwrote their atl.dll with a Unicode version. The strange thing is that you would think if this happened that their Internet Explorer browser would not work either, unless Internet Explorer doesn't use the atl.dll file.

It sure would be nice if it was possible to eliminate the dependency on the atl.dll file and do away with all this DLL hell although I cannot think of how that would be achieved in a practical way.

[StarHawk]

Just got my first Windows 98 client with the same problem (however other Windows 98 clients of mine don't have this problem). Interestingly I asked her to go to her Windows/system32 folder and find the atl.dll file and tell me what version it is. The response I got back was that they had no atl.dll file in this folder. Dealing with inexprienced "not computer oriented" people and relying on their information is risky. It is quite possible that she just couldn't find the file in the folder because there are so many.

I told her to upgrade to Windows XP Home Edition and when she did, the problem was corrected.

For now I'm suspending all sales to any operating system other than Windows XP Home Edition until/if I can correct this problem. I was tempted to take the Purebasic .dll ANSI version of the atl.dll found in the Compilers folder and make the installation automatically overwrite their System folder atl.dll with this dll; however, this seems a bit unethical, especially being that it may "break" other programs on their computer, DAMN.

Enough of my rambling for now. Will keep you posted if I find another solution. Thanks for your ideas.

[plouf]

if you install compatible atl.dll in your program folder the dll in program foolder loads first (this has change to winxpsp1 < but you said no prob with winXP right ?)

[StarHawk]

I don't understand what you are asking. Can you clearify your question?

[plouf]

I don't understand what you are asking. Can you clearify your question?

I ? (i dont ask anythink)

[dell_jockey]

Hi,

as to parallel installations of DLL and other executables you guys might want to check out the following link:
http://msdn.microsoft.com/library/defau ... byside.asp

Pay particular attention to what functionality a .LOCAL file in the application directory would provide...

[techjunkie]

Why don't make a compiler flag in Pure with a static option. So you can link the dll's you want with the executable?

[techjunkie]

Correct me if I am wrong, but what I remember a windows "application" allways look for a dll in the following places (priority order),

In current directory
In %systemroot%\system32\
In %systemroot%

So the only thing you have to make sure if you run a WebGadget application is that IE is installed. But if you want to be sure of a special version of atl.dll you have to include it.

I have published an application using the atl.dll and IWebBrowse2 ocx control and I haven't included any atl.dll at all - just told the users that IE 5.5 or more have to be installed.

No complains yet...