I am developing a portable application in VB6.
My target platforms are Win XP - Vista - 7 - 8 ( I think all of them Have VB6 Run.
I one part of My application , I need to read a small text file form Internet
I used
Inet.OpenURL
And this is working well in Win Xp , But in Win7 I got this error
Run time error ‘339’: Component ‘MSINET.OCX’ or one of its
dependencies not correctly registered: a file is missing or invalid.
As this is a portable application , I can't make a Setup file.
What Can I do?
Is it possible to include MSINET.OCX in my application file?
Is there any replacement for Inet.OpenURL Which works in Win 7 ?
Thanks
For something this simple you can use the MSXML XmlHttpRequest object instead. Version 3.0 should be present as part of Windows in nearly any version (even back to Win95 if IE 5.x was ever installed).
This is generally a cleaner option then the Internet Transfer Control as long as you don't need FTP but only HTTP/HTTPS. It can also be used for async requests if you deal with its script-style event binding.
If you are only doing simple GET requests you can simply use the AsyncRead method that is built into the VB6 runtime.
Related
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
We have an old Powerbuilder app running on Server 2000 and need to move it. I am having a problem with moving the Powerbuilder app ver 7.0, to a newer platform - Server 2003.
We basically moved the directory with the app in it and all the Dlls. Then I registered the ones that would allow it. We also had to set up Informix client-side software and verified that it was able to connect to the Database.
The app basically takes 2 parameters then checks for data in a remote database, then generates a return code to be used by another app. The return code we get is unexpected and I have no luck in looking up the number:
-1073741811
The app is run from the command line. When I run the app I get a Windows error that mentions Sybase and msvcr80.dll and a dump, and the return code mentioned above - Here is the error from the manifest text:
Server=watson.microsoft.com
UI LCID=1033
Flags=99088
Brand=WINDOWS
TitleName=Sybase Inc. Product File
DigPidRegPath=HKLM\Software\Microsoft\Windows NT\CurrentVersion\DigitalProductId
RegSubPath=Microsoft\PCHealth\ErrorReporting\DW
ErrorText=This error occurred on 2/14/2013 at 7:56:14 AM.
HeaderText=Sybase Inc. Product File encountered a problem and needed to close.
Stage1URL=/StageOne/cert_lsi_exe/7_0_3_10180/msvcr80_dll/8_0_50727_6195/0001e6d5.htm
Stage2URL=/dw/stagetwo.asp?szAppName=cert_lsi.exe&szAppVer=7.0.3.10180&szModName=msvcr80.dll&szModVer=8.0.50727.6195&offset=0001e6d5
ErrorSig=AppName: cert_lsi.exe AppVer: 7.0.3.10180 ModName: msvcr80.dll ModVer: 8.0.50727.6195 Offset: 0001e6d5
DataFiles=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.mdmp|C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\appcompat.txt
Heap=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.hdmp
ErrorSubPath=cert_lsi.exe\7.0.3.10180\msvcr80.dll\8.0.50727.6195\0001e6d5
I am surprised by the msvcr80.dll request, because this app was written around 2003 and I didnt think that c compiler was at ver 8 yet. I have used Dependency Walker and see no complaints there. I am probably in DLLHell with this thing, though... does anyone have any ideas what to look for?
Thanks in Advance!
I still have a few PB 7 applications around.
Did you try Application Compatibility?
Navigate to the folder and right click on the executable and choose the Compatibility tab.
I suggest trying
Run this program in compatibility for Windows XP (Service Pack 3)
Privilege Level [x] Run this program as administrator
You may need to use Windows XP (Service Pack 2) or an earlier version of Windows.
I have a flash drive which has an application whose code is written VC++ 2008 , the application works fine in xp , but the problem arises when i plug in the drive to a windows 7 machine , it doesn't run properly. is there any way that i can make it compatible to windows by writing a code.
i dont want to set the compatibility tab in windows 7 to run the program..
i want to code it in the program , more like a patch.
You can use the Microsoft Application Compatibility Toolkit, which will tell you exactly which Windows XP compatibility shims are used by your code when you run your application under Windows XP mode.
You simply run your application and disable various shims until your code once again behaves incorrectly. The last shim you disabled is the cause of the incorrect behavior. You can then research the exact consequences of each shim as well as exactly what your code will have to do to fix the bugs it has that force it to run in Windows XP Compatibility Mode.
You probably need to add an Application Manifest to your application to request the appropriate security permissions to allow your application to do what it needs to do.
This may cause a UAC prompt to be shown to the user if elevated permissions are needed, but then your code will be allowed to do whatever Windows 7 is currently blocking.
If you know that the problem exists and know that UAC / etc ... / Manifest on Win7 don't solve your problem and that it's not connected with 32/64 bit issues, try a different approach.
I guess you know what goes wrong with your app on Windows 7. If you're not sure exactly, at least you should know where (in which logical block) your problem is located (e.g IO block, Disk read/write block, Gui, etc.
Now stick to the debugger. Hope your program isn't that big that you can't analyze it and find the source of your problem. You could have your problems because of some functions working not as expected or something like that.
Then, I guess, you could rethink / remanage your code and change it the way it works on both platform. If there is no universal solution, use #ifdefs to determine your current platform (the worst case actually, because you would have to have different binary files for different windows versions).
All these years i have been successfully using EnumServicesStatus in combination with OpenScManager (with SC_MANAGER_ENUMERATE_SERVICE) to get a list of the services installed on a computer. This has been working well since NT 4 and up to Vista.
Now, for some reason, in Windows 7 I'm not getting the whole list of the installed services, but only a few of them. No errors, just a very incomplete list of services
Has anything changed in Windows 7? Do I need administrative powers now to enumerate services (I hope that's not the case)? Using Delphi 2010 but the same code was working file in D2007.
I don't think anything has changed here. It would cause huge incompatibilities with old software. But D2007 used the ansi version ENUM_SERVICE_STATUSA and I think D2010 calls the unicode version ENUM_SERVICE_STATUSW. Maybe you are doing some manipulation in the results that assume that the result is ANSI when you are getting Unicode? Just guessing.