[Knarfe1000]

Okay than. I wanted to test someting with elder builds.

[Nightmare]

Couldn't you just name the old builts exactly the same like the current builts and than smuggle them in?

[jr2]

Couldn't you just name the old builts exactly the same like the current builts and than smuggle them in?

I think there is communication between FSO and the launcher and the protocols used are different (don't quote me; feel free to correct if this is not the case).

Although I wonder how hard it would be to make older builds use Knossos protocol for mods etc that have not been / maybe will never be updated by FSCRP.  Probably too hard to bother with I imagine.

[jr2]

Any time to try this?  Found perhaps a couple more methods around it in case it comes in handy:
https://stackoverflow.com/a/10001420

Hidden Text: Show

Warning! While this approach was probably more or less OK for the original poster, it isn't really a good idea in general. In particular, note (as per the comment thread) that artificially manipulated tokens have been reported to cause problems in more complicated applications, so if you are using them, be sure to stick to the basic Win32 API. There are of course also potential security implications.

In most scenarios similar to those of the OP, it would probably be preferable to replace the shortcut that launches the elevated application with a launcher application. The launcher can then remain running for as long as the elevated application is running, and provide a natural limited token for the elevated application to use to launch non-elevated processes.

There's code for launching a low integrity process, which is analogous to your case, in the Designing Applications to Run at a Low Integrity Level article in MSDN.

First, you duplicate the process token, since you can't (or at least shouldn't) mess about with a token that is already being used. Then you use SetTokenInformation with the TokenIntegrityLevel class to set the integrity level. There appears to be a bug in the example code, since the correct SID for low integrity level is S-1-16-4096 rather than S-1-16-1024, but you'll want medium integrity level anyway, which is S-1-16-8192. These can be found here.

Once you have this working (that is, once you are able to launch medium integrity processes from your high integrity process) you should try using CreateRestrictedToken to create the new token instead of DuplicateToken, and remove the Administrators token and all privileges (except SeChangeNotifyPrivilege). Otherwise, the new processes will have medium integrity but still have administrator privilege, which could make it easier for any malicious code that might be running in the same session to elevate its privileges.

https://stackoverflow.com/a/9914500

Hidden Text: Show

I've used the approach described here to accomplish this. The basic idea is to ask Explorer to run Process B for you. Since Explorer typically runs at medium integrity level, this gives you what you want.

http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/

http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/

The first link will at least give you a good background.

We have a legacy application (Process A) that unfortunately has to run with elevated "admin" privileges (accomplished by setting its shortcut to always run as administrator).

A cleaner way to do that is set the requestedExecutionLevel to the manifest.

2)

The cause is that once an application has admin permissions in Windows, it can't drop them.

Can something like this be done?  Again, it would involve invoking a second instance of Knossos, so that would have to be supported (first one could always exit after launching non-elevated version?)

You can also do it the other way around and start a program as your normal user from a elevated cmd prompt using the runas command.



If you use the /savecred parameter you'll only be asked for your password once.



For example with your forum name and notepad

Code: [Select]

C:\WINDOWS\system32>runas /user:cniggeler /savecred notepad


or to open a certain file with your program (for example C:\Windows\WindowsUpdate.log)

Code: [Select]

C:\WINDOWS\system32>runas /user:cniggeler /savecred "notepad \C:\Windows\WindowsUpdate.log"

EDIT2: Got it!! (well, pretty sure anyways) right  here:

SetTokenInformation
Change Token to Medium Integrity Level

https://weblogs.asp.net/kennykerr/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control

[wookieejedi]

Reaming builds to be exactly the same is a pain if you are trying to bug find and again doesn't work after 3.8. The easiest solution is to just setup a wxLauncher folder for testing older builds. I say this from experience trying it both ways 

[ngld]

I think there is communication between FSO and the launcher and the protocols used are different (don't quote me; feel free to correct if this is not the case).

Older FSO versions used to store settings, pilot files, etc. in the game directory while 3.8.0 and later store them in AppData. You can launch older builds with Knossos but all the fs2_open.ini settings made through Knossos wouldn't work since the build will be looking in the wrong place. You can still manually edit the fs2_open.ini, of course. There's another bug affecting macOS and possibly Windows in older builds that breaks the way Knossos handles the mod folder structure. Those builds change the current working directory (or root directory) to the same directory the exe file is in. Afterwards, it obviously won't be able to find any mods.

Adapting old builds to work with Knossos isn't too hard but I'm not exactly sure why you'd want that either.

@jr2: Sorry, not yet.

I'm currently stuck on an annoying bug on macOS. Whenever I launch the packaged version of Knossos, the HTML UI fails to initialize. It's somehow related to the way I package Qt with Knossos but I have no clue what the exact cause is. If anyone wants to help out (and has a macOS installation handy), feel free to speak up and I'll explain the build process for Knossos. If I can find no other solution, I might just remove Qt from the Knossos build which would mean that every macOS user would have to install Qt before using Knossos but at least that'd work.

[jr2]

I have MacOS Mojave installed via Clover on this machine, which should work the same as normal MacOS as far as I'm aware.  What exactly do you need me to do?
EDIT: I have to work a 12 hour shift the next two days and a 6 hour after that, so if I take a while getting back to you that's why.  Should be able to poke at it for a bit during that time though.

EDIT2: Wait.  Do you mean help like coding help or help like try different patches and things out and report back help?  I'm useless for coding unfortunately   (I mean... slightly better than a monkey with a typewriter I imagine? ).

[ngld]

Sorry for the late reply.

@jr2: Being able to code isn't necessary but I suppose it'll be hard to find the problem without understanding the code or being familiar with Qt on macOS.
Still, you can try the last macOS build and tell me if it works or launches with just a grey window: https://github.com/ngld/knossos/releases/download/v0.14.0-rc.1/Knossos-0.14.0-rc.1.dmg