If you encounter an unknown parameter -- just ignore it



  • This is not intended as Microsoft bashing.  I just thought it was interesting in a WTF sort of way.

    I've been reading about of a piece of malware called TDL4.   What caught my attention was the way that the author figured out how to bypass the requirement that all drivers must be signed when running 64 bit Windows.   A fairly simple method that the Microsoft programmers apparently never thought of:  just pass bogus parameters to various components of Windows.

    TDL4 changes a flag in the Boot Configuration Data so that Winload.exe thinks you are booting in WindowsPE mode, which doesn't have the driver signing requirement.  Normally, Winload would then load the Windows kernel with a paramenter of <font face="courier new,courier">/MININT</font> to indicate that we are in WindowsPE mode.  However, TDL4 patches that so it passes the paramenter <font face="courier new,courier">IN/MINT</font> instead, which the kernel doesn't recognize and so the lernel just loads normally, not in WindowPE mode. Congratulations, you just loaded an unsigned driver

    Microsoft patched the method described above and added other digital signature checks.  If any module fails the check it returns a code of C0000428 (STATUS_INVALID_IMAGE_HASH) and stops the boot process with an error message.  So, the author patched that part too, so that it now returns an error code of 0000C428 which is a non-existant error code.  Winload doesn't recognize that error code and so it just marches on and loads the unsigned driver.

    The malware locates a DLL that it wants to replace by checking for an export directory size of 0xFA.  Microsoft patched the DLL in question (kdcomm.dll) so that it now has an export directory size of 0x110.   So the malware author modified the program to . . . . wait for it . . . . . look for both 0xFA and 0x110.   Wow.  I didn't see that one coming from a mile away

     



  • @El_Heffe said:

    Microsoft patched the method described above and added other digital signature checks.  If any module fails the check it returns a code of C0000428 (STATUS_INVALID_IMAGE_HASH) and stops the boot process with an error message.  So, the author patched that part too, so that it now returns an error code of 0000C428 which is a non-existant [b]success[/b] code.  Winload [b]sees that no error occurred[/b] and so it just marches on and loads the unsigned driver.

    FTFY.



  • @immibis said:

    So, the author patched that part too, so that it now returns an error code of 0000C428 which is a non-existant success code.  Winload sees that no error occurred and so it just marches on and loads the unsigned driver.
    Why not just patch it to return success, then? For the lulz?



  • @El_Heffe said:

    The malware locates a DLL that it wants to replace by checking for an export directory size of 0xFA.  Microsoft patched the DLL in question (kdcomm.dll) so that it now has an export directory size of 0x110.   So the malware author modified the program to . . . . wait for it . . . . . look for both 0xFA and 0x110.   Wow.  I didn't see that one coming from a mile away

    Sounds like Nintendo. They issued a few "anti-piracy" updates that specifically blocked certain title IDs from installing. The hackers fixed it by, who'd have guessed, changing their software's title ID.



  • If the virus has access to patch system DLLs, the game's already lost anyway. As Raymond Chen would put it, it's on the wrong side of the airtight hatch.

    The real solution here is for people to either stop running as Admin all the time, or stop using Windows XP. There's only so much Microsoft can do to "fix" an OS with a flawed security model, without also breaking it entirely. 2014 can't come soon enough...



  •  If you do not know that flag

              you must skip it

    If the error code's unknown

              you must skip it

    If a malware comes along

             you  must skip it

    If the DLL is bad

              you must skip it

    Now skip it -- skip it good

    Try to detect it -- skip it good

    It's not to late -- to skip it

    I say skip it -- skip it good

     



  • @blakeyrat said:

    The real solution here is for people to either stop running as Admin all the time, or stop using Windows XP. There's only so much Microsoft can do to "fix" an OS with a flawed security model, without also breaking it entirely. 2014 can't come soon enough...
    ‮ sdrawno atsiV morf ylno ereht si tnemeriuqer gningis revird ecniS‬(and only in x64 versions of the OS), it's pretty obvious whom this trojan is targeting (also, last time I read about it, the bootloader stuff it does would make XP/2003 x64 unbootable).


  • BINNED

    What does that have to do with unknown parameters??

    Instead of using "IN/MINT" and 0x0000C428 they could have just gone with "\0" and whatever stands for STATUS_SUCCESS. How do you suggest to detect that now??

     

    +1 on the "other side of the airtight hatchway"



  • You use a CAPTCHA, of course.



  • @ender said:

    ‮ sdrawno atsiV morf ylno ereht si tnemeriuqer gningis revird ecniS‬(and only in x64 versions of the OS), it's pretty obvious whom this trojan is targeting (also, last time I read about it, the bootloader stuff it does would make XP/2003 x64 unbootable).

    Windows XP x64 also required signed drivers.



  • @Kyanar said:

    Windows XP x64 also required signed drivers.
    Nope. The sound card I used at the time (M-Audio Revolution 5.1) did not have signed drivers, but they worked nevertheless.



  • @blakeyrat said:

    The real solution here is for people to either stop running as Admin all the time, or stop using Windows XP.

    I understood from the second linked article that it detects the OS and fails the installation if it's XP. Also, if it's on Vista/7 and fails privilege escalation, it pops up a dialog box asking the user for admin access. I'd wager that a fair proportion of targets will just hit "OK" anyway - another Raymond Chen truism is that the general response to a dialog box is "Do whatever I think will make the dialog box go away".



  • @immibis said:

    @El_Heffe said:

    Microsoft patched the method described above and added other digital signature checks.  If any module fails the check it returns a code of C0000428 (STATUS_INVALID_IMAGE_HASH) and stops the boot process with an error message.  So, the author patched that part too, so that it now returns an error code of 0000C428 which is a non-existant success code.  Winload sees that no error occurred and so it just marches on and loads the unsigned driver.

    FTFY.

    I think you're missing the point here.  The key word is not "success" or "failure".  The key word is "non-existant". 

    Program A sends a status code or parameter that doesn't exist to Program B.  If you wrote both programs, why would you have one send a non-existant code to the other?   Shouldn't Program B say "Hey wait a minute, I don't recognize that code, there must be something wrong".

     



  • I remember reading that many "bugs" had to be reintroduced into the newer implementations of various Windows components, such as ignoring invalid/nonexistant arguments and so on, because older software had bugs that were unnoticeable on the older implementation and said software would not run if more stringent error checking was implemented.



  • @El_Heffe said:

    Program A sends a status code or parameter that doesn't exist to Program B.  If you wrote both programs, why would you have one send a non-existant code to the other?   Shouldn't Program B say "Hey wait a minute, I don't recognize that code, there must be something wrong".

    In the general case, no. Otherwise when you add new messages to program A, any systems with an older version of B will break.

    In this particular case, though, both programs are a part of the core of the OS and should always be in sync. So I agree with you here.



  • @Scarlet Manuka said:

    @El_Heffe said:
    Program A sends a status code or parameter that doesn't exist to Program B.  If you wrote both programs, why would you have one send a non-existant code to the other?   Shouldn't Program B say "Hey wait a minute, I don't recognize that code, there must be something wrong".
    In the general case, no. Otherwise when you add new messages to program A, any systems with an older version of B will break.

    In this particular case, though, both programs are a part of the core of the OS and should always be in sync. So I agree with you here.

     

    So this is wrong? (pseudo-C)

    int result = PerformAnotherOperation();
    if(IS_FAILURE_CODE(result))
    {
        PrintErrorMessage(result);
        /* abort whatever this is trying to do */;
    }

    You're saying it should actually be

    int result = PerformAnotherOperation();
    if(result == ERROR_INVALID_FUNCTION || result == ERROR_FILE_NOT_FOUND || result == ERROR_PATH_NOT_FOUND
      || result == ERROR_TOO_MANY_OPEN_FILES || result == ERROR_ACCESS_DENIED || result == ERROR_NOT_ENOUGH_MEMORY
      || result == ERROR_BAD_ENVIRONMENT || result == ERROR_BAD_FORMAT || result == ERROR_INVALID_BLOCK
     /* snip 1000 more lines like that. these are win32 error codes and not HRESULTs, but who cares */
    {
    PrintErrorMessage(result);
    /* abort whatever this is trying to do */;
    }
    else if(result == ERROR_SUCCESS)
    {
    }
    else
    {
    TellUserTheirComputerIsInfectedWithAVirus();
    /* abort */;
    }

    And then when someone adds a new error code to Windows, they have to change it in 5000 different places - or they forget to (or don't know they have to) and then Windows starts telling people their computers have viruses.

    And it doesn't actually fix the cause of the problem. The virus could just as well have written ERROR_SUCCESS instead.



  • @Scarlet Manuka said:


    You're saying it should actually be

     

    int result = PerformAnotherOperation();
    if(result == ERROR_INVALID_FUNCTION || result == ERROR_FILE_NOT_FOUND || result == ERROR_PATH_NOT_FOUND
      || result == ERROR_TOO_MANY_OPEN_FILES || result == ERROR_ACCESS_DENIED || result == ERROR_NOT_ENOUGH_MEMORY
      || result == ERROR_BAD_ENVIRONMENT || result == ERROR_BAD_FORMAT || result == ERROR_INVALID_BLOCK
     /* snip 1000 more lines like that. these are win32 error codes and not HRESULTs, but who cares */
    {
    PrintErrorMessage(result);
    /* abort whatever this is trying to do */;

    No. You use the code

     

    if(!IS_SUCCESS_CODE(result))
    {
        abort();
    }

     

    This way you only succeed on the one value you want, and don't care whatever nonsense is generated.  People really need to learn how to avoid "not" requirements (as in, "the widget shall not freem if condition A"  should be "the widget shall freem only if condition B").



  •  @blakeyrat said:

    If the virus has access to patch system DLLs, the game's already lost anyway. As Raymond Chen would put it, it's on the wrong side of the airtight hatch.

    The real solution here is for people to either stop running as Admin all the time, or stop using Windows XP. There's only so much Microsoft can do to "fix" an OS with a flawed security model, without also breaking it entirely. 2014 can't come soon enough...

    Running as admin is perfectly safe when you know what you're doing and have a proper firewall installed.  I haven't had a malware infection in 7 years, running as admin in XP, Vista, and now 7.

     



  • @Master Chief said:

    Running as admin is perfectly safe when you know what you're doing and have a proper firewall installed.  I haven't had a malware infection in 7 years, running as admin in XP, Vista, and now 7.
     

    I've had exactly 1.

    Since I started doing stuff with computers.



  • @dhromed said:

    @Master Chief said:

    Running as admin is perfectly safe when you know what you're doing and have a proper firewall installed.  I haven't had a malware infection in 7 years, running as admin in XP, Vista, and now 7.
     

    I've had exactly 1.

    Since I started doing stuff with computers.

    I've never made a claim on my home insurance, but it's still fucking stupid to own a home uninsured.

    I TRUST YOU CAN APPLY THIS ANALOGY TO YOUR PARTICULAR SITUATION RE: USING ADMINISTRATIVE ACCOUNTS IN WINDOWS.



  • @blakeyrat said:

    I TRUST YOU CAN APPLY THIS ANALOGY TO YOUR PARTICULAR SITUATION RE: USING ADMINISTRATIVE ACCOUNTS IN WINDOWS.

    I did install a virus scanner after that one event :D



  • @Master Chief said:

    @blakeyrat said:
    If the virus has access to patch system DLLs, the game's already lost anyway. As Raymond Chen would put it, it's on the wrong side of the airtight hatch.

    The real solution here is for people to either stop running as Admin all the time, or stop using Windows XP. There's only so much Microsoft can do to "fix" an OS with a flawed security model, without also breaking it entirely. 2014 can't come soon enough...

    Running as admin is perfectly safe when you know what you're doing and have a proper firewall installed.  I haven't had a malware infection in 7 years, running as admin in XP, Vista, and now 7.
     

    DOS 3 thru 6

    Windows 3.0 thru 7

    Always running as admin (in those OSes that have admin)

    0 Viruses

    Not running as Administrator is OK if you can make it work.  Unfortunately, many retarded programmers continue to create software that does things requiring admin rights.  When I first tried to install my favorite text editor in Windows 7 I couldn't enter the program's serial number because it was trying to write to a protected part of the registry.  I had to go in and manually change the persmisisons for that particular registry key.  This shit still happens way too often.

     

     

     



  • Agreed! I don't think programs should be using the registry at all really. It makes portability a pain, allows for issues such as that. If installed to program files, use %appdata%, otherwise a directory local to the exe.



  • @El_Heffe said:

    This shit still happens way too often.

    That's because people never report bugs if they can just work around them by running as Admin. Then once you're running as Admin for one program, you don't even see the problem occur in a bunch of others. You've created a nice little self-fulfilling prophecy powered by your own high tolerance of shitty software. And this is why the world is full of SO MUCH SHITTY SOFTWARE. Nobody gives a fuck. The developer didn't give enough of a fuck to read-up on how security on NT-based OSes works. The user didn't give enough of a fuck to tell the developer to fix his shit. Oh, and since you have a serial number, you've actually PAID these guys for their not-giving-a-fuck.

    Improve the world: GIVE A FUCK.

    @nexekho said:

    Agreed! I don't think programs should be using the registry at all really. It makes portability a pain, allows for issues such as that. If installed to program files, use %appdata%, otherwise a directory local to the exe.

    Please, PLEASE GOD, tell me you're trolling.



  • Please, PLEASE GOD, tell me you're trolling.

    Where exactly do you think a program should keep its settings? It should be ideally outside of the documents/etc. folders like a LOT of games engines seem to (UT3 even storing game cache and stuff in there, just no, no, don't do that) but somewhere that is user-specific. %appdata% seems like a decent choice for this. And if the program isn't in program files, it can likely assume it is a portable install or that it at least has write access to its own directory, also acting as a fallback for non-Windows platforms.

    Blender gives you a choice, in fact, now that I think of it, with %appdata% as the default, which is probably the best solution of all.



  • @blakeyrat said:

    The developer didn't give enough of a fuck to read-up on how security on NT-based OSes works. The user didn't give enough of a fuck to tell the developer to fix his shit.
    You have often ranted about open source software and how they ignore bug reports.  Well guess what, commercial software ISN'T ANY FUCKING BETTER.   Want to submit a bug report?   Lots of luck figuring out how or where to submit it.  For example, the text editor that I mentioned.  I just spent some time on their website and the only method I can find for submitting a bug report is to post it in one of their forums.  I have done this with other programs and the result has been exactly the same as writing the bug on a piece of paper and then throwing it in the garbage.  I do give a fuck, but I'm tired of playing the game.

     



  • @nexekho said:

    Where exactly do you think a program should keep its settings?

    In the Registry, usually. Otherwise, you're basically pissing and shitting over most of Windows' Active Directory features, and corporate IT users will hate you and burn you in effigy.

    @nexekho said:

    It should be ideally outside of the documents/etc. folders like a LOT of games engines seem to (UT3 even storing game cache and stuff in there, just no, no, don't do that) but somewhere that is user-specific.

    UT3 is wrong here. Anything a game engine does is, in general, the wrong thing to do.

    @nexekho said:

    %appdata% seems like a decent choice for this.

    It's a decent choice, but you have to keep in mind that settings stored in %appdata% are not subject to AD permissions (well... generally), and cannot be modified by AD Group Policies. This is why, for example, Firefox has such low corporate adoption.

    If your setting is one you think nobody will ever need to set a Group Policy on, then you could put it in there. As an example, this is where Live Messenger keeps things like custom smilies, and IM logs-- this is the correct choice because while you want the option to turn on and off smilies or logging via Group Policy, it would be silly to store the actual log files and smilies themselves in the Registry.

    Obviously local application data, like your caches, should go in... %localappdata% or whatever the DOS name for local application data is. Do not put your caches in the regular %appdata%, because you'll end up with Roaming Profiles transferring 2 gigabytes of web cache every time someone logs in and, again, the poor corporate IT guy is going to be burning you in effigy.

    Oh, and if you're writing application software for Windows and you didn't know any of this: PLEASE SHOOT YOURSELF NOW! (Or, more productively, read-up on how Group Policy works, and the NT security model.)

    @nexekho said:

    And if the program isn't in program files, it can likely assume it is a portable install or that it at least has write access to its own directory, also acting as a fallback for non-Windows platforms.

    I'd agree with this.

    Well, except the "fallback for non-Windows" part-- you're either writing software for Windows or you're not. If you are, do it fucking correctly! All this means, use Windows' built-in features and conventions, not some cross-platform abortion! Just because other platforms don't have great corporate network features like Group Policy doesn't mean you should ignore the feature when your software is on Windows.

    If you're going to port the software to Windows, you have to actually port the software to Windows! You can't just shit out something that barely runs (like, say, Pidgin) and declare you're done.

    @nexekho said:

    Blender gives you a choice, in fact, now that I think of it, with %appdata% as the default, which is probably the best solution of all.

    Blender is user-hostile in many ways. I'm sure nobody would notice one more tiny bit of user-hostility.



  • @El_Heffe said:

    You have often ranted about open source software and how they ignore bug reports.  Well guess what, commercial software ISN'T ANY FUCKING BETTER.   Want to submit a bug report?   Lots of luck figuring out how or where to submit it.  For example, the text editor that I mentioned.  I just spent some time on their website and the only method I can find for submitting a bug report is to post it in one of their forums.  I have done this with other programs and the result has been exactly the same as writing the bug on a piece of paper and then throwing it in the garbage.  I do give a fuck, but I'm tired of playing the game.

    You're right... unfortunately, too many software companies aren't interested in feedback or improving their products.

    But the least you could do is not give them money. Someone has to make a stand.



  • Oh, and if you're writing application software for Windows and you didn't know any of this: PLEASE SHOOT YOURSELF NOW! (Or, more productively, read-up on how Group Policy works, and the NT security model.)

    I didn't know much of that, thanks for outlining that. Most of what I write is small tools for performing specific tasks or work on small games. (which aren't really subject to sync, etc.)



  • @nexekho said:

    Oh, and if you're writing application software for Windows and you didn't know any of this: PLEASE SHOOT YOURSELF NOW! (Or, more productively, read-up on how Group Policy works, and the NT security model.)

    I didn't know much of that, thanks for outlining that. Most of what I write is small tools for performing specific tasks or work on small games. (which aren't really subject to sync, etc.)

    You should still do it correctly.

    Take the game example: let's see a principal wants to install your game on their network, but the kids are having fights over the high score lists. He asks their network administrator to either reset the list on all the computers, or to disable the recording of high scores altogether. If your program used the Registry correctly, the network administrator can do this in seconds-- if not, he's probably going to end up deploying some shitty JScript that runs on login that attempts to find and erase your high score file, which is a hell of a lot more work for him, more bug prone, and doesn't even meet the principal's requirements in the first place. (As the game will still store scores until the user logs out.)

    This is an actual use-case I've had to write an actual shitty JScript for, BTW. Because the game's author was a dick and just didn't give a fuck. (IIRC, that was also the game that showed swear messages in the error dialogs when it crashed, like "this program is fucked"... other than the error dialog it was perfectly kid-friendly. Stupid developer.)

    Basically, it's not your job as a developer to decide what the network administrator may or may not do with your software. Your job is to make your software compatible with his tools, so he can do his job.

    Think of it this way: when you're designing a programing language, you don't design it to dictate what type of software it can write, you design it to be as powerful as possible so it can be used to write software you can't even imagine yet. Your program should be the same way.

    Plus, since all of the API and frameworks assume you give a fuck, it's actually a lot easier to write software correctly than incorrectly.


  • ♿ (Parody)

    @blakeyrat said:

    Oh, and if you're writing application software for Windows and you didn't know any of this: PLEASE SHOOT YOURSELF NOW!

    FTFY



  • Could you provide some references on how to do it correctly, because I want learn how to do it correctly.



  • @delta534 said:

    Could you provide some references on how to do it correctly, because I want learn how to do it correctly.

    That's a very good question, and frankly, I've been Googling around and I haven't found anything that great. (Other than of course Group Policy's own documentation on MSDN, which spends reams talking about technical minutiae but never actually says "here's when to use it and why".

    What's really depressing me is seeing the sheer number of developers completely ignorant of how it works-- every single "when should I use the Registry" post on StackOverflow is busting with answers that amount to "never, unless you have to" and not a single mention of Group Policy or Active Directory. The groupthink here is totally wrong, but considering how crappy Microsoft's own documentation is on the subject, I can't really blame them for it.

    Raymond Chen lays out why you shouldn't use .ini or XML configuration files, but barely broaches the subject of Group Policy (although he does mention it in his last bulletpoint of the top list. You should definitely read that thread and all of Raymond's replies.

    I learned most of this stuff by actually (gasp) being an network administrator for awhile, so kind of trial by fire. I'd be happy to answer any questions on the topic... and I'll keep looking for a good overview (from Microsoft hopefully) on where Windows apps should store settings.



  • Related to setting, but where should a game store things like mods and game saves or a program store plugins.



  • @delta534 said:

    Related to setting, but where should a game store things like mods and game saves or a program store plugins.

    IMO:

    Game mods should go in the user's home folder. I would recommend: Username\[game]\Mods. This is assuming your program doesn't have a GUI to add/remove mods on its own; if it does, they should go in %appdata% to prevent cluttering up the user's home folder.

    Saved games should go in: Username\Saved Games\[Game]\Saves. The Saved Games folder is a special folder in Vista and Windows 7, so on those platforms make sure you ask the OS what path to use for it! Also note: if your game is on Steam, make sure you add Steam Cloud support as well! This keeps the saves convenient so the user can move them to another machine.

    What not to do: WOW puts mods in a folder in its own program folder. This means that if you have more than one WOW player on the same computer, they are forced to share the same set of mods. To "fix" this, WOW actually added in an interface for each user on the system to individually turn off mods they don't like. Blizzard could have saved a whole lot of their own time and effort by just putting mods in the user profile in the first place.

    Plugins: If your program has an interface to add/remove plugins, I'd recommend putting them in %appdata%. (Shockingly, Firefox got this one right.) If your program has no interface to add/remove plugins, I'd follow the advice I laid out above for mods.

    EDIT: -ed the hell out of this, if you're coming from email please re-read.


  • Garbage Person

     @delta534 said:

    Could you provide some references on how to do it correctly, because I want learn how to do it correctly.
    I don't know about any good references, but I came up through ActiveDirectory administration and can give you the Cliff's Notes.

     

    Settings in the registry. Profile data in appdata. Caches in localappdata. Userdata (savegames, screenshots, whatever) in Documents. Static data in the install directory.

     

    The registry both machine-specific and user-specific and is centrally manageable (through a mechanism called Group Policy), and does not follow the user around from computer to computer (but the same settings will always be applied by Group Policy for a given user/machine pairing)

    AppData is user-specific and not manageable, so don't store any configuration here, and does follow the user from computer to computer. This should be kept as small as possible - so things like user profiles might be a good fit.

    Localappdata is user-specific and not manageable and does not follow the user from computer to computer. This makes it a good place for big data that isn't necessary to actually use the software - generated cache data, for instance.

    Documents is user-specific and not manageable. It follows the user from computer to computer. This is a good alternative to AppData for things that the user might conceivably want to get at (save games, screenshots, etc.)

    The install directory is machine-specific and does not move from computer to computer.

     

    Oftentimes, AppData, Documents, and the Install Directory (and indeed, many other directories) are actually not present on the local machine, but redirected to UNC paths or mounted drive letters. Make sure your fucking software works with network directories. This may require signed code in the case of the install directory. Related, always make sure to access these through the API methods that get you their locations - because only through those methods can you actually get at redirected paths like that.

     

    Regarding Group Policy and the registry. The registry, at least as far as app developers are concerned, boils down to two hives: HKEY_LOCAL_MACHINE or HKLM, which contains machine-specific settings, and HKEY_CURRENT_USER aka HKCU, which contains user-specific settings. Group policy manages both. A 'policy' is either a machine policy or a user policy. Machine policies are applied to HKLM, user policies to HKCU. Each policy consists of a set of registry keys and values to impose a specific task or value.

     

    Every machine has its own distinct HKLM. At boot, any defined machine policies applicable to that machine are overlaid on top of the machine's locally stored HKLM and this superimposition becomes the machine's effective HKLM registry hive.

    Every user has their own distinct HKCU on every machine. At logon, any defined user policies applicable to that user are overlaid on top of the computer they're logging into's copy of their HKCU, and this superimposition becomes the machine's effective HKCU registry hive.

    A policy has two states - defined and undefined. When undefined, it does not overlay itself on the local registry, and whatever was stored for that machine or user on that particular machine is used. This is the default state of things, and is exactly the way a single, unmanaged computer works. When defined, it does overlay itself on the local registry. Changes can be made if the user has permission, but do not write back to the policy definition and will be lost at either reboot or relogin (depending on whether we're in HKCU or HKLM)

     

     

    Bottom line, as long as you store your settings in the registry, everything else will be entirely transparent and you don't have to worry about specifically programming for it. However, if you want to make some system administrator's day, document your registry keys very well. If you want to make some system administrator's WEEK, the group policy administration tools use what's called an "administrative template" file to populate our GUI with policies for us to enable/disable/tweak. These are essentially files associating registry keys with policies and some documentation on what they do. Publish those. You'll need to write them if you choose to test against Group Policy anyway.



  • That makes sense. The saved game folder I should have thought of. It make sense that Microsoft does provide a lot of things to make the programmers life easier. Also Bethesda did the same thing that Blizzard with Morrowind and Oblivion mods, which made my life a pain with UAC on. I want to avoid that with the game I'm mulling around in my head. I do have UAC off, you can flame all you want. I fully understand that I am putting my computer at risk, I don't care.



  • @delta534 said:

    I do have UAC off, you can flame all you want. I fully understand that I am putting my computer at risk, I don't care.
    Not really. There are ways around UAC, and it's primary purpose isn't security anyway - it's there just to force developers to finally lose the "everybody is Administrator" mentality.



  • Yeah, but it does not help when most of the games you run expect admin accounts, and are a pain to move to a different folder that default location that you cannot change on installation. Like I said I am trying to avoid that, because if I do everything right, my programs will still like run on whatever version of windows exists 15 years down the line.



  • @delta534 said:

    Yeah, but it does not help when most of the games you run expect admin accounts, and are a pain to move to a different folder that default location that you cannot change on installation. Like I said I am trying to avoid that, because if I do everything right, my programs will still like run on whatever version of windows exists 15 years down the line.

    Really? I keep UAC on, and I have very few problems with games. That said:

    1) Most of my games are installed via. Steam. (I dunno if that makes a difference.)

    2) I have had to set "Run As Admin" compatibility flags. (The original Neverwinter Nights is one of these, IIRC.)

    3) I've been playing mostly indie/modern games in the last couple years.



  • I've been playing older games like Morrowind. The indie/modern games probably makes a huge difference. It's mainly the older games that were written when admin rights were the default. It's more the inability to modify the folder in which the game was installed by things like 7-zip for mod installation that made me turn UAC off.



  • Steam. (I dunno if that makes a difference.)


    [img]http://imgur.com/4NboA.png[/img]

    All of my Steam games (that is, one of them, damned JC2, I shouldn't need to install Steam to use a boxed game) ended up in Steam's Program Files directory. Whether Steam has some kind of special permissions to it or it uses Steam's background service to orchestrate this, dunno. I think Steam has some kind of filesystem wrapper that allows game content to be streamed so stuff is downloaded as you need it beyond basic core content, which probably also manages read/write access to these folders, possibly even keeping a "diff" for each user. And yeah, I cheat on JC2. I like being able to tie two jumbo jets together without the rope snapping, so sue me!


  • @nexekho said:

    All of my Steam games (that is, one of them, damned JC2, I shouldn't need to install Steam to use a boxed game) ended up in Steam's Program Files directory. Whether Steam has some kind of special permissions to it or it uses Steam's background service to orchestrate this, dunno.

    When you install Steam, it sets permissions on its own folder while it has temporary Admin control. It's... technically legit, but a little... eh... not-so-nice.



  • @blakeyrat said:

    Raymond Chen lays out why you shouldn't use .ini or XML configuration files, but barely broaches the subject of Group Policy (although he does mention it in his last bulletpoint of the top list. You should definitely read that thread and all of Raymond's replies.

    I have tremendous respect for Raymond Chen and really enjoy his blog.  However, one of the problems I see with this particular issue, and even with some of his answers, is that everyone seems to see it strictly as an all or nothing issue -- half the people say the only right way is to always use the registry and the other half says never use it at all.

    One of the things I really like about Firefox is that all my setting are in %appdata%.  This means I can just copy %appdata%\Mozilla to any computer and ~presto~ I've got all my settings.  Several other programs I use are like this as well, and it's really great from a standpoint of backup and portability.  I think people who mostly use these sort of programs tend to think "this is the right way to do it and why can't everyone do it this way"  while people who have other more complicated situations tend to think "put everyting in the registry and never use configuration files".

     



  • @El_Heffe said:

    One of the things I really like about Firefox is that all my setting are in %appdata%.  This means I can just copy %appdata%\Mozilla to any computer and ~presto~ I've got all my settings.

    This. I know from my experience, that I change between Windows and Linux fairly often (every few years... changing to Windows when I just hopelessly broke my Linux and don't care to reinstall, and change to Linux when it's I feel like trying Linux again), and whenever I do, I can just move all my settings over, without any issues. More importantly for me, the same works with Thunderbird and all my mail.



  • @El_Heffe said:

    I can just copy %appdata%\Mozilla to any computer and ~presto~ I've got all my settings.  Several other programs I use are like this as well, and it's really great from a standpoint of backup and portability. 
     

    I cannot stress enough the desirability of this to power users.

    To summarize, preferences and things like that, i.e. user-specific stuff, should go into the user folder, where it's accessible and transferrable.If this creates an issue with AD, then I say fix AD!

    Various system-specific settings that the user doesn't touch can go into the registry, such as file associations.



  • @dhromed said:

    @El_Heffe said:

    I can just copy %appdata%\Mozilla to any computer and ~presto~ I've got all my settings.  Several other programs I use are like this as well, and it's really great from a standpoint of backup and portability. 
     

    I cannot stress enough the desirability of this to power users.

    To summarize, preferences and things like that, i.e. user-specific stuff, should go into the user folder, where it's accessible and transferrable.If this creates an issue with AD, then I say fix AD!

    Various system-specific settings that the user doesn't touch can go into the registry, such as file associations.




    I like the chrome approach: i just gave it my google account and told it to do the sync thingy something.

    now my browser looks and feels same on all computers at home and work

    the only thing missing is sync of the "Most visited" screen (i pin stuff on it) ...



    Mozzila introduced it in 4



  • @blakeyrat said:

    Basically, it's not your job as a [game] developer to decide what the network administrator may or may not do with your software. Your job is to make your software compatible with his tools, so he can do his job.

    Ah, so that's how I get 90+ on metacritic.

    @blakeyrat said:

    Think of it this way: when you're designing a programing language, you don't design it to dictate what type of software it can write, you design it to be as powerful as possible so it can be used to write software you can't even imagine yet. Your program should be the same way.

    Okay, now you're just trolling. What you describe is an antipattern, ofcourse.



  • @Nelle said:

    I like the chrome approach: i just gave it my google account and told it to do the sync thingy something.

    now my browser looks and feels same on all computers at home and work

    the only thing missing is sync of the "Most visited" screen (i pin stuff on it) ...



    Mozzila introduced it in 4

    I used Xmarks for that, 3 years before Chrome got the idea. Still a year or two after Apple first put it in Safari as part of the original .mac product.



  • @dhromed said:

    @El_Heffe said:

    I can just copy %appdata%\Mozilla to any computer and ~presto~ I've got all my settings.  Several other programs I use are like this as well, and it's really great from a standpoint of backup and portability.

    I cannot stress enough the desirability of this to power users.

    Two responses to that:

    1) Network administrators *are* power users. Duh.
    2) Power users shouldn't dictate the design of the system, if they did we'd end up with... well, Linux, basically.

    @dhromed said:

    To summarize, preferences and things like that, i.e. user-specific stuff, should go into the user folder, where it's accessible and transferrable.If this creates an issue with AD, then I say fix AD!

    Ugh. Ok. Let me spell this out for people who are a little slow:

    1) Storing settings in the user folder and storing settings in the Registry are not mutually-exclusive. Firefox, if they gave a fuck, could easily store its settings in both places, making it compliant with AD and also allowing portability of settings from machine to machine. (Or, more simply, it could just provide a "Export Settings..." and corresponding "Import Settings..." option somewhere in the GUI. Why the holy shit do you people, *software developers*, think those two things are mutually-exclusive? Have you the brain worms!?

    2) Why don't you propose a way to "fix" AD that meets every single requirement given by Raymond's bullet-point list and also allows for easy portability of settings in a universal-to-all-applications way? And... doesn't end up being identical to the Registry as implemented. Look, I know Microsoft is TEH EVILS and all that, but they also hire smart people and have spent years and years making Active Directory as powerful and flexible as it is. Most likely, you can't do better than they did.

    I still move the reason software developers hate the registry so much is that they don't understand what it is or what it's for-- if they knew they were alienating the people who sign 10,000 machine purchase orders, they'd shove settings in the Registry toot sweet. (Although sadly, that's not really the case, since the people who buy the software don't really admin the software and all shitty vendors have to do is wine and dine them until they're drunk enough to sign that purchase order for, say, Lotus Notes. Also I wager kickbacks are involved. But in theory... in theory the network administrators have some say in what software is purchased.)

    @dhromed said:

    Various system-specific settings that the user doesn't touch can go into the registry, such as file associations.

    Uh, file associations do go into the Registry.

    @Faxmachinen said:

    Ah, so that's how I get 90+ on metacritic.

    What the fuck are you talking about? You can't just type random sentences, you have to somehow relate them to something else in the thread.

    @Faxmachinen said:

    Okay, now you're just trolling. What you describe is an antipattern, ofcourse.

    A) The inner-system effect is, basically, "adding a configuration option for every single operation the program can possibly do, so that configuring the program takes almost as long as writing a new program to perform the same task."

    B) I'm saying, "put your configuration options in the OS-defined place to put configuration options."

    Now, tell me, how the fucking shit does A relate to B? Remember, you need to connect these two thoughts somehow, you can't just spasm-out random unconnected sentences. Let's try joining the conversation like a big boy and it you get through it without crying, you'll get a sticker at the end, kay?


Log in to reply