[RESOLVED] Create a text file in Windows directory

[ek_developers]

hello guys,

I want to create a text file on this path "c:\windows\system32\abc.txt" programmically.

I use this simple code

Dim iFileNo As Integer
iFileNo = FreeFile
Open "C:\windows\system32\abc.txt" For Output As #iFileNo
Print #iFileNo, "bla bla.."
Close #iFileNo

the above code is working fine when creating text file on other than windows disk. but when i create in windows disk (Local Disk C) it won't work. I know Windows 7 requires admin privileges to write to this directory.

So i need to do one of this

1. Run my program as administrator
2. Turn off User Account Control Settings.

but i want to make this without doing these things because of some security issues with my clients..
Is there any other ways to make this possible??

[Arnoutdv]

No and why would you?
Why do you think you need to write data in the system folder?

[LaVolpe]

Welcome to the forums

Don't abuse protected folders. Windows has given you folders to be used for your application and/or your clients. Use those folders.

[ek_developers]

thank you guys,

I want this just for my software's security purpose.. If the files(those text files) present in that folder my software will work or otherwise it shows 'system not activated' something like that.. If i put those files in my application directory the clients can easily find them..

[Arnoutdv]

Better choose a different method.
For example use an encrypted file in the application or user data folder .

[Zvoni]

Better choose a different method.
For example use an encrypted file in the application or user data folder .

Or an encrypted entry in the registry HKLM (Machine-wide)
Many ways to skin that cat.....

[Elroy]

Yeah, my first thought is to use the registry. You can just go quite simple and use the SaveSetting and GetSetting commands. The vast majority of users are never going to mess around in the registry. Any any who are would even more easily find your file in the c:\windows\system32 folder.

And yes, I have to second LaVolpe's advice, "Don't abuse protected folders. Windows has given you folders to be used for your application and/or your clients. Use those folders."

If you really want a file (as opposed to a registry entry), I'd recommend studying up on the appropriate use of the C:\ProgramData area. That's typically a hidden folder, and it's precisely for programs that need to place some files on the local computer that can be used by any user logged into that machine.

Good Luck,
Elroy

[dilettante]

HKLM writing requires elevation aside from a few exceptions Windows places different security upon.

It sounds like you need someplace visible by all users who might log on.

There are two obvious places then: HKLM or the CommonAppData special folder. To use either one requires creating a registry key or a subfolder beneath and then setting security on that permitting the necessary access by all logged on users. That's why you'd normally set them up within an elevated installer run. If you do not use a proper formal installer then your other option is to require that the program by run once elevated, then the program could detect the missing location and create it and set its security.

Another sort of hacky way might be to create a folder under the Public special folder. All logged on users should already have nearly full access there. This requires Vista or later though, and its actual location can theoretically move from version to version so you are supposed to look it up at runtime. If you are willing to trust environment variables there is one called PUBLIC defined, or else you can use FOLDERID_Public to call the SHGetKnownFolderPath() API.

[ek_developers]

thank you so much guys,

I've tried registry(HKLM) and i think it'll be even better..

Thanks again..
Resolved

[dilettante]

Unless you have dealt with setting the DACL on your registry key within an elevated task you are in for a world of hurt.

Your program might seem to work but your attempts at registry writing will be virtualized into the current user's HKCU. Runs under another user won't see anything because it is not actually in HKLM.

See Registry Virtualization, and welcome to 2006.

[Zvoni]

dil,

i think he's trying to achieve something like a license-/key-file (if missing then Demo-mode or something).
As for the HKLM: You're right with the elevated user needed, but if he writes that key during Installation (which needs elevated rights) then his problem has more to do with: How does he get his setup-Routine (Not his program!!) to write that key into HKLM.
Then he would just need to read that key during runtime/startup of his Application.
Anyway, Elroy's idea with c:\ProgramData is a viable option

[dilettante]

Your installer can prompt for the license key and write the data to the registry. Nearly every common setup technology supports this sort of thing. Even the PDW can be used by creating a custom setup1.exe to do this. Windows Installer has a very basic built in "product key" mechanism but that can be extended via Custom Actions. Third party setup tools offer similar features.

CommonAppData (which in some versions of Windows is at %SystemDrive%\ProgramData unless local group policy has redirected it elsewhere) is a possibility as long as your application doesn't need to do anything but read there. BTW: Do not hard code this path, always look it up at runtime just like all special folders.

CommonAppData has a "Creator Owner" DACL on it and this will be inherited by a subfolder you create there. That means that the user who creates any files within it gets full access and other users get read-only access. If any standard users running your application need to update such files you'll have problems again.

That's why your elevated installer should create the folder, set security on it as required by your application, and then populate the folder with any files you need there initially. This is trivial enough in Windows Installer through a few table entries, for the PDW you'll need to customize setup1.exe, and so on.


Deployment is a separate discipline of its own, which is part of the reason why it has its own forum at VBForums.

[dilettante]

Maybe see the [VB6] ProgramData for common files.

But yes, if the application only reads a file there then most of that isn't necessary since everyone gets read-only access anyway.

That means your program could check for the file and if the path isn't valid yet it can go ahead and prompt for the license key, then create the folder and the file. That user will "own" the folder and file but if other users are only going to read it this is no big deal.

[PGBSoft]

It’s a wonder…, no one does not talk about how to utilize Alternate Data Stream (ADS) to accomplish this type of stuff, at least for an idea to try. Yes, it might not be a professional approach and it has few limitations and disadvantages such as it supports only on NTFS, antivirus attention, can find with command prompt etc., but it is still a very interesting, effective and simple approach where people do not much talk about to hide secret data.

The attached one is a very simple demo application, which stores/embeds a text stream of data dynamically with the application executable file itself. It also supports automatic elevated execution to alter/remove stream data if needed, when the executable file resides in a protected location such as program files, windows folder, or folders protected with ACL permissions.

The demo also provides an alternate answer to the questions on how to save dynamic data into the executables itself.



Note: The demo supports activation code of ‘123456’. Change it in Module1 for your own as follows for testing

Public Const ACTIVATION_CODE = "123456" 'set your own for testing