avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday January 21, 2021, 6:55 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - aloishammer [ switch to compact view ]

Pages: [1]
Find And Run Robot / Re: Protocol links?
« on: January 22, 2017, 09:20 PM »
@aloishammer: Thanks for the above pointers. I had already tried some FO3 Nexus mods. However, nothing has so far enabled FO3 to play properly. The Nexus mods got FO3 to start up, the file selected loads, then crashes during load. That's on 2 of the laptops. The 3rd laptop plays FO3 without any mods ... I have no idea why, and cannot spot the differences that might be behind it. Spent hours on troubleshooting FO3. 
Jiminy Cricket.

Maybe you've already gone through all of this, but: I'm thinking back up your FO3 saved games, uninstall FO3 and every bit of related software (FOSE, etc.), and make a clean sweep of any other Fallout-related config files or the like. Voidtools' Everything is fantastic for this kind of work. Be certain to kill the actual .INI files, in case there are bad settings. In fact, be very careful about editing Gamebryo .INIs in general. 😉

Unfortunately, the Gamebryo engine does periodically cause save file corruption, even if you're not using a single mod. Corrupt save files may just cause strange behavior in the game—but they can cause a crash to desktop, too. 😝 I usually back up TES / Fallout save files once or twice a day.

That's all I can really think of. That, and check a few things, like make sure FO3 runs with Administrator privileges—it might need it; I don't know—and review any GPU driver settings you might have. If you're using an NVIDIA GPU, NVIDIA Inspector is really good for this kind of thing.

Also, like I said, try using FOSE if you haven't already, and try setting the LAA flag.

Find And Run Robot / Re: Protocol links?
« on: January 22, 2017, 04:19 PM »
However, there is hope - as @aloishammer says:
Fortunately, a lot of angry people have worked very hard at removing GFWL runtime requirements from older, unsupported titles. PCGamingWiki has a lot of details on this.
Oh, yes. The PCGW link I provided deals with specific titles and links to tools and methods for removing the GFWL dependency from each—or else provides information on a newer, re-released build. Where no solutions appear possible, the games' status is noted. I only have a handful of GFWL titles, fortunately, and the BioShock titles have just now gotten the "HD" re-release treatment, which I would hope means they have no GFWL dependencies whatever. 😉

I can't recall specifics, but I've used XLiveless (linked on PCGW) for everything but FO3, and had considerable success. In the case of FO3, bear in mind that the Embryo engine Bethesda Software keep inflicting on gamers is frequently unstable. That is, GFWL may not necessarily be what's preventing FO3 from running in some cases.

If you haven't already, I suggest installing FOSE. Whether or not you use any mods that require it—many do—I've found that it seems to make the game just a little bit more stable. I believe there are also several FOSE-dependent mods that patch out some unpleasant bugs in the executable. Nexus Mods has virtually every mod ever released for a Bethesda title, and should have these. I don't recall names—sorry. See also: the Nexus Mod Manager, which is fantastic.

Additionally, editing the binary to set the /LARGEADDRESSAWARE (LAA) linker flag is a very, very good idea. It's something FOSE can't do, I believe. One of the better tools I've found for this is creatively called "Large Address Aware." If you prefer to use the command line—maybe for automation?—EDITBIN.EXE from the Microsoft Visual Studio tools can change any of the Portable Executable (PE) header flags, including LAA.

...Visual Studio has a free-as-in-beer Community Edition, starting from VS2015. If all you want is EDITBIN, use the web installer, if you can, and perform a custom install. Turn off everything possible, other than the C++ tools selection; I don't recall the exact description, unfortunately. Alternately, I THINK that you can get it in the Microsoft Build Tools. I'm having trouble unpacking the executable to confirm.

Most of this is referenced on the PCGW page for Fallout 3. 😉

Find And Run Robot / Re: Protocol links?
« on: January 21, 2017, 05:38 PM »
I appreciate it, but I don't have and don't expect to acquire any skill in AHK scripting, so I can't maintain it on my own.
No skill needed. Save script, add paths, install autohotkey and copy script shortcut to Windows Startup folder. Then the links will be up to date on each boot.
I understand. But I'm considering long-term possibilities: the Steam manifests may change format next month or tomorrow. They might move, vanish, be renamed, split into pieces, or combined with something else. Maybe Steam will start running them through gzip to save storage and transmission costs. Those are just a few very simple examples.

I avoid becoming dependent on tools that I can't be reasonably sure will continue working in the long term—the long term being years.

Again, I gave GameSave Manager as an example; it's theoretically a very simple tool that does a very simple job (and far better than Steam's Cloud Save feature), but it was maintained by one person who had Something happen that meant he couldn't work on it for a couple years. Luckily, I happened to discover it existed after it was clear it had been abandoned. (Temporarily, but no one knew that at the time.)

Again, thanks, but it's not for me. If I can't maintain it myself—and, at present, I can't—I need to be sure that someone else can... and will. 😁

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 08:21 PM »
I'll just back out of trying to help in this thread.  I've not been cherry picking, I'm quoting the relevant part instead of a whole bit to reply to, and to be accused of such... well, let's just leave it there.
I apologize. That was overly harsh, yes.

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 06:48 PM »
I'm willing to learn PowerShell if it ever gets really mature, but, at the moment, it's just impressing me with the fact that it can be insanely buggy when you need core features to work.

Again, seemingly quite unfair.  I use it, and it, from my perspective of a daily user, is quite stable if you know what you're doing, and use the constructs as they're intended.  Many people want it to be a replacement for bash and such, and that, it's admittedly not.  So when you use it under those assumptions, yes, it might not operate in the way that you'd want it to.  Sort of like using a screwdriver to drive a nail, or a hammer for a screw.
I'm not being intentionally unfair. I'm relating my own experience, just as you did above.

...And my experience is that, when doing very little with PowerShell—with the latest WMF 5.x installed, by the way—on 7SP1 systems in good order, PowerShell [or system components it requires?] in some cases can't even connect to the Internet... which is what's evident in the link I provided. I'm not using a third-party firewall, and there are no Windows Firewall rules preventing it. (Or else Windows Firewall is completely failing to log the fact.) Also, it's the only thing failing... to connect to the Internet, or failing in any other way.

I haven't made even minor alterations to the PowerShell package providers, either; this came up while I was trying to install something from the PowerShell gallery that apparently requires NuGet 2.something.specific installed as one. I've done nothing to the PS environment as a whole, other than occasionally upgrade the revision of WMF installed, using only Microsoft's official installers.

My working theory is that perhaps something went badly wrong over the last couple years when upgrading from WMF 3.x to 4.x to 5.x, but that would be in Microsoft's hands; not mine. I have no way to test this theory, and the failures aren't generating (useful) logs in any place that I can find. It may not be resolved until I wipe and replace my clean 7SP1 installs with clean 10 ones.

Certainly, the only information I can find amounts to "It must be a proxy failure." I don't use one. Nothing is configured to use one. Nothing has gotten misconfigured by a "stray PAC script" to use one.

Finally, I'm not somehow misusing PowerShell in some bash-drunken fashion. I already explained that I'm having trouble getting a three-line script to work reliably. Not "at all"; sometimes, it fails on login. Mostly, it doesn't. There's no reason I can find that it should mostly work, but not always.

If you're going to make assumptions, please make them on the basis that I've administrated both Windows and UNIX systems for about twenty years, both professionally and personally. If I meant to say that I hate Windows, I'd say that. I haven't even said that I hate PowerShell.

Please also don't cherry-pick what I'm saying. I've been writing long-form responses on the assumption you'll grant me the courtesy of reading and replying to them in their entirety.

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 06:20 PM »
That is a link to the API.  It also is not restricted to those that use steamworks, indeed, I already have an API key for it.  It gives a lot of information that would be readily obtainable from their queries- just not the users local information, i.e. the groups or what's installed on their computer.  So your assessment would seem a bit unfair.
Er... what I said is that Steamworks is an API for the Steam service, but not for the Steam client.

IoW, you can use Steamworks to get information about one's Steam account, but that's entirely different from one's local install of the Steam client.

(I also said, I thought, that the access they provide to developers is reputed to be quite good.)

Giving a Steamworks partner programmatic access to local installations of either Steam or games is, so far as I know, completely unnecessary for anything compiled against the Steamworks APIs; and it might even be dangerous in terms of assisting someone in either breaking the Steamworks DRM or in assisting multiplayer cheating. At any rate, if the decision were up to me, I most likely wouldn't risk it.

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 06:08 PM »
Has anyone come up with a clever way to maintain cloned links?
I had this in mind when I wrote the small script above. Easy to add a few lines to also remove .urls to games that have been deinstalled. Put a link to the script in Windows autostart and the shortcuts will update on each boot. To update more often add some lines with a timer and keep it running in the background. Or use Task Scheduler to run it at some interval.

Code: Autohotkey [Select]
  1.     ;SteamLinker
  2.     ;Creates one .url link file for each currently installed steam game
  3.     ;Setup: add full path to steam root folder and an output folder to save the .url files
  4.     ;For example C:\steam\  and C:\folder
  5.     ;Warning: all old files in outdir with "[ste].url" in name will be removed when script runs
  6.     steamdir =
  7.     outdir =
  8.     If !FileExist(steamdir) or !FileExist(outdir)
  9.      exitapp
  10.     Loop, files, %outdir%\*[ste].url
  11.     Loop, files, %steamdir%\steamapps\*.acf
  12.     {
  13.     FileReadLine, idline, %A_LoopFileFullPath% , 3
  14.     FileReadLine, nameline, %A_LoopFileFullPath% , 5
  15.     StringSplit, id, idline, "
  16.    StringSplit, name, nameline, "
  17.     IniWrite, steam://rungameid/%id4%, %outdir%\%name4% [ste].url, InternetShortcut, URL
  18.     }
I appreciate it, but I don't have and don't expect to acquire any skill in AHK scripting, so I can't maintain it on my own.

I find the sophistication and reach of Windows' scripting and automation to be much below the level of a UNIX, but I have hopes that Microsoft will consider backporting both its newer terminal code and the new bash-centric CLI facilities... or at least the new terminal code. (Which probably still isn't Unicode-safe, and likely lacks a lot of other crucial things.) (The new CLI facilities alone have a great long way to go.) I personally don't need them in Windows 7... much longer... but I spend any amount of time on machines I don't own and don't even have full administrative access to. 😉

I'm willing to learn PowerShell if it ever gets really mature, but, at the moment, it's just impressing me with the fact that it can be insanely buggy when you need core features to work.

I can't depend on any other facility to exist even on relatively recent Windows installations, and I certainly can't depend that I'll always be able to install it. The rest of my skills are tied up in scripting and automating on—begging your pardon—OSes I don't install solely to play games and occasionally update device firmware on.

...Also, even if Microsoft bought AHK and shipped it free in every box of Windows 10 Cereal, Windows still displays some seriously bizarre behavior if either there's no active desktop session at all, or if some obscure thing is preventing one's batch file, random Windows Script Host dialect, PowerShell script, or whatever from interacting with one. $Path and other environment variables seem to get set entirely at random (if at all). And sometimes a well-written script will fail for some other reason entirely, which is happening right now—sometimes—with a trivial script that I really need to work every time I log on. (Resets my sound card. PowerShell; about three lines and an external library.)

Sorry, I know that that's probably over-explained. In short, unless you're offering to create and maintain a reasonably stand-alone utility that I don't have to think about... ? 😁

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 04:56 PM »
Is there even a way to access the files that steam has installed in an API?

Just checked the steam API, and there's a way to see the games that a user owns, but not the games that they have installed.
A formal or even unofficial API? I doubt it. Valve tend to be a tad jealous of their software and their service both; they seem to do a good job of providing necessary APIs for game developers selling through the storefront and managing ancillary functions (cloud saves, achievements, etc.) for the games themselves, but nothing beyond what's strictly necessary.

It took more than long enough for Valve to care about even allowing "customers" (end users) to replace Steam client-side game icons or grid-view game banners with custom resources, and what's there is surprisingly primitive. Based on that sort of evidence, I wouldn't bet that there's a single client API call available to anything... outside of normal Windows desktop integration, at least. There is this, however.

I'm reasonably certain that the official Steamworks API is solely dedicated to interactions with the Steam service itself, without reading any of it.

At any rate, when they're not working to enforce DRM requirements or prevent multiplayer cheating, Valve seem to greatly prefer open standards and simplicity for the Steam client and for items like the Source Engine. By way of example: there's no official soundtrack for Left 4 Dead 2 (I know, because I wanted to get it), but it's entirely possible to grab the bare WAV (and I think Ogg Vorbis?) files out of the install directory.

As with the .ACF manifests @Nod5 mentioned earlier, there's considerable use of semi-structured plaintext, JSON, XML, and other trivial formats that would likely be very simple to use directly without significant conversion, let alone reverse-engineering. There may be times that the Steam client has a different internal state than is reflected in external files.

For the games themselves? Valve seem to be aiming for the greatest possible compatibility with the lowest possible effort. So far as I know, Steam doesn't even provide something like packaging system primitives, even for its own internal use. Games are still installed as-is, with whatever binary blob(s) the developers decide to publish... which is how you end up with Steam games that use or need additional third-party DRM or multiplayer systems or whatever.

If you'd like to start poking around the Steam client internals or just the games being installed, I think that there's very little preventing you from doing it, other than whatever EULAs you may have agreed to. 😉

End note: I haven't looked, but it's quite possible that Steam does integrate at least in part with the Windows Games Explorer. HowToGeek does note that Microsoft never added Steam or any other major "games provider" (Microsoft's term) to this facility, but my interpretation is that Valve may have at some point added integration, or perhaps even wrote and published—but never activated—the necessary code in the client. It may even still be there. I have no idea what the Windows APIs for this looked like, but they were still there as of at least Windows 8.x, and they would have had to include some basic information about installed games: a name; an icon; some way to execute the game (or, more likely, STEAM.EXE), and I think a couple of other details. If this still exists, you might be able to tap into it. You may have to go through the Wayback Machine to get your hands on API documentation, though.

From time to time, you'll see "Steam" games appear in this folder regardless, on account of they were written against Games for Windows Dead. The service is defunct; however, it does have a very slight upside in that every(?) game binary still hitched to the decaying corpse should appear in the special "Games" folder aboard every Windows release that still has that functionality.

...Fortunately, a lot of angry people have worked very hard at removing GFWL runtime requirements from older, unsupported titles. PCGamingWiki has a lot of details on this.

Alternately, you could see what's available through Windows Store APIs. I suspect Valve probably took that a lot more seriously than they did Microsoft's older gaming efforts. I'm still taking a wait-and-see attitude on upgrading from 7SP1, though, so I have no real idea how widespread support is. Valve may or may not have decided to make Steam or Steam-installed games at least appear in Windows Store facilities.

Find And Run Robot / Re: Protocol links?
« on: January 20, 2017, 03:04 PM »
This app already does that work, though.
Yup, seems to work fine. Since the generated shortcuts call STEAM.EXE instead of a game binary, it also takes care of any questions I might have had about preserving (finding?) custom launch options or anything else that Steam already manages.

My only remaining question was about creating or deleting shortcuts as games are bought / refunded / installed / uninstalled. Since no one seems to have done that sort of work, I'll look into finding a way to automate it myself.

(Well, that, and it would be great if someone had devised a way to automate finding better (256x256px min) Windows icons for Steam games... a lot of games... but I'm a perfectionist. That's a whole separate question and a whole other realm of complexity. Truth be told, I'm more worried about whether work on Gamesave Manager 4.x ever finishes.)

Find And Run Robot / Re: Protocol links?
« on: January 15, 2017, 08:36 PM »
You'll have to use the program to create the links, and put them into the folder.  Then, update the search folders setting to point to whatever folder you store the resulting links in.  It's not a FARR plugin, but rather something that creates true links out of steam links.  Then you can put them anywhere, and they act as normal links, i.e. findable by FARR.
OH! Okay, so the .dcupdate file is just a little extra to help keep the program up to date, and it doesn't serve any other function?

Has anyone come up with a clever way to maintain cloned links? Delete and create them as Steam games are added and removed? I've been looking at the possibility of doing this with Task Scheduler, and it looks a lot like I'd have to learn PowerShell scripting or else buy some sort of tool to monitor directories for changes...

Find And Run Robot / Re: Protocol links?
« on: January 15, 2017, 06:12 PM »
You might use the Steam URL Converter, and place those URLs in a folder, and add that folder to the FARR search folder list.
Perhaps I'm doing something wrong, but the plugin doesn't seem to work. It's not listed in FARR2's interface; although it does appear in DCUpdater. When I type a sample search ("left4") into FARR2, I do see the Left 4 Dead 2 binary as the first search result, but it's just a bare EXE. It doesn't have the actual link title ("Left 4 Dead 2"), and none of the custom launch options I've set in Steam are being passed, so far as I can tell.

Find And Run Robot / Re: Protocol links?
« on: January 15, 2017, 05:56 PM »
You might use the Steam URL Converter, and place those URLs in a folder, and add that folder to the FARR search folder list.
That was fast. Thanks! I was sure someone else must have tried to do this, but board searches and Google custom searches weren't finding any topics, somehow.

Find And Run Robot / Protocol links?
« on: January 15, 2017, 05:45 PM »
Can FARR2 support—or does it support—opening special "protocol" links?

In addition to LNK files with http:// or https:// shortcuts, many systems have various other protocols registered. Steam, for instance, as in the game platform. In its current configuration, I can't get FARR2 to match Steam links, and I'm not sure how to change that. Including a screenshot of a sample Steam shortcut to illustrate the kind of LNK I'm trying to get FARR2 to launch.

EDIT: Sorry, this is actually a .URL file. I have .URL files included in searches, and I have specific paths containing Steam URL shortcuts ( %MYSTARTMENU%, %COMMONSTARTMENU% ) switched on. I'm not sure what else (if anything) to add.


ProcessTamer / Enhancement request: support NT 6 idle priority
« on: April 16, 2011, 02:48 AM »
Windows >= NT 6.0 has a process priority called "idle", which ProcessTamer does not appear to support. Will this be added at some point?


One more security note: everyone in the wider security community has "binary planting" on their minds just now.  I can't even begin to guess where FARR2 might need/want changes, but this new research seems extremely pertinent to FARR2, whose entire purpose is to create new processes...


welcome aloishammer  :up:

i'm afraid i'm totally ignorant about ASLR and Perma-DEP.  could you point me to something gentle i could read and maybe elaborate a little on why you think this would be useful?
I don't know what you'd consider "gentle".  Microsoft seems to have gone out of their way to confuse anyone attempting to use either CPU-based or compiler-based software protection techniques.  >:(

There's an MSDN article here that explains some of the code protection techniques MSVC offers.  Unfortunately, Microsoft can't decide whether it's Address Space Layout Randomization (ASLR) or "dynamic base" or "image randomization".  Also, while they differentiate between the NX execute-protection CPU instruction and "SafeSEH" in the article, Windows does not.  Windows offers "Data Execution Prevention", occasionally calls it NX (as in the NT6 bootloader), and combines both NX and "SafeSEH" for anything selected for protection with "DEP".

Wikipedia may actually be a considerably better reference:

The extremely short version I can offer: the NX instruction is used to mark memory ranges as non-executable; if someone successfully inserts malicious instructions into an NX-marked data (non-code) area and successfully sets the instruction pointer there, the CPU should throw an exception and refuse to execute the non-code.

SafeSEH is next to worthless, but very good at breaking applications that weren't compiled for it.  This is why "DEP" was introduced in WinXPSP2, but Win7 still doesn't enable it by default, and I assume 7SP1 won't, either.

ASLR, depending on exact implementation (Windows' is partial for performance reasons), can place various code *and* data into totally random memory address ranges.  This way, anyone successfully injecting malicious code into the in-RAM, executing image of your app will either be unable to reliably predict where the malicious code went, and thus be unable to set the instruction pointer to it, or will have to work considerably harder to locate and execute it.

These are the two big ones: the MSDN article mentions one or two other code protection techniques (mostly free just by enabling switches in MSVC), but most focus ends up on "DEP", NX, ASLR.

Major caveat: ASLR on Win32 gives you only a 3.2-3.5GB address space to search, so it's very close to not worth doing.  This is part of the reason I'm asking for a native Win64 build.

Wrap-up: assuming you're using MSVC, and at least 2005SP1, or that you can/could build with MSVC Express (free), NX, ASLR, and the other techniques mentioned in the MSDN article are effectively free; it should be a matter of switching on flags when building your project.

Postscript: From my testing, I don't think you'd need any recoding.  I've been experimenting with Microsoft's EMET 2.0 release: FARR2 and DCU are reported as running with full EMET-enforced protections and display no abnormalities.

Find And Run Robot / Double Request: ASLR/DEP and amd64
« on: August 14, 2010, 12:55 PM »
Would you consider looking at ASLR and DEP for FARR (and DCU)?

Would you consider a native amd64 build for those of us running amd64 Windows?  (That's quite a lot of people, now.)  (Also, ASLR is even more easily bypassed in a mere 4GB (or really 3.2GB-or-so) address space.)

I've tested adding perma-DEP and ASLR (/NXCOMPAT and /DYNAMICBASE, respectively) to the DCU and FARR2 executables and support DLLs, with MSVC10-Express' toolchain, and FARR2's speed has dropped drastically.  I think this is because it wasn't compiled properly for ASLR to start, as opposed to something that would happen to FARR2 with ASLR added at link (compile?) time originally.

Perma-DEP by itself doesn't appear to affect performance, nor should it.

Thanks for such a great and useful tool!

Pages: [1]