On MSDN lot win32 functions contain this statement:
Requirements: Minimum supported client - Windows 2000 Professional.
Is it really necessary to use the pro version, or function works with home version.
I use windows-xp home, and I can run many functions, but one function fails without reason, could be that it fails because I do not use pro version?
There was no "Home" versions of Windows 2000, Professional was the only non-server version released.
If the documentation displays it as the minimum supported version & do not list exceptions for XP, then anything with a minimum of "Windows 2000 Professional" will run on XP Home or Pro.
Related
Microsoft no longer supports VB6 development and support from Microsoft has already stopped. But VB6 applications still run on Windows 8.1. See also this article titled "Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1".
When would a VB6 application stop running on Windows? Is there any official statement from Microsoft or any clue about the same?
EDIT:
In this link, the Visual Studio team has mentioned that, "It will be supported at least through 2024". But it's not clear whether they said it's supported in Windows 8 till 2024 or in future release of windows OS too.
The "2024" means as part of Windows 8. The link says the VB6 runtime is part of Windows and therefore will be supported in the same way as the rest of Windows. For example Windows 8 will be supported until 2024 because that's the support lifecycle for Windows 8.
EDIT: Microsoft have now said the VB6 runtime is officially part of Windows 10 too.
EDIT: the VB6 IDE (not runtime) is no longer officially supported on any version of Windows, but there are ways to get it to work on Windows 7 and 8.
Uservoice: The VB6 runtime it is still a component of the Windows operating
system and is a component shipped in Windows 8.1. It will be supported
at least through 2024
It seems clear they mean VB6 will be supported through 2024, not just VB6 on Windows 8 (whose mainstream support ends 6 years earlier anyway).
The VB6 programming language installs and runs on Windows 7, 8.x and 10.
There is a utility to install it here: VB6 IDE install utility
It is in Microsoft's interests for VB6 applications to run in Windows 10 and so they probably will. The same is probably true of most old application frameworks: Microsoft works hard to maintain compatibility. The IDE runs on Windows 7 (not sure about 8 or 10).
However, just because Microsoft says VB6 will run it doesn't mean your particular application will work, particularly if you use third party components. You should at least be thinking about migrating to another development environment.
From what I heard, VB6 applications still work on Windows 10 technical preview. I've seen no official statement yet, but it would seem that VB6 will stay supported for at least a few years.
Microsoft have just stated for VB6 programming on Windows 10:-
"Windows is committed to compatibility. The Windows compatibility team
has been looking at user telemetry and reacting to feedback from
Windows Insiders to ensure that existing apps work well with Windows
10. Windows 10 is designed to run Windows 8.1 and Windows Phone 8.1 software programs. And yes, everyone’s favorite VB6 Runtime will
continue to work, too. In the near future, the compat team will go
more in-depth on this topic on Blogging Windows."
Everyone's favorite VB6 programming on Windows 10
So VB6 programming will work on Windows 10, as does VBA programming.
They also state that 'Project Centennial' Universal Windows Platform Bridge will work with VB6 code.
Instructions for installing the VB6 IDE are available here...
In my personal experience if you build a dll in VB6 and add it as a component to COM Plus in Server 2016 it just won't add. You will get an error such as the following, even for a 'Hello World' component.
A registry value was changed while installing the following component
into a COM+ Application. If you are experiencing activation problems
with this component then please check the registry value for the
following key.
Component: C:\temp\Project1.dll
Registry Key:
CLSID\{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32
Process Name: RunDll32.exe Comsvcs.dll file version: not loaded
There is a project to provide a new language "RADBasic" which is intended to be compatible with the VB6 programming language.
New language compatible with VB6 programming
Looks like Microsoft just extended VB6 runtime support out to Windows 11 and Server 2022. No such luck for the IDE though.
Read more from Microsoft here:
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy
I am developing a few scripts depending upon Windows Management Instrumentation Command-line (WMIC). What is worrying me is support of WMIC for different versions of Windows.
I have found a few pages here and there. For example,
http://ss64.com/nt/wmic.html points "WMIC is available on Vista/Windows 7, Windows XP Professional, but not Windows XP Home". But these links are quite old.
I have already checked WMIC in Windows 7. How to find what are the platforms WMIC support.
Can I assume in the following windows platforms, WMIC is available:
Windows XP
Windows 7 (32bit and 64bit version)
Windows 2007 (32bit and 64bit version)
Windows 2012 (32bit and 64bit version)
WMIC is supported in every SKU of Windows after Windows XP, so, yes, you can assume it will be there.
See http://msdn.microsoft.com/en-us/library/aa394531(v=vs.85).aspx, which states the minimum version of the supported OSes as XP and Server 2003.
You must aware for some changes about WMIC within XP to 7 even higher.
For example, Volume switch there is in Win7 but not WinXP.
I suggest to use and test with minimum state that is WinXP.
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.
I will be testing an application that claims to run on Windows XP, Windows Vista, and Windows 7. I know that I have to test the application for each of those on 32-bit and 64-bit (if it exists), but I'm not sure if it's necessary to test each edition of each operating system.
For example, do I really need to test for Windows 7 Starter if I already tested Windows 7 Ultimate or Home? Do I need to test Windows Vista Business if I already tested Windows Vista Home Premium? And so on ...
It would be very time-consuming to test each and every edition of each of the three flavors that are supposed to be supported:
Windows XP Home w/ SP2
Windows XP Professional w/ SP2
Windows Vista Starter
Windows Vista Home Basic
Windows Vista Home Premium
Windows Vista Business
Windows Vista Enterprise
Windows Vista Ultimate
Windows 7 Starter
Windows 7 Home Basic
Windows 7 Home Premium
Windows 7 Professional
Windows 7 Enterprise
Windows 7 Ultimate
Let me know what you think.
In our workflow we test each platform and architecture, not every edition.
For example, test on XP, Vista, and 7, and 32- and 64- bit architectures. There is no need to test both XP Home and Professional on the same architecture unless some feature of your software depends on a functionality only present in Professional.
It would be good, but it is not necessary. A prudent approach would be to test it on the edge cases.
For example, if it works on XP SP1 and SP3, it probably works on SP2. If it works on Windows 7 Home Basic and Windows 7 Ultimate, then it probably works on Windows 7 Professional.
Use your best judgment. Its easy to post an answer that says, "Do Everything!", but in reality, that is not practical.
It would require analysis from your part.
If you'd use dll's or features only available in some Windows editions, or rely on Hotfixes integrated in an SP but not in the base edition, you'd have to test on each of the different versions.
However, I'd say in most situations testing what you suggested should suffice.
I would definitely test the following versions from your list:
Windows XP Home w/ SP2 [Yes]
Windows XP Professional w/ SP2 [No]
Windows Vista Starter [Yes]
Windows Vista Home Basic [No]
Windows Vista Home Premium [No]
Windows Vista Business [No]
Windows Vista Enterprise [No]
Windows Vista Ultimate [No]
Windows 7 Starter [Yes]
Windows 7 Home Basic [No]
Windows 7 Home Premium [No]
Windows 7 Professional [No]
Windows 7 Enterprise [No]
Windows 7 Ultimate [No]
My understanding is: If it works on the most stripped basic version, it will work on the the ones that are more feature packed.
The only difference between Home/Professional/Ultimate/Orgasmic would be the larger scale features that are included. The API should be identical.
A possible alternative is to skip testing and simply ship it. This provides you with a small army of testers with all kinds of environments, some of whom will report to you (with angry e-mails or demands for refunds, perhaps).
For some years, I was in a happy position where I had essentially a captive customer base (this was in-company) and my code either worked for them or they reported on failure and I'd fix it the same day. THEY WERE GRATEFUL to get fixes so quickly; other departments tested their code and had lengthy release cycles but not really fewer bugs; and if something went wrong it took ages to fix.
This may not be good advice for you, but (as my anecdote shows) it would depend on the circumstances. If you're not worried about annoying a few users or tarnishing your reputation, this might allow you to cut a corner or two.
EDIT:
Based on your feedback, you're in the (more common) situation where this kind of operation would earn you a spanking. In that case, I'd agree with the recommendations of some other answers that encourage you to test all major releases but not the different editions.
As the programmer, you should theoretically have a feel for what distinguishes the Home/Premium/Whatever versions. These days, as far as I've seen, that tends to be stuff like:
Is there server-type software (like IIS) included?
Is there a limit on network connections?
Does it ship with all languages?
Which multimedia gadgets and codecs does it include?
In some cases, the difference in versions came down to a single flag stored in some number on the CD... identical code, just an option for toggling capabilities. Unless the subset of capabilities has an impact on your code, you're probably safe to ignore it. A sensible approach might be to test with the lowest common denominator (i.e. the "poor peoples' editions") of the product, as that will
be the least expensive to purchase for testing on; and
have the greatest number of restrictions on what your code can do.
But as usual, Your Mileage May Vary.
I'd start with the Windows Application Compatibility Toolkit from Microsoft, the Win 7 version is here. You should be able to back track from there through the Vista and XP ACTs.
I am a .net and java deloper. I have an MSDN subscription with access to all editions of the Windows 7 operating system. I am going with a 64 bit installation. Which edition of Windows 7 should I install on my development PC: Professional, Ultimate, Enterprise, Enterprise N, etc.? Thanks in advance.
Put Ultimate on the box and run the others in virtual machines.
If you have access to all versions, I see no reason not to install Ultimate.
As long as your tools run on the OS it shouldn't matter
(btw: I'm running ultimate and it's working out fine)
I think you should use Vista, or even XP for developing your .Net Apps
the reason is your apps have to be backward compatible.
Remember most users still use XP.
And you cant sell your app to an XP user even if your app is very clever, because they cant install it.
And at last .Net is Platform independ , you can use it on which ever windows version you want. (even for Linux)
(excluded windows 3, 98)