I was trying to do some legacy work, and looked up Visual C++ 6 on MSDN. I can no longer see it, and the best I can do is Visual C++ 4.2!
Does anyone know why this is the case? Is there a way to get it still from MSDN?
That was the result of a lawsuit, started by Sun Microsystems, the owners of Java. Microsoft obtained a license to implement Java on Windows and implemented their own JVM. Giving it capabilities beyond the JVM implementation that Sun maintained. Sun was not happy about it and sued. It was settled out of court, Microsoft agreed to discontinue their JVM and all of the products that used it. Like VC++ 5.0 and 6.0, Windows 98 and ME, Office 2000 and XP, IE 5.5. Only VB6 survived since its IDE didn't use the JVM.
You can still obtain a license at an auction site like Ebay. Caveat emptor, prices are high.
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
Does windows 8 supports visual source safe (or the other way around?)
Aka, can you install visual source safe running windows 8?
My advice is, don't go closer to Visual SourceSafe than you can spit a rat. VSS has NEVER worked right. Data corruption is all too common. When I worked as an independent consultant to Microsoft in the late 1990's and spent some of my time in Redmond, I found out MS's little secret. Virtually none of the Microsoft development projects used their own VSS. Their internal source code control in the early '90s was a customized version of the old RCS file-based system. They then bought source code rights to Perforce and created a customized version of Perforce for their own use. Now, at least since Visual Studio 2012, they only officially support their own Microsoft Team Foundation Version Control (TFVC) and Git. Support for only those two has been built into VS 2012 and newer IDEs.
Again, even the Microsoft programmers joke about VSS being a "code destruction device." If you already have a honking lot of projects in VSS 6 (which IIRC was built in 1998 and discontinued in 2006), you might want to track down the upgrade to VSS 2005, which is rare, but at least "supported" to whatever degree until sometime in 2017. I also have no idea if either is compatible with Windows 10 (I've installed 6.0 on Windows 7) I'm not sure it's any better, and Microsoft makes it very hard to find full or upgrade downloads of VSS 2005 on their site, but I recall seeing a link for it on one of the MS forums. Search for it.
OTOH, if you are not welded to VSS and don't want to use either TFSC or Git, Subversion (standalone) is a very good alternative (CVS is a dead issue and is not being supported). My current client has development teams using either Git or SVN for their .NET (yuck) projects.
DISCLAIMER: My personal experience (as StackOverflow wants to see for opinion posts) covers 40 years as a top-level software design and development consultant for primarily Fortune 50 companies, during which I have used extensively just about every major COTS and open-source make utility, bug-tracker, and version-control system available. I was a primary beta-tester for the original PVCS (Polytron Version Control System), later bought by Borland. I have also written a proprietary text delta-based version control system for Dow Jones in the early '90s.
We've got it to work.
When it says you'll have to close all running program's it isn't just being nice.
Yes, and in windows 10 too.
Copy and paste VSS from other computer in any folder in new computer.
For register in VB60 ide, execute SSINT.EXE
Find an run .EXE in VSS folder for other opcions
Yes. It can be installed in Windows 10 computers too.
Is there some kind of SDK out for WinRT.? Can we develop applications for it now?
Is VS2010 usable for developing or will some other IDE be shipped? Also, is C++ necessary to develop performance-oriented apps in WinRT, or will the C# applications give equivalent performance? Can development be done on Win7?
I am curious about this because I missed out when WPF was released and I don't want to miss out on this.
Take a look at the Windows Dev Center where you can download a copy of Windows 8, complete with all the new tools for developing for it.
Visual Studio 11 Developer Preview is also available on Subscriber Downloads if you do have a subscription, and it includes the WinRT SDK and runs on Windows 7 and other operating systems. So you can build it and debug it, but you still have to run your code on a Windows 8 machine.
Performance-wise, WinRT doesn't change the guidance for whether to use native code. The APIs will behave near identically regardless of what language you choose, so make the decision between C++ and C# just as you would today.
I need to install the Windows Embedded CE 6.0 package that works with Visual Studio 2005 because I need to upgrade an old driver that runs under CE 6.0. I understand that Microsoft does not support this CE package any longer and, in fact, they no longer provide the installation files for CE 6.0
Where can I get the Windows Embedded CE 6.0 installation files??? They can be in an ISO file or whatever format is available.
I'm not sure if I understood your question right. By package you mean BSP (Board Support Package)?
If you are new to CE, you will need a brief explanation before get started.
The Windows CE 6.0 itself doesn't have exactly installation files. The runtime system is built through a toolkit called Platform Builder. As "input" for platform builder, you select which components your runtime image will have (including drivers) and as "output" is created a binary image of your system. You may transfer your runtime image to the device with a few different methods.
Regarding drivers, they usually are distributed through BSPs. BSPs are built by the device maker so you could check the device manufacturer site for BSPs, but you can give a try first on the supported packages search (http://www.microsoft.com/windowsembedded/en-us/downloads/board-support-packages-for-windows-embedded.aspx).
You can get the Platform Builder Toolkit with a Microsoft Authorized Embedded Distributor or through a MSDN subscription (http://www.microsoft.com/windowsembedded/en-us/evaluate/how-to-buy-windows-embedded-compact-7.aspx). The Platform Builder for CE6 comes with a copy of VS2005.
Windows CE6 is currently at R3 (released in 2009) and it is supported (mainstream support) at least until 2014 (http://www.microsoft.com/windowsembedded/en-us/evaluate/windows-embedded-roadmap.aspx).
I strongly recommend you to take a look at least on http://www.microsoft.com/windowsembedded/en-us/develop/windows-embedded-ce-6-for-developers-overview.aspx. I'm not much experienced with CE6 (few months) but my personal experience says that it's a long path to code drivers for CE.
I have an old dll that uses the Microsoft Visual C++ 2003 (7.1) run time package. Unfortunately I don't have that DLL around anymore. Short of reinstalling VS2003, is there another way to get the run time redistributable dll?
Storm's answer is not correct. No hard feelings Storm, and apologies to the OP as I'm a bit late to the party here (wish I could have helped sooner, but I didn't run into the problem until today, or this stack overflow answer until I was figuring out a solution.)
The Visual C++ 2003 runtime was not available as a seperate download because it was included with the .NET 1.1 runtime.
If you install the .NET 1.1 runtime you will get msvcr71.dll installed, and in addition added to C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322.
The .NET 1.1 runtime is available here: http://www.microsoft.com/downloads/en/details.aspx?familyid=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en (23.1 MB)
If you are looking for a file that ends with a "P" such as msvcp71.dll, this indicates that your file was compiled against a C++ runtime (as opposed to a C runtime), in some situations I noticed these files were only installed when I installed the full SDK. If you need one of these files, you may need to install the full .NET 1.1 SDK as well, which is available here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d (106.2 MB)
After installing the SDK I now have both msvcr71.dll and msvcp71.dll in my System32 folder, and the application I'm trying to run (boomerang c++ decompiler) works fine without any missing DLL errors.
Also on a side note: be VERY aware of the difference between a Hotfix Update and a Regular Update. As noted in the linked KB932298 download (linked below by Storm): "Please be aware this Hotfix has not gone through full Microsoft product regression testing nor has it been tested in combination with other Hotfixes."
Hotfixes are NOT meant for general users, but rather users who are facing a very specific problem. As described in the article only install that Hotfix if you are have having specific daylight savings time issues with the rules that changed in 2007. -- Likely this was a pre-release for customers who "just couldn't wait" for the official update (probably for some business critical application) -- for regular users Windows Update should be all you need.
Thanks, and I hope this helps others who run into this issue!
After a bit of googling, it seems that there never was a separate redistributable for Visual C++ 2003 (7.1). At least that is what a post on the microsoft forum says.
You may however be able to extract the runtime DLLs from the VC 7.1 DST timezone update.
the answer https://stackoverflow.com/a/6132093/1498669 is right.
There is also an update to both 2002 and 2003 runtimes
just do an search on microsoft download
https://www.microsoft.com/en-us/search?q=mfc70
https://www.microsoft.com/en-us/search?q=mfc71
and you find the offical updates to the products
however, the latest patches seem to be:
https://www.microsoft.com/en-us/download/details.aspx?id=3644
https://www.microsoft.com/en-us/download/details.aspx?id=22539
https://www.microsoft.com/en-us/download/details.aspx?id=6818
Another way:
using Unofficial (Full Size: 26.1 MB) VC++ All in one that contained your needed files:
http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/
OR (Smallest 5.10 MB) Microsoft Visual Basic/C++ Runtimes 1.1.1 RePacked Here:
http://www.wincert.net/forum/topic/9794-bonus-microsoft-visual-basicc-runtimes-111/
I think this is what you're looking for: Microsoft Visual C++ 2008 Redistributable Package (x86)