locked
writing executable to \system32 RRS feed

  • Question

  • I had a screen saver program which misbehaved when I upgraded to win 10. I changed 1 line in my .cpp file and rebuilt.

    All well until writing to \system32 folder "unable to open wormsav.scr". I am sure this is a permisssions issue, even though I am the sole user & administrator etc I don't seem to have read/write access to certain system folders.

    do I need to modify something in some property page for the build process?

    How do I modify  something in \system32?

    (I've already posted this to the windows 10 forum!)

    Thanks, Mike

    Friday, July 21, 2017 12:17 PM

All replies

  • >All well until writing to \system32 folder "unable to open wormsav.scr". I am sure this is a permisssions issue, even though I am the sole user & administrator

    Mike,

    Despite being logged on as an administrator, are you running the process that's trying to write that file elevated (Run as
    administrator)?

    Dave

    Friday, July 21, 2017 12:58 PM
  • Hi Dave,

    Yes, VS2008 is still running, but the error occurs even when VS is not even loaded. I'm very fond  of this particular creation, which is 20+ years old! It has worked well in environments from WWG 3.1, win 95, win 7 and Visual C++ 6.0. It's really ugly when it's running on a black background. I have tried lots of things including declaring my graphics resources inside and outside the window procedure., copying the mainDC to the saver's DC at various points. I'm using double-buffered repaints to reduce flicker. My Msft screen savers work well, but I'm sure those programmers knew a thing or two more than me!

    ??

    Thanks, Mike.
    Friday, July 21, 2017 5:47 PM
  • Mike,

    Your reply seems to have meandered from the question you asked.

    What process is trying to write the file? It's that process that needs to be run elevated.

    Dave

    Friday, July 21, 2017 6:03 PM
  • Dave,

    OK, whatever process within VS2008 that writes the final executable (.scr)

    I am running VS "as administrator". More details:

    Problem (black background) occurs ONLY when it is started by the timer, otherwise, in the settings dialog, in the little preview screen or from the preview button and directly from desktop icon it runs perfectly.

    what am I missing?

    Thanks for your patience.

    Mike.

     

    Friday, July 21, 2017 9:23 PM
  • OK, whatever process within VS2008 that writes the final executable (.scr)

    Ah, so you're somehow getting the build target written to that directory?
    Have you got some custom build step copying it, or have you set the output to that destination?

    I am running VS "as administrator".

    OK.

    Problem (black background) occurs ONLY when it is started by the timer, otherwise, in the settings dialog, in the little preview screen or from the preview button and directly from desktop icon it runs perfectly.

    How does that relate to the problem of copying the file?

    what am I missing?

    I have no idea. I've never written a screen saver.

    Dave

    Saturday, July 22, 2017 12:04 AM
  • Bear with me Dave.

    I was very happy with win 7 and had to be dragged kicking and screaming to upgrade to win 10. Over several "upgrades" of OS over 2 decades it has been my experience that each upgrade has led to me having to junk well-loved programs because the new version was too advanced for them. This is now the case with VS2008. After years of happy programming I have had this problem which has cost me hours of effort to solve. (and is still not solved!) Basically, screensavers are always run from system\32, but I quickly found that it requires ready access to this directory to write and troubleshoot savers. Thus my interest in copying to \system32

    It is simply that "copying" is a surrogate for all those file operations. I don't need to copy as such, but if I could copy, I could list, write, erase etc etc. win7 is much more forgiving and has no trouble just writing there, erasing etc. These are operations I am doing every 5 minutes when I am writing and debugging code. I'm sorry if I didn't explain myself well. So far I have managed to take ownership of the folder but that was laborious and still time consuming to  do the multiple reads, writes etc required by the the debugging process. Screensavers (and I have written a few) are tricky to debug because you can't just run with breakpoints, look at variables on the fly etc. Basically you can do one of 2 things, put your fancy graphics etc in a generic window app (console) to debug, or just keep trying various things until it starts working. (write/build/run/rewrite/rerun etc.)

    There's a lot to like about win 10. It is quite pretty, but you just have to look at the problems people bring to these forums (fora?) to wonder if it's just too complex. Seems like even skilled programmers are always finding little unexplained quirks. Absolutely I now know way more about permissions in win 10 than I want to. I just want my screensaver to work. (BTW, I tried to upgrade to VS2015 but it was just a horrendous experience (see my posts in that forum!) and I had to go back to 2008).

    So, restating the issue:

    screensaver program 20 y old, working well over 2 or 3 versions of windows.

    I want my little worms to be crawling over the screen, not suspended in a black void. I know it can be done because if I run it from a desktop icon, it works as it should.

    Thanks for your patience!

    Mike.

    Saturday, July 22, 2017 3:20 AM
  • ... This is now the case with VS2008.

    Mike,

    So, what exactly doesn't work for you with VS2008 under Windows 10?

    As far as I know there's nothing fundamentally different regarding the security of the system32 folder from Win7-10.

    Basically, screensavers are always run from system\32, but I quickly found that it requires ready access to this directory to write and troubleshoot savers. Thus my interest in copying to \system32

    OK, but you've still not clarified what isn't working for you. Your problem may be clear to you, but it's not to me and probably no
    one else.

    It is simply that "copying" is a surrogate for all those file operations. I don't need to copy as such, but if I could copy, I could list, write, erase etc etc.

    Try this experiment.

    Open a command prompt in Windows 10 and change directory to c:\windows\system32
    Assuming you've not set User Account Control settings to disable UAC, even though you're logged on as an administrator account, the
    command prompt will not have permissions to modify c:\windows\system32, so when you do this:

    C:\Windows\System32>copy Bubbles.scr temp.scr

    You should get:    Access is denied.

    Now, open another command prompt but use Run as administrator. Note that the caption bar for the command prompt says "Administrator:
    Command Prompt" to indicate it's running elevated.

    Change directory to the c:\windows\system32 directory and then do:

    C:\WINDOWS\system32>copy Bubbles.scr temp.scr

    It should succeed.

    Similarly, from this command prompt, you should be able to: del temp.scr
    and it should work too.

    win7 is much more forgiving and has no trouble just writing there, erasing etc.

    It should be no different.

    There's a lot to like about win 10. It is quite pretty,

    Compared to what? I prefer older desktop UIs - ones that were consistent and didn't try to blind you or test your vision with barely
    visible pale grey on white text. There, you've got me started! :)

    I want my little worms to be crawling over the screen, not suspended in a black void.

    If your problem is no longer to do with getting your exe to the system32 directory, please start a new thread.

    Dave

    Saturday, July 22, 2017 5:25 PM
  • Thanks Dave.

    I will move to the win 10 forum.

    Sunday, July 23, 2017 6:59 PM