Jump to content
Sign in to follow this  
Nyerguds

[split] Rename of CCSetup to CCSettings

Recommended Posts

That being done, isn't the new tool named CCSetup anymore ? Because that's what I wrote in the translated read me, if I remember correctly... Don't forget to change it ^^

 

I can't call it ccsetup because windows 7 is retarded and treats every program with "setup" or "install" in the filename as if it's an installer, and then complains if it was not ran in Administrator mode... so I renamed it X_x

 

But yes, I've already updated the name everywhere ;)

Share this post


Link to post

Ok lol

I never thought that 7 would be that dumb. Microsoft still has some work to do :lol:

Share this post


Link to post
I can't call it ccsetup because windows 7 is retarded and treats every program with "setup" or "install" in the filename as if it's an installer, and then complains if it was not ran in Administrator mode... so I renamed it X_x

 

But yes, I've already updated the name everywhere ;)

That might be the dumbest thing I ever heard. Whole point if UAC is to sniff out unexpected administrator-only operations.

Share this post


Link to post

Yep. There's even OS-specific settings you can put into the exe (by using a manifest-file) to make sure it behaves in a certain way, with or without rights elevation. Windows 7's compatibility assistant decides to completely ignore that from the moment it finds "setup" or "install" in either the filename or the exe's version information -_-

 

For every such program that runs without admin rights, you get a popup after closing the program that basically says "this application may not have installed correctly, because it was ran without administrator rights", with the option to run it again, in admin mode. Really dumb. And the only way around it is adding some special system exception on it; something that's entirely dependent on the user's profile, and that (as far as I can tell) can't be done automatically on install.

 

For more insight, here's the blog of a Microsoft developer ranting about how badly the Win7 devs screwed that up:

http://blogs.msdn.com/b/cjacks/archive/200...les-on-you.aspx

 

Anyway, this is the translation thread, so let's keep the discussion about this stuff to a minimum :P

Share this post


Link to post

"Insight", that seams to lofty a word for this debacle. It's bad enough to dumb stuff down for the end user. It's even worse to do so at developers' expense. Hell this would just confuse the end users after that downloaded something that they thought had less risk of messing with their computers. What a failure on MS's part.

Share this post


Link to post

Eh... that's pretty much exactly what the MS developer says in that link I provided as "more insight". Apparently he wasn't part of the people who did it, and was just as irate when he heard about it :P

 

Anyway, I split this off, because I specifically asked non-translators to stay out of the translation thread, but this discussion still has info that's useful enough to keep around for everyone.

Share this post


Link to post

I'd really like to see how the MS-bashing people would react if these compatibilty features weren't there. Just letting bad software crash when it tries to write any file to the program files directory, be it savegames, the highscore file or the settings ini. Features like that are present to keep crappy software running, and all classic C&C games write their stuff to the game folder, which was a bad practice even in the '90.

 

Before you judge a company so quickly, you should look at the history of the problem. It is possible to disable the dialog for Windows 7, but you can't disable it pre-emptively for every future OS version - for a reason.

Share this post


Link to post
I'd really like to see how the MS-bashing people would react if these compatibilty features weren't there. Just letting bad software crash when it tries to write any file to the program files directory, be it savegames, the highscore file or the settings ini. Features like that are present to keep crappy software running, and all classic C&C games write their stuff to the game folder, which was a bad practice even in the '90.

 

Before you judge a company so quickly, you should look at the history of the problem. It is possible to disable the dialog for Windows 7, but you can't disable it pre-emptively for every future OS version - for a reason.

 

OpenGL ftw! =P

 

btw, when i was running Windows 7, i disabled UAC. That crap do a lot of issues, like slow Installers load, problems with Command Prompt. Really. Windows XP still the best Microsoft OS for me :P

Share this post


Link to post

UAC is the first thing I disable when I install windows 7. However, I prefer that each game save their stuff in the game folder rather than program files or documents. Because when I format the windows hard drive, I never think of making back up of these folders.

 

To stay on the topic, I had no problem with CCSetup.exe when I checked it.

 

And now that you changed the name, did you think of adding a command or something in the installer to delete the original ccsetup.exe, for those who patch the original game ? Because I know I would get confuse with 2 settings program in the same folder ^^

Share this post


Link to post

AlexB, you do have to put this in perspective... a Microsoft programmer, ON the UAC support dev team, is ranting about how poorly the developers of the UAC handled this. He's one of the people responsible for patching the mess the original programmers made.

 

This isn't a "Microsoft" problem. It's a problem of those specific devs that messed up this system.

 

And now that you changed the name, did you think of adding a command or something in the installer to delete the original ccsetup.exe, for those who patch the original game ? Because I know I would get confuse with 2 settings program in the same folder ^^

Obviously. My installer script has a "files to delete" section for all previous versions of the game.

 

[InstallDelete]
; version 1.06b cleanup
Name: {app}\updatrem.mix; Type: files
Name: {app}\funpark.exe; Type: files

; Remove spanish language; it'll be useless without a lang_spa.mix anyway
Name: {app}\deseispa.mix; Type: files
Name: {app}\snowispa.mix; Type: files
Name: {app}\tempispa.mix; Type: files
Name: {app}\wintispa.mix; Type: files
Name: {app}\speecspa.mix; Type: files
Name: {app}\talkspa.mix; Type: files

; version 1.06a cleanup
Name: {app}\update01.mix; Type: files
Name: {app}\update03.mix; Type: files
Name: {app}\funpark.bat; Type: files
; version 1.04 cleanup
Name: {app}\version.txt; Type: files
Name: {app}\logo.vqa; Type: files
Name: {app}\logo.vqp; Type: files
Name: {app}\ccsetup.exe; Type: files
; possible extracted files cleanup (mostly necessary for the German TFD)
Name: {app}\scg0?e?.ini; Type: files
Name: {app}\scg0?e?.bin; Type: files
Name: {app}\scg0?w?.ini; Type: files
Name: {app}\scg0?w?.bin; Type: files
Name: {app}\scg1?e?.ini; Type: files
Name: {app}\scg1?e?.bin; Type: files
Name: {app}\scb0?e?.ini; Type: files
Name: {app}\scb0?e?.bin; Type: files
Name: {app}\scb1?e?.ini; Type: files
Name: {app}\scb1?e?.bin; Type: files

Name: {app}\conquer.eng; Type: files
Name: {app}\conquer.ger; Type: files
Name: {app}\conquer.fre; Type: files

; Special Ops files cleanup
Name: {app}\scN64mis.mix; Type: files

Share this post


Link to post
AlexB, you do have to put this in perspective... a Microsoft programmer, ON the UAC support dev team, is ranting about how poorly the developers of the UAC handled this. He's one of the people responsible for patching the mess the original programmers made.

 

This isn't a "Microsoft" problem. It's a problem of those specific devs that messed up this system.

Sure, no system is perfect and it's a pity you can't say "I'm not a setup tool, and I won't be, ever!". But decisions like that aren't made by rouge devs just because they feel like it. They must have had a reason to do this, and I can imagine it's quite undesirable to have software saying "I'm compatible with all future OSes, even though I don't know anything about them". Maybe Windows 8 will offer a solution. :lol:

The blogger from the link I posted is a compatibility coder working for Microsoft, too, but not for UAC. ^_^

 

You could fix CCSetup if you include a compatibility section in the manifest with the Windows 7 GUID, but you'll have to update the tool for Windows 8, and possibly its successors, because you can't know their GUIDs yet. It is a solution, but not a complete one. Renaming the file and changing the file description completely evades the problem. For now this should be the easiest way.

Share this post


Link to post

I DID Include a manifest for Windows 7 into the program. Windows 7 ignored it because of the filename. THAT's how bad the system is.

Share this post


Link to post

I don't see why MS even needs to include this special logic for installers. How is their normal way of detecting whether a feature needs administrator privileges not good enough?

Eh... that's pretty much exactly what the MS developer says in that link I provided as "more insight". Apparently he wasn't part of the people who did it, and was just as irate when he heard about it :P

 

Anyway, I split this off, because I specifically asked non-translators to stay out of the translation thread, but this discussion still has info that's useful enough to keep around for everyone.

I wasn't trying to correct your english or anything like that. I was just making a (bad) joke about how screwed up this "feature" is.

 

Share this post


Link to post
I DID Include a manifest for Windows 7 into the program. Windows 7 ignored it because of the filename. THAT's how bad the system is.

That's weird, because the UAC guy explicitly says including the Windows 7 GUID disables PCA for sure. :huh: Would you rename CCSettings back to CCSetup if it worked (at least for Win7)? If yes, I could try to investigate why it still shows up and how to disable PCA.

 

Sonarpulse: Windows does not detect what a program does. If it isn't running with elevated privileges, some actions like copying or editing files, changing the registry and several others just fail. Processes cannot be elevated when they are already running, they have to be started with elevated privileges. This and the fact setups exist to change the system (they require these privileges) lead to the conclusion setups shouldn't be launched unelevated. (The C&C setup isn't a true setup, it just changes user settings, which any application is able to without elevation. But: elevation is needed if the configuration file lies in the program files folder, which is readonly for standard users [for a very good reason].)

Share this post


Link to post

The way the detection SHOULD work is this: a program "identified" as setup runs, and exits, without leaving installer-related information in the registry piece related to installers (the section from which it also reads the "Add/Remove programs" stuff).

 

Because of this, it triggers the compatibility wizard, because windows assumes it was an installer that ran without privileges and failed to write to the installer registry.

 

The PROBLEM is that unlike windows Vista, Win7 ignores the manifests in the identification part of the process. Installer identification has always been done by filename and version information, but Vista at least has the decency to abort the whole thing if the program has a Windows Vista manifest saying it shouldn't run as admin. Windows 7 doesn't do that. Even applications that specifically tell Windows 7 that they were MADE FOR Win7 and should run WITHOUT admin rights get targeted by the compatibility wizard.

 

That's weird, because the UAC guy explicitly says including the Windows 7 GUID disables PCA for sure.

I added this in the manifest. That IS the GUID bit. It did NOT help.

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    </application>
  </compatibility>

Those are the IDs for Vistan wnd Win7. Not a clue what else I'd have to do.

Share this post


Link to post

I don't know the exact words, but the captions should be similar. In the Windows "Resource Monitor", add the column "OS context" (?) to the CPU list. If you start CCSetup.exe, this column should show "Windows Vista" despite the compatibility manifest and exiting the tool will show the PCA dialog. If you now rename the CCSetup.exe file to CC2Setup.exe or whatever (keep the word Setup to trigger the Windows heuristic) and restart it, does it still show as Vista or is it Windows 7 now? If it is, it is most likely a caching issue. Instead of renaming, you could also copy the file to another folder and test it there. I tested this with an older version of your CCSetup.exe and RASetup.exe, and the PCA dialog no longer appears.

Share this post


Link to post

I have no idea what that Resource Monitor would be. But as the article said, the problem would simply reappear for the next Windows version anyway. So I'm keeping it.

Share this post


Link to post

I'd go with renaming it to CCconfig.exe, Renegade has a similiar WWconfig.exe file for all the settings that can be changed in-game.

Share this post


Link to post

That's not a bad suggestion, actually :)

Share this post


Link to post
I have no idea what that Resource Monitor would be.

You can find it from task manager -> performance tab -> Resource Monitor button.

Share this post


Link to post
Sonarpulse: Windows does not detect what a program does. If it isn't running with elevated privileges, some actions like copying or editing files, changing the registry and several others just fail. Processes cannot be elevated when they are already running, they have to be started with elevated privileges. This and the fact setups exist to change the system (they require these privileges) lead to the conclusion setups shouldn't be launched unelevated. (The C&C setup isn't a true setup, it just changes user settings, which any application is able to without elevation. But: elevation is needed if the configuration file lies in the program files folder, which is readonly for standard users [for a very good reason].)

 

Oh, thought I had seeing some pre-vista software automatically defaulting to administrator only, but I guess not. I admit, I have no idea how windows could've fathomed before-hand if executables would need elevated privilages. Also I knew about XCC mixer (almost) silently failing to save due to UAC so I certainly knew of the way things actually worked. Not sure how I got that wrong.

 

You say processes can't be elevated while running, so does this mean when you're let's say changing NTFS privilages (god, i hate that), It discretely restarts the dialogue process?

---------

CCconfig IS a great idea. maybe TDconfig would be less ambigous, but Nyerguds has mostly used cnc95 in other instances so TDconfig would be inconsistant.

Share this post


Link to post

It does not check what the actual code does (which is not possible anyhow). As long as there is no manifest file for an executable (read: old program), Windows has a list of known setup program names (for InstallShield, Wise, InnoSetup, ...) and other tools that are known to require elevation. Otherwise it just guesses by filename and file description.

 

How programs like XCC deal with errors is up to them. Then there's file system virtualization that suppresses elevation-related errors by silently changing the file location, which makes writing succeed even though you don't have write access to a folder. If the program tries to read those files, the path is again changed and the read operation succeeds also. Thus old programs which don't know about NTFS access restrictions are still permitted to run. (In Vista and Windows 7 a "Compatibility files" button should show up in this case, allowing you to see the redirected files in their real.)

 

NTFS folder access rights are not the same as process elevation. The access rights can be changed while a process is running. But if you launch Task Manager and click the "Show processes for all users" button, it is closed and a new elevated Task Manager is started. (You can see this on the performance graphs tab, which is reset in the process). All those complex compatibility things can be a real pain in the lower back region, because for every screw you tighten, some cogs in other parts of the program become loose potentially.

Share this post


Link to post

The problem is that my program DOES have a Manifest file, and it still triggers the compatibility. Believe me, I've tried everything, researched everything, and the issue keeps popping up for other programmers too. It can't be fixed besides with that "shimming" process, and I couldn't find any info on how to automate that.

Share this post


Link to post

Yeah the whole comparability files deal never worked for me. Programs, TS for example, never got redirected when they tried to read the files. I think XCC sometimes would successfully write to the compatibility folder, and sometimes would wouldn't write at all.

 

Yeah I wasn't clear. I didn't mean to conflate the NTFS permissions themselves with process elevation, rather, I was referring to elevating the process of the dialogue used to change the file permissions. Why didn't they just make this stuff like Unix back in the DOS (or even NT) days...

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×