I'm running low on memory on my C:\ but I have plenty on D:\
My goal is to make it so all programs installs to D:/Programs even those dumb programs where you don't get an option to choose where they will be installed.
I have been looking into different ways to move the default installation path & register edits & things, but most of them are kind of dangerous, really annoying to do &/or might bring unexpected side effects; like the programs cant be found & such.
But then I found a suggestion to use the windows cmd (commandpromts) mklink command to basically make a shortcut from C:\Programs to D:\Programs
But I'm thinking: What happens if I simply Drag & drop the C:\Programs to D:\ then right click on it & chooses make shortcut & move that shortcut back to C:/
Is this a really stupid or smart solution? (I'm leaning to dumb, because it's just too simple, but I don't know why it would be dumb?)
& does anyone knows what can go wrong with this solution?
I'm using Windows 7
I think I found why this would be stupid, a shortcut done in windows is apparently a file that points to the target & not all programs use it correctly, while using cmd to make a symbolic link is "registered to the hard drive" & it should work better.
Quote from this page:
"Shortcuts, symbolic links, hard links & junctions?!
A shortcut is a file that points to another file. It is an antiquated pointing system from the Windows 95 era that many programs do not recognise. Shortcuts do not only use up space on the hard drive, but they also break and linger behind after the deletion, renaming or moving of the target.
A symbolic link is similar to a shortcut, but instead of being saved as a file it is registered to the hard drive partition. It does not use any disk space, and all programs recognise both the link and the target. A symbolic link can point to any file or folder either locally on the computer or over a network using an SMB path.
A file hard link is a little different and can not be used over multiple partitions meaning you can not have a link on drive C: pointing to a file on drive D:. A file hard link points to and duplicates a target as a mirrored copy, but the duplicate does not use any additional space on the hard drive partition. So two hard links that mirror a 1 GB file would in total only use 1 GB on the partition rather than 3 GB. Importantly if either the hard links or the target were to delete, the other links retain the data. Changes to the content of either the target or the links automatically propagate to all other items.
A junction behaves like a hard link for directories, but unlike file hard links you can create junctions that span multiple partitions. Again a directory junction and its content are stored on the hard drive partition, but they do not use any additional space. Any changes to the content within either the target or the links will automatically propagate except where the target directory is deleted or renamed. In that case, all links that point to the target will break and linger on the partition."
Related
I want to make a program that opens two different programs (one virus file that infects the computer and one that is the real program). I have tried with .bat files, but it requires me to write the path to the file that includes the name of the targets user account. The problem is that i don't know what the target has named his account. Is there any way a program can search the sub folder and find the target programs automaticly? (Im planning on having that program with the folder "first" and in that folder the virus and the actual program will be)
Sorry for bad English
You can use Veil-Framework or metasploit to embed a payload into a file, and it accepts several different formats. Then you have to use social engeenering to distribute the infected file. Youll have to do some tests in local to ensure that infected file evades antivirus (the av evasion is the hard thing to do here as signatures of known payloads are also known by av software).
Renember that infecting a remote computer not owned by you can be considered a delictive act an can get you into legal issues.
Hope this helps.
I was wondering if its possible to add custom folders to console2 app, when it starts.
What i mean is, i created a USB flash that always uses drive letter X, and i have custom apps there, that i need to add to system path, to use them in console2. But the problem is, that don't want to install all of the applications to each computer i connect my USB, nor do i want to add them to system path, since the path will be wrong, when i remove the usb from computer.
So basically, what i want is to create fully portable usb drive with all of the software in it, and i want it to be automatically added and available to console2, but not to the computers system path..
i hope i made my goal clear..
I think I understand your problem, but I'm not entirely sure from your wording. Since you mentioned that you have already created a static drive letter ( X:\ ) for your USB drive, then couldn't you just add the programs to your shell using the path from your USB like this:
http://puu.sh/5wCqW.png
If you're using a different computer every time, then you might have to change the static drive letter for your USB on the computer that you're working on at that moment so that it matches the one in your Console2 shell:
http://www.howtogeek.com/96298/assign-a-static-drive-letter-to-a-usb-drive-in-windows-7/
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.
We develop a database application. The user asks for a new feature: Copy blobs into the clipboard such that Windows Explorer can paste them as new files. One solution is to save the blobs into a temporary folder and add these temporary files to the clipboard.
But I'm looking for a better solution. Is it possible to hook the paste action in Windows Explorer and save the blobs to the destination path by myself?
I've never tried it but I think it is indeed possible. Please take a look at the MSDN Documentation for Shell Clipboard Formats. CFSTR_FILECONTENTS and CFSTR_FILEDESCRIPTOR are the formats you are likely supposed to handle.
Additionally, I found an article at Code Project which provides a demo program: How to drag a virtual file from your app into Windows Explorer.
Update: An example written in .NET:
Creating something from nothing
Creating something from nothing, asynchronously
From the MSDN article Handling Shell Data Transfer Scenarios
Existing files should be offered with the CF_HDROP format.
Offer file-like data with CFSTR_FILECONTENTS/CFSTR_FILEDESCRIPTOR
formats. This approach allows the
target to create a file from a data
object without needing to know
anything about the underlying data
storage. You should normally present
the data as an IStream interface. This
data transfer mechanism is more
flexible than a global memory object
and uses much less memory.
Two other good articles to read from MSDN are:
Shell Data Object
Shell Clipboard Formats
When I first started working on using the clipboard to transfer files I printed off all three articles and read them several times.
Dealing with the interfaces can be quite involved. I have found two good libraries out there to help with this.
The The Drag and Drop Component Suite for Delphi. If you scroll down on the home page you will see some FAQs are good reading. There are also a lot of sample applications with the download. I think the AsyncSource demos should be helpful for what you are looking for. The suite is freeware with source. The code seems to be well commented.
I am currently using the Transfer#Once component from Quasidata. It is not free but is very inexpensive. I initially used Transfer#Once because at the time it was better supported than the Drag and Drop component suite. However, that situation has reversed itself. Transfer#Once does not yet support Delphi 2009. When I get around to moving my application I will probably switch components. The Transfer#Once code is included with purchase. Personally I found the Drag and Drop code to be much easier to read and follow.
I'd say that explorer does the copying to the destination files itself, so there's no way to directly write the destination files. This makes sense, because the names of the source files can only come from the application that copied the data to the clipboard, which need not be explorer. OTOH the names of the destination files may actually differ, because files of the same name could already exist in the destination folder, and only explorer can create the modified names for the destination files (like by prepending "Copy of " or by appending " (2)" to the base file name).
You will need to provide the clipboard format for the Windows Explorer so that it can paste the files. The documentation of standard clipboard formats suggests that CF_HDROP is the right one. With this clipboard format you would provide a list of source file names, but the files do need to exist of course, so you will need to save them to disc.
You could try to make the process as light-weight as possible, though. Usually when a user copies data to the clipboard it is put there immediately, whether or not it will be used for a paste operation. For your application that would mean that you would need to create the files and put the list of file names into the clipboard, every time. However, Windows does support a mode called Delayed Rendering, which is used exactly for such cases. Basically you put only an empty stub of the data onto the clipboard, and only when another application tries to access the data it will be requested from your app. So you could implement this in a way that only when the user tries to paste the files into explorer you would save them to disc and return the list of file names.
It's been a while since I toyed with copy/paste, but I'm pretty sure you can do what you're suggesting (insert the blob as a new file into the clipboard).
I seem to remember that depending on how you add to the clipboard you can specify what sort of data you're copying. I think if you get that data type right, you'll be able to paste as though you'd copied from windows explorer.
I'll try and dig out some more details this evening if I have a chance (I don't have all my bookmarks here at work)...
[Edit] Have a look at the wxWidgets documentation on drag and drop. That was what I'd been working with and it gives some hints about data types.
What are you writing in? Delphi?
[Edit2] I think this may actually be a limitation of Windows(?). It might just be the wxWidgets documentation, but there's a suggestion that you only copy filenames rather than the files themselves. If that's the case, you're going to have to ue your original suggestion of creating a temp file first :-(