To get information about the wireless LAN cards, I came across the api WlanEnumInterfaces . In the documentation, it says
Minimum supported client - Windows Vista, Windows XP with SP3
It means that the api is available on the above mentioned Operating System
The application is running on Windows XP with SP3, but when inlcude , it gives error - file not found.
If I search my whole PC, this file is not found. Even the corresponding library is 'wlanapi.lib' is missing
Any help would be useful...
You should be looking for wlanapi.dll, which is the runtime component.
Generally when you're using new APIs, you should be using LoadLibrary and GetProcAddress, so you can handle failure gracefully.
This import library is included with the Windows SDK. I have to guess that you've got an old version of it on your machine. The default install location is c:\program files\microsoft\sdks\windows\???\lib where ??? is the SDK version number (like v7.0).
You can download the SDK from Microsoft. Do make sure that the version you get is compatible with your version of Visual Studio. Do not attempt if you have an old one, like version 6.
Related
I have not enough knowledge on how to fix this. What I do know is:
Build a Executable in Visual Studio 2010 on Windows 8.1 (hence the 1-2-0.dll)
Running the executable, crashes on Windows Vista with the message: "This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Under vista you would have the libraryloader 1-1-0 if not mistaken?
this library is linked from mscorlib.dll somehow? But not referencing this dll would not build the project.
Maybe someone could direct me in correct way? Or better have a solution for this?
Is there a way to tell VS to not use this latest dll version?
I am certain I did not reference this specific DLL.
I got the same problem, in my case I was providing the d3d9.dll and d3d11.dll, that I copied from windows 8.1 windows instalation directory and ofc. I cant use those!
And then all Computers like Vista, Windows 7 and even Windows 8 had that Error:
"This application could not be started, because of the api-ms-win-core-libraryloader-l1-2-0.dll"
Because this file:
api-ms-win-core-libraryloader-l1-2-0.dll belongs to Windows 8.1
Solution?
In my instaler, Installshield, I removed the d3d9.dll and d3d11.dll, so my aplication will use the ones already in OS.
The problem was not in the "EXE" produced by Visual Studio, but in DLL dependecies that I was providing.
this problem occurred due to Compatibility with older operating systems.
this link may help you
http://msdn.microsoft.com/en-us/library/hh802935(v=vs.85).aspx
Short version:
When I moved to Win7, I manually removed the MDAC 2.7 lines from my .ISM module, built it, and installed my software. It seems to work. Can I trust it?
Longer version:
We have just gone from XP to Windows 7. The software we deliver is C# (.NET 4 framework), targeting XP and Windows 7. It contains a few older COM modules, one of which is written in VB6. (Yes, I would love to rewrite this in a modern technology, but that's not an option at this point.)
I use InstallShield 2010 to build the installer for this package. Building this installer on XP worked with no problems. When I try on Windows 7, it wants MDAC 2.7 as a prerequisite merge module. Microsoft doesn't allow you to download 2.7 anymore, and I'm not going to get it from "Sharewarez R'us" sites.
The error InstallShield gave me when it couldn't find the merge module was: File not found. An error occured merging Module 'MDAC27ENU...'
From what I've read on the web, Windows 7 has the latest-greatest MDAC (now renamed WDAC) already installed. On a whim, I manually deleted the MDAC dependencies from the .ISM, built and installed, and my software seemed to run just fine.
What I think is happening is Win7 is noticing that something in VB6 is using MDAC and the OS is supplying the latest-greatest and it just works. I no longer need the merge module because Windows 7 has WDAC built in. (Can it really be that simple?)
My main question is: can I trust it?
My secondary question is: What about XP deployments? They will still need MDAC 2.7... Does that indicate I can't build on Windows 7 to target XP if I require MDAC 2.7? Please point me in the right direction. Thanks.
You need a comprehensive review (dependency analysis) of your installer. The VB6 runtime and MDAC/WDAC components are all built into windows these days. This is also the case with Windows XP and the latest service pack.
Either your ISM is referencing the MDAC merge module or it's referencing another merge module that has a dependency on the MDAC merge module. Hence why I suggest a complete review.
Without looking at your application I can't give you a 100% answer but odds are that if you implement a setup condition (launch condition) to check for XP latest service pack or newer that you will likely work without installing a bunch of stuff you don't need to be installing.
It seems that it is impossible to find an image of Windows XP Professional x86 checked build. But I still need to support the software and do my work for that system. :(
Yes, I know that I can install only the checked kernel on the free build, but I still want to have a checked system, not a mix of the two.
Solutions, anyone?
UPDATE: It appears it is not clear from the question itself that what I am looking for is the installation image itself (an ISO image), so I can have the full checked build of the OS installed. NOT the service packs. NOT x64 image.
UPDATE 2: Why calling MS won't help: see http://msdn.microsoft.com/en-us/subscriptions/ff723773.aspx after "Products Unavailable due to Java-related Settlement".
UPDATE 3: See http://social.msdn.microsoft.com/Forums/en/wdk/thread/5fa40892-8207-425a-8866-0fcaebb0c343 -- someone suggests that "The only install disk of a checked XP was the release, i.e. no service packs. MSDN and Technet distributions had the disk as one of the set." Does anybody here have those disks? Seems that ours were lost in the sands of time.
UPDATE 4: Narrowed it down to a MSDN CD named "Windows® XP Professional Checked/Debug Build (English)", disc 1013, volume label X08-48914, dated October 2001. Anyone has that one?..
I bet that if you support your software to work in Windows Server 2003 then your software will also work in Windows XP, even though Microsoft's debugging symbols differ. You can install the checked build of Windows Server 2003 RTM, add the optional component for desktop experience, and it will be approximately the same as Windows XP with SP1 with some increased security. Checked build service packs are available for Windows Server 2003. So you can approximate every service pack version of Windows XP except for Windows XP RTM.
Checked versions are only available in English. You can install an MUI pack but the result is not identical to an actual Russian version of Windows. You'll have to test your software again in the actual version of Windows that your customers use, and that will not be a checked version.
These files are downloadable from MSDN:
en_windows_server_2003_enterprise_chk.iso
en_windows_server_2003_enterprise_x64_chk.iso
(The first paragraph was edited to mention that the Windows Server 2003 RTM download is also a checked build. Of course the download would be useless otherwise.)
I'm trying to use WIA in an older VB6 program running in Windows 7 and when I run from source everything works great and I can import images. When I run from the compiled version I get the following error:
Automation error. The specified module could not be found.
(Error number 2147024770)
I found the wiaaut.dll in both system32 and SysWOW64 so I don't know if that is potentially causing a problem. I tried unregistering and registering both to no avail. Any help would be much appreciate.
As far as I know wiaaut.dll is preinstalled in Vista and Windows 7, but this is not the redist version for XP that comes in the downloadable SDK, and it should not be deployed to those newer OSs. perhaps somebody tried to run some application installer on your machine that forced the XP version into place blindly?
Perhaps try How to use the System File Checker tool to troubleshoot missing or corrupted system files on Windows Vista or on Windows 7 to see if it can restore the original Win7 version?
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try