I have seen that there are several different versions of the Microsoft Windows SDK:
7/.NET 3.5: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71DEB800-C591-4F97-A900-BEA146E4FAE1 (1.4 GB)
7/.NET 4: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=35AEDA01-421D-4BA5-B44B-543DC8C33A20 (500 MB)
and some others, but these should work for XP and Vista and the server operating systems as well. Now I'm somewhat confused because of the completely different file size of the .iso images. I don't find a complete list of contents on the Microsoft pages and don't want to install both.
Is the .NET 4 version not just a newer version of basically the same thing? Why is it so much smaller, is there something missing or is it just compressed much better?
I'm actually not (much) interested in .NET here, I need samples of unmanaged C++ code for Windows (most urgently the volume shadow copy example). Which SDK would you recommend and why?
The supported platforms are newer, there is no need to ship some OS upgrades.
Documentation is now an optional download via help manager.
Related
I've some .vbp,.frm files and i want to open them with VB 6.0 but i am using Windows 8.1 is there any version of Visual Basic that is compatible with Windows 8.1.Please do suggest me.Thanks in Advance.
Whats not working? Microsoft is supporting run time files for at least a few more years works up to 10 and maybe will be for a few more versions, install vb 6 and it should have no problem running unless the systems messed up.
As indicated by others, the VB6 development tools can be installed and work (with limitations) on all versions of Windows Longhorn (including Windows Vista, Windows 7, Windows 8, Windows 8.1, on up through Windows 10). Most of the limitations are project types rendered useless when Microsoft ripped away the infrastructure for them as they mutated IE and IIS over the years with little regard.
So without a license for VB6 or preferably VS6 there isn't much you can do with these files. If the projects are fairly simple you might get somewhere trying to make the completely unsupported VB5 work if you have a license for that, or if the project files are for even simpler applications VB5CCE might be of some limited use if you have that.
But in general there are no other products that can use these files to any useful extent. So as already covered many times in other questions here and elsewhere you need VB6/VS6 and the only remaining source is an MSDN Subscription or used or remaindered copies that may be for sale here and there.
I just formatted my computer not even a week ago after being on Win 7 for a long time. I thought it was safe as at work I been using Windows for like a year now and have not had to go to load Windows 7 up since switching.
Now I just got a project that is apparently set to .net 4.0.3 version and won't be upgraded at this time.
I tried downloading .net 4.0.3 on Windows 8 but it always fails for me. I get
"KB2600211 does not apply, or is blocked by another condition on your computer."
I thought maybe if I install VS 2010(as they want me to use VS 2010 becuase they are a bit worried VS 2012 will do something funky to the project and mess everyone else on the team who are on Windows 7 and Vs 2010).
Anyone know how I can get at least 4.0.3 on windows 8? I don't want to format, took so long to get up to speed and won't be able to do Win Phone 8 programming anymore.
I would also have to stick it on my other HDD as my SDD can't fit both OS on with VS on it. So I will have a very slow OS and very fast OS.
The problem is that .net 4.5 is an in-place install which replaces .net 4.0. You cannot have both installed at the same time and Windows 8 comes pre-installed with .net 4.5. For the most part you should be able to just use .net 4.5 as if it were .net 4.0 but there are some breaking changes. You might be able to uninstall 4.5 and then install 4.0, but that sounds rather risky.
At a previous job, we didn't upgrade to .net 4.5 for exactly this reason. Until everyone is upgrading at the same time, there can be substantial compatibility issues.
For a list of incompatibility issues see here. Note that this doesn't cover any places where your app may have been depending on a bug in .net 4.0 which is now fixed in 4.5 or any things like this where a type is moved to a different assembly (these are not considered breaking changes, so they aren't listed in the incompatibility list).
The international manufacturing company that I am working for is considering moving from Windows to Linux. The only reason for this that I am aware of is that the Windows automatic updates occassionaly cause some of their applications to fail. Apparently, they do not know how to turn this off. What other reasons they may have, I do not know (cost, the mobile phone effect?). My question is does Linux or some popular variant of Linux have a development environment equivalent in power and functionality to Microsoft .Net other than what Java offers, the Linux version of .Net (Mono) offers, or running Windows as a virtual machine on Linux?
It's kind of unclear what you are looking for... a Mono IDE that runs on Linux?
Have you looked at http://monodevelop.com/ ? It's not Visual Studio, but it's really not bad as IDE's go, and I think it's cross-compatible with VS project files. Should be packages available for any major Linux distro -- I know all the Debian based ones have it.
Mono's API is pretty compatible with .NET, though there are differences in some of the supporting libraries. There are apache extensions to do ASP.NET, but they are fiddly to get set up correctly.
It's a usable platform though, and it's possible to write Mono code that's 100% .NET compatible if you stay away from certain assemblies that haven't been ported yet.
I know I am 9 months late. You may have found your solution. You may look at IronPython.
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
We're looking at upgrading from Visual Studio 2005 to Visual Studio 2008. I discovered the following disturbing comment.
From Update WINVER and _WIN32_WINNT:
Beginning with Visual C++ 2008, Visual C++ does not support targeting Windows 95, Windows 98, Windows ME, or Windows NT.
Does this mean that if we rebuild our products with Microsoft Visual C++ 2008, they will stop working on Windows 98 machines? It sounds like it, but I have trouble believing they'd make that big a change.
It's not just about .NET 3.5. It's about the Windows SDK header file macros and definitions pulled in by the mandatory version bump in WINVER. So yes, Colen, Visual C++ 2008 binaries will target the Windows NT APIs only and while occasionally they may work on Windows 98, you should assume that you cannot use Visual Studio 2008 to target Win9x. You will have to use Visual Studio 2005 or older.
Yes, it does mean that: The Windows CreateProcess and LoadLibrary APIs on Windows NT before Windows 2000 and all of Windows (95, 98, and ME) will not load a DLL or EXE file made by Visual Studio 2008 (VS 9), because the PE header in the file has the required OS version field set to 5.
The error message upon attempting to load a Visual Studio 2008-generated EXE file will (be a very unfriendly modal error dialog) actually say "You need to upgrade your operating system to run this program".
I experimented with editing the field to 4. The binary will be loaded, but any use of the Visual Studio 2008 C-runtime will hang or crash the process. There are ways to get Visual Studio 2008 projects to not use their native C-runtimes, but if massive use of C++ features is important to you, this approach is not going to scale past a small application.
Visual Studio 2005 (VS 8) has most of the features of Visual Studio 2008, but it still targets early OS versions which is why at my shop we are sticking with that for the moment.
It's natural that they do not support older versions of their operating system on their newer products. It would cost them more (not just monetary cost, but also making harder or impossible to provide some newer useful features) to make things work with the limitations (and often bugs) of older systems. This happens all the time, and with everyone; new versions of GCC drop support for older less popular architectures; new releases of glibc require a more recent minimum kernel version; and so on.
These operating systems have long been retired; from Microsoft's point of view, nobody should be using them anymore. If you still want to develop for them, you can use older tools of the same vintage.
The 3.5 Framework won't even install on Windows 2000 Server at this point. So I don't believe that they will on 95, 98, or NT either. Microsoft doesn't want the responsibility of supporting these retired operating systems anymore.
It is my understanding that with the most recent KernelEx all MSVC versions targeting XP could potentially work (results depending on how many "newest" functions/features you will then decide to use)
With respect to what the answer could have been in 2008 instead, there were quite a number of patched libraries even back then (check links on the Wayback Machine if they are broken).
While I agree with JesperE, Windows 98 is such a small percentage of users that it makes little sense to target them, unless of course you know a large percentage of your customers are in fact using Windows 98.
In any case, you can in fact target Windows 98 in Visual Studio 2008 (you can't develop on Windows 98). You must, however, target your projects at .NET 2.0 only, you cannot use any 3.0, or 3.5 features.
I'd recommend that you take this as an opportunity to stop supporting Windows 9x. This is a good reason as any to do so. And, at least if you're writing C/C++ code for the Win32 API, life is much easier if you can assume that the target OS is Windows 2000 or later.
According to .NET 3.5 information, Windows 98 is not supported by .NET 3.5, so I would imagine that is what they mean. You can still do .NET 2.0 and lower development, but if you use the 3.5 libraries, Windows 98 is not supported.