Is it possible to remote-debug a Visual C++ 6.0 application running on a Windows NT machine from a developer workstation running Windows XP? If so, is there a procedure written up somewhere?
Take a look at this article. Also this may be helpful although you don't mention which version of the IDE you're using.
Yes -- you can also use a newer version of Visual Studio. As long as you have the PDB file for the target application it doesn't matter what version it was built with (well, VS6 might not understand a newer PDB, but backwards should be fine).
The remote debugging experience on newer VS versions is a lot smoother than old versions in my experience. It is also easier to set up if you can arrange things so that you are attaching to an existing process that you have started manually rather than kicking off the process (avoid a lot of the path setup).
Related
Did they finally make x64 IDE for VS2017?
I am asking because I have ~200 projects in solution and it works bad when all are loaded, slowly eats up to 2.5GB of memory and then freezes. vsFunnel helps, but I would prefer x64 IDE.
[EDIT1]: This is something new for big solutions in VS 2017: Enable lightweight solution load
No.
(And plenty of requests here are there for handling bigger solutions and/or process dumps.)
VS2019 may help, it is not fully 64-bit but they say the debugger runs on 64-bit process and demo with Gear of War code in VS2019 keynotes launch day.
GoW debugging at 38:00
You may need to switch to VSCode or VS for Mac for full 64-bit experience.
I hit this question because on Azure Education they launch VS2017 with both 64 and 32-bit system, I'm curious but it till installing with the same installer and in the same Program Files (x86) folder, and when I try to change the folder it says
Visual Studio cannot be installed to a nonempty directory
'C:\ProgramData...\
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows
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.
Can someone tell me why I don't have all of the dev studio windows available to me when I develop on a 64-bit platform? I upgraded my dev desktop box to server 2003 x64 to match our deployment platform. Since then (I'm using VS2005) I've noticed that several windows aren't available. I can't view Processes (which is the most annoying) so I don't know which processes I'm attached to. I can attach to a process fine, but it won't show me what is already running under the debugger. There are others, but that's the one that sticks out in my mind at the moment.
My question is where are these limitations of developing under 64 bit documented (assuming they are)? (Of course, I also get the "Edit/Continue" warning dialog all the time telling me that doesn't work in 64-bit)
Also, is VS2008 any better under 64 bit?
Follow-up: Apparently my question is a little bit vague. I'm developing a 64-bit app on a 64-bit development environment. "Recompile it in x86" doesn't solve my problems.
Follow-up #2: I'm giving it one more shot. I WANT TO DEBUG A 64 BIT PROGRAM ON A 64 BIT ENVIRONMENT AND I DON'T HAVE ALL OF THE VISUAL STUDIO FEATURES SHOWING UP. HOW DO I GET THEM?
Follow-up #3: I just installed XP 64 (previously I was using Server 2003 64-bit) and those features all showed up again (Process window, etc). Apparently the server version of windows doesn't provide all of the dev features.
Can anyone tell me why?
"Edit/Continue" can work if you change the build setting to X86 :)
Here was the suggestion from StackOverflow about it.
I had some problem with NUNIT when debugging code. The solution was to use the special program in the \bin\ folder Nunit-x86.exe for old code built in x86 and use the Nunit.exe for x64 built.