@Dimis I already explained it, maybe I just didn't write it out well enough... it's been a busy two days, wife has a new job etc etc this was supposed to be a relaxing week coding and stuff heh...
The apps are relying upon libraries in my case which are being extracted to a target which cannot be accessed properly (localtemp). In my case I imagine it's probably PhysX, Styx, etc. Not to mention the fact DBP also dumps debug DLLs there for whatever reason, aaaand all the .fx files. When any app I developed with my previously working plugin suite is launched, I find it dumps a bunch of those plugin DLL files into a dbpdata folder in my localtemp. In conjunction with the event1000 offset 0xc0 (app failed, nul pointer), and Procmon saying the app is complaining about not having access or permissions in that exact same directory, I'd say this is exactly why my app won't launch: The app is unloading dependencies into localtemp even when I set ExternaliseDLLs off, and because of that and the last security updates (also my foolish idea to clean boot), the apps is not being allowed to run at all.
I've tried gaining access to the localtemp to fix older programs before, it's a nightmare. Windows *really* doesn't want you messing around in there anymore. I imagine now it's even more difficult.
Yes, they still fail in windowed. The only things I can get to run are the most simple, simple things. Things that don't use plugins, or 3D. But none of my other commercial software had done this. I have over 100 games on Steam, and it's only DBP having issues for me personally. Though I've read that others are having issues with things like Office and Adobe products.
See above posts. It's been confirmed that using CodeSurge, which doesn't touch the temp folder, compiles properly with no issues *unless* you set "LocalTempDir" to Yes, then you get failed to build lock_resource. That is because it's trying to build in a protected folder, that being temp.
And I'm not sure but, the behavior we're seeing from apps that dump their plugin DLL files into temp when run *may* have something to do with ExternaliseDLLs, a setting that doesn't seem to be respected and is actually omitted from the CS editor .dbpro output. 'cause, that is what the app is doing. Externalising it's DLLs to temp and trying to reference them.
I have a ton of the msvcp files, I'll go through them later to find out if I need one. But first, check this out:
"KB5039211: This update addresses an issue that affects lsass.exe. It leaks memory. This occurs during a Local Security Authority (Domain Policy) Remote Protocol (LSARPC) call."
They've realized they [BLEEPED
] up Windows Security. Memory leak? Interesting, before I installed a particular vcp redist, I was getting a BEX that would switch to appcrash when I shut off DEP. That's a buffer overflow exception.. Maybe the vcpr didn't actually fix what was causing the BEX, just bandaged it enough to stop the BEX and throw only the null. I'll post again after the update.
Now to finish my 12648430... (hex it ;])
[update]
Well the update fixed nothing, but immediately following it there was another definition update. It at least seems they know there's some kind of issue, but no telling if they'll end up fixing what they broke.
I'm going to install PureBASIC alongside DBP today and start working to get it to a state where I can fully port my engine. If I can, would you all like me to write a list of libs for PureBASIC to make DBP porting easy? I feel the most difficult things to port will be DarkPhysics, and a few of DBP's more advanced 3D functions. eg I didn't see a 3D raycast function, but then again I haven't checked out the entire guide yet. I could upload an include with my own functions to replace stuff like that, too. Would just take some time.
