Does anyone know how to convert .exe to windows app?

More details needed.
When you run this .EXE under Windows -- what Windows is saying?

Are you asking about converting a command line program into a GUI?

No, I'm talking about putting a windows .exe program onto the microsoft app store.
These days people are afraid to open .exe files, they expect to download an app.
Github appears to be source code only, but they don't seem to have an assembly compiler....

As usual, most likely your exe does not have description files (xml) in the resources section so that the exe is a complete WIndows app.

To figure out the missing descriptions, create a C++/C# application "Hello. I am Windows App.". Take the hex editor and see what is included in the resulting application. After that, it's enough to repeat it on fasm. fasm is similar to output to a file. You just need to repeat the result of the C compiler.

As far as I know, you need to digitally sign the Windows app before they can be deployed.

I don't know anymore than this.

Let them download the source code.

They'll complain about not being able to read assembly. To clear their mind, link them to the x86 backend C source of GAS and see which they'd rather read.

The bigger issue is that to get on the store, you'll need to get the thing signed by MS. The "official" native code option for app store development is C++/WinRT targeting Windows App SDK... The bigger problem is that I don't know what MS requires you to turn over to get an "app" signed. It shouldn't be an issue to give them code (IMO), but for example their driver verification process involves very strict static analysis of the source on the customer end before the compiler toolchain will even allow anything to build. Store apps might require some kind of automated verification on the MS end that you won't be able to feed pure assembly into, or at least binary analysis that requires an absolutely perfect implementation of what C++/WinRT would produce to avoid rejection... then they have UI guidelines, accessibility guidelines, etc, although I don't think they're too strict on those. After all that your program will end up installed in a Sandboxed location that generally won't have access to the full filesystem by default.

I wouldn't want to try to fully comply with the restrictions in assembly language since they're not extensively documented, it's more of something handled for you when writing in C++ or the preferred C# or other .NET language. You have to check whether you have access to nearly everything before using it and it isn't the same UAC type of elevation that desktop stuff uses. There's a whole settings page for allowing access to various things, and you can disable access to everything for all store apps without the setting affecting desktop programs at all, which is what I did.

Personally I don't even install MS software that I use (Powershell, Terminal, PowerToys) from the store if it's available through github, which is everything of value these days.

Also the signing certs aren't especially cheap, which is why you'll find things like the Dolby Vision extension for free (Dolby is huge and can afford to eat the cost, they get it back on every few OLEDs sold) but open source software like Krita that has an official store version charging money when it's free everywhere else because they need to cover the signing. From what I've read they're cheaper than say getting something on the Apple store (which also requires the yearly fee dev account), but you get very little benefit from it. I open the store about once every 6 months and update built-in stuff that needs it; login expires on a regular basis by default since I activated Windows with a key and don't login to my own machine with an MS account because that would be mildly insane.

That is their loss, not mine.