My Application is dependent on PowerShell version 5. But some old windows system have not installed the same version where our application is running. So is there any way to run standalone PowerShell which I put in my application folder. So my application is not dependent on system PowerShell.
Disclaimer: We don't know your application and we don't know, why exactly it depends on PowerShell.
Further we don't know if it depends on Windows PowerShell or on PowerShell in general. We also don't know if it requires specifically version 5 or would run in newer versions too.
To answer the core of your question:
So is there any way to run standalone PowerShell which I put in my application folder.
Yes, there is!
Microsoft introduced PowerShell Core, which started as a fork and is a cross-platform edition that runs on Windows, macOS, and major Linux distros. You can download PowerShell binary archives from GitHub, extract them and just run pwsh.exe.
Please beware:
While it provides a huge amount of well-known PowerShell-cmdlets and some (most) of the Windows PowerShell behaviour, it is important to know the difference between PowerShell Core and Windows PowerShell. Refer to the repository's README for further resources.
No. You cannot have a portable version of Windows PowerShell for your application.
You also may not be able to install a newer version on an older operating system; e.g., you can't install PowerShell version 5 on Windows XP.
Windows Powershell versions depend on many things, such as OS Version, Microsoft .NET Framework, Windows Management Framework, WS-Management, Windows Management Instrumentation, Common Language Runtime, Graphical User Interface Requirements.
Here is a link with information about Windows PowerShell versions and their requirements.
I'd say it is best if you create your application so that it is compatible with the oldest possible version of PowerShell it will run with. It could be hard and tricky, but it's the only to way to ensure proper backward compatibility.
Related
I was looking into what versions of Windows support DCH drivers here. The page seems to suggest that any "UWP-based edition of Windows" supports DCH.
While I know this means that Windows 10 and newer support it, is there a PowerShell command that can be ran on most versions of Windows to output whether UWP (or DCH) is supported?
I just updated PowerShell to 7.2.1:
But the old is still installed:
How do I remove the old one? Having both installed is kinda redundant I suppose.
You don't. PowerShell Core (6+) installs alongside Windows PowerShell (up to 5.1). Windows PowerShell still contains proprietary code that has not yet been open sourced, or never will be in the foreseeable future. The main difference between the two is that PowerShell Core runs on .NET Core, and Windows PowerShell relies on .NET Framework. There is no more new development for Windows PowerShell, as new features find their way into PowerShell Core instead.
There are unrecommended and unsupported ways to purge the system of Windows PowerShell but you will very literally break parts of Windows in the process. As ofVersion 21H1 (OS Build 22000.466) Windows PowerShell remains a dependency of the core operating system and likely will be for some time yet.
I am using Visual Studio 2008 to write applications. When deploying the app, some of the systems are 32bit, while the others are 64bit. Therefore, I plan to deliver both 32bit/64bit version in the installer, then launch the corresponding version based on the bitness of the OS. How to implement the latter, i.e., get the bitness of the OS and launch the corresponding version?
Let me clarify the situation. I already developed both 32bit and 64bit EXE application with C++. Then I want to detect the bitness of the Windows in C++(I don't know .NET) and launch the corresponding version of application.
Thanks
I would recommend looking for a more powerful MSI packaging tool. Most professional tools offer you a built-in bootstrapper that provides this functionality with one click.
The VS setup project is useful for basic application packaging, but never intended to offer you full power.
It depends on what you mean by "launch the corresponding version". This implies that you already have code written that needs to choose, in which case this isn't an installer question at all - you just need to find the bitness of the OS and then install the appropriate MSI file (or VS-generated setup.exe). If it's a C# launcher you'd perhaps use Environment.Is64BitOperatingSystem.
Your question doesn't say if you are delivering code (assemblies, COM Dlls etc) that will be used by client programs. I mention this because your 32-bit setup will install and run on 64-bit OS versions in the 32-bit subsystem. The 64-bit version will presumably contain only native 64-bit code.
Note that your 64-bit setup won't install on a 32-bit OS anyway.
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