Does Microsoft have plans to make executables obsolete?

Matthew Turner 21

In the last 5 years I noticed Microsoft making a distinct move from batch to PowerShell as the main console provider. With more research from a developer's perspective I found a fascinating pattern of Application-As-A-Library with PowerShell's binary cmdlets. I like how it allows your application to have the flexibility of being called or being used natively without a Process object and all that overhead; and I especially like how it allows for testing the API for both use cases of a console application and a third party dependency for another application. Plus I have seen Microsoft tools like sqlcmd getting uplifted to a cmdlet (Invoke-Sqlcmd in this case).

So that begs the question, does Microsoft plan on deprecating executables? Because with PowerShell's binary cmdlets, all the same functionality can be provided in an executable-like entry point, without the need to ever have any ever again.

Accepted answer

Karen Payne MVP 35,366 Reputation points

2021-05-15T22:53:52.723+00:00

I don't see a valid reason now or in the new future for executables to go away.

If we look at the big picture, desktop solution are only part of the ecosystem and with .NET Core there is more attention to the other platforms.

In a recent Microsoft Summit I attended the only thing mentioned about executables was single executables made easier, no talk about executables going away.

Lastly, I'm sure you know PowerShell can work directly with the .NET Framework yet that does not mean anything about replacing exes.
Please sign in to rate this answer.
Matthew Turner 21 Reputation points

2021-05-17T14:40:23.083+00:00

I'm pretty sure my reasoning is valid, but thank you anyway (you did provide that bit about a Microsoft summit).
Sign in to comment

2 additional answers

Sam of Simple Samples 5,521 Reputation points

2021-05-12T19:33:47.17+00:00

When you say batch do you mean command-prompt scripts that typically have a bat or cmd extension? I have never heard of an executable version of them.

I am not familiar with PowerShell binary cmdlets but How to Write a PowerShell Binary Module indicates that the compiled binary is actually some other language, such as C#.

See What is PowerShell? It says that PowerShell is a scripting language.
Please sign in to rate this answer.
Matthew Turner 21 Reputation points

2021-05-12T19:42:43.897+00:00

Correct, batch is the term (as I know it) for command-prompt scripts with bat (for batch) or cmd.

The command-prompt is the mechanism for calling executables, hence why I am mentioning a scripting language for talking about strictly executables. Even when you double-click on an application it is being started through a hidden command-prompt mechanism. So with PowerShell, a different command-prompt mechanism, executables are no longer really necessary (note that executables, just like binary cmdlets, are written in other .NET languages, of which C# is one).

What I am really talking about it a difference in the entry point when developing. In console applications it is a public static Int32 Main(String[] args) and binary cmdlets have something different. They also both compile to binaries, just that one is exe (executable) and the other is dll (library). So if a dll can act like an exe, through the mechanism of PowerShell, what use are they in the future?

Sam of Simple Samples 5,521 Reputation points

2021-05-12T20:53:43.753+00:00

You are implying that GUI applications are started by a console, also called command-prompt. That is not true. Console windows do not exist for GUI applications unless they are created during execution using AllocConsole. A GUI application can be executed from a console or from many other ways. See Creation of a Console. It says the system creates a new console when it starts a console process. See what it says about GUI applications.

A C and C++ application's entry point is called Main because that is what the language standard says so. It is the same in Unix and Linux and all operating systems supporting standard C and C++. For Windows the entry point is defined in the link editor; the actual entry point for C and C++ is the C runtime.

Sam of Simple Samples 5,521 Reputation points

2021-05-12T21:25:01.487+00:00

Further about console and GUI applications note that console applications did not exist in the original 16-bit Windows; only GUI applications. 16-bit Windows was built on top of DOS, there were no command-prompt applications back then. Windows GUI applications were not executed by DOS, they were executed entirely separately from DOS. No console.

Matthew Turner 21 Reputation points

2021-05-13T14:57:13.353+00:00

I am not here for a history lesson. Whether my terminology is correct (I understood consoles to be the same as what Linux would call terminals) I am wondering if the current (not past) executables will become obsolete.

Since PowerShell, being .NET capable, can spin up GUI elements this does apply to both console applications and GUI applications (aka, all executables). The main point is that theoretically, all executables can be turned into libraries (a small change to their binary file structure) and open the door for native re-use.

I am also not asking about whether it is possible to obsolete executables, since I already know it is, instead I am asking if Microsoft has plans to obsolete executables.

Sam of Simple Samples 5,521 Reputation points

2021-05-13T16:15:12.547+00:00

You need to learn more about how executables work, not for things like PowerShell but for C++, C#, VB.Net and such. I am not avoiding answering your question, I just do not understand the question. For example current (not past) executables is very vague. PE Format describes the past and the current format for executables; it has not changed. Can you be specific about what you are asking? So far you have said many things that are not accurate, so that makes the question difficult to answer.

Matthew Turner 21 Reputation points

2021-05-13T18:43:24.113+00:00

This conversation is splitting in two: what is meant by "console" (that also includes what an "executable" is) and my original question on Microsoft plans.

Matthew Turner 21 Reputation points

2021-05-13T18:43:52.973+00:00

For the former, my education taught me about the fork+exec pattern that builds from a single process into the multiprocess environment of a computer. I was under the impression, whether faulted or not, that the Windows terminology for a process who was following this pattern to be a "console" (and in Linux it is called a "terminal"). I also recognize that it is also used to refer to those executables who either follow a REPL from the user or, alternatively, can be given a script in place of a user to determine which processes to kick off with a fork+exec pattern--for which we have "scripting languages". I might be confusing you because my usage of "console" is any mechanism that starts a new process, not simply the command line that is shown to a user (which would be one such "console").

Matthew Turner 21 Reputation points

2021-05-13T18:44:02.013+00:00

Somewhere along the lines of calling an executable we reach the traditional main method, whose content is the application-level code of interest to developers. Whatever the format or mechanism is, the goal is reaching that application-level code. PowerShell's binary cmdlets use a different format, libraries, that it can load and, by my understanding, reach that application-level code without kicking off a new process (aka, natively). As long as it done properly all application-level code currently compiled into any kind of *.exe (whether console application or GUI application) can be compiled into a *.dll that PowerShell is capable of executing, without any change at the application-level code functionality. I know that Microsoft's sqlcmd.exe has already made the shift to Invoke-Sqlcmd (C:\Program Files (x86)\Microsoft SQL Server\150\Tools\PowerShell\Modules\SQLPS\Microsoft.SqlServer.Management.PSSnapins.dll).

Matthew Turner 21 Reputation points

2021-05-13T18:44:17.02+00:00

All of that is merely background to the focus of my question: if PowerShell means that *.exes (whatever it means) can be replace with *.dlls (which can be natively imported in other applications), does Microsoft have plans to deprecate *.exe altogether (tell everyone to write *.dlls).

Sam of Simple Samples 5,521 Reputation points

2021-05-13T19:31:19.047+00:00

The term fork and the related concept is (as far as I know) unique to Unix and Linux inherits that.

I have been working with computers for half a century. My first experience was with IBM Mainframe computers. Your concept of consoles is misleading you. Non-console applications are not executed in the manner you understand. The only reason console is relevant is because you continue to think they are relevant.
Sign in to comment
Sam of Simple Samples 5,521 Reputation points

2021-05-13T19:39:02.187+00:00

First note that DLLs are considered executables. I assume you are asking only about executables with an exe extension. For every DLL that is executed there is one and only one exe file but each exe file uses many DLLS; note that the Windows API is entirely DLLs or at least nearly so. I certainly have not seen any plan or reason to make them obsolete. Doing so would drastically change the way many applications work and there is no reason to eliminate exe files.
Please sign in to rate this answer.
Matthew Turner 21 Reputation points

2021-05-13T20:10:46.57+00:00

PowerShell raises a reason to think about exe files (not dlls -- https://superuser.com/questions/596305/is-dll-executable/596313#596313) as obsolete.

Sam of Simple Samples 5,521 Reputation points

2021-05-13T23:11:32.83+00:00

I have unsubscribed from this. I won't see any more comments or such.
Sign in to comment

Share via

Does Microsoft have plans to make executables obsolete?

2 additional answers