Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
This is just a curiosity of mine about how a specific OS executes a binary file.
If I change dir to some path in UNIX or Windows I can execute a program just by entering its file name. In Linux I have to enter ./file_name (unless it's included in PATH). In know it's kind of a stupid question, but is there any reason for that?
Nothing magical - it's simply because, by default, Windows implicitly includes '.' in the executable search path. *nix does not.
The latter behavior is obviously more secure, if marginally less convenient.
You can obtain behavior similar to Windows under *nix (at some cost in security) by adding '.' to your path
For example, you could add the following to your .bash_profile:
export PATH=PATH:.
Of course, that's not exactly the same as Windows, as Windows (again, by default) looks in the CWD first. You could do the same in *nix by moving the '.' to the front of the system's PATH, but don't do that!
It opens you up to a large security risk. If someone were to be able to drop a malicious program with the same name as a system utility (say "ls", or "cp"), that program would run instead of the system utility. You can imagine the potential for "mischief" that provides!
To expand on what Gregj said, there is a PATH variable in both Windows and Linux, which tells the operating system where to look for executables when you don't tell it explicitly where it is. Linux doesn't include the current directory (.) for security concerns; a program could otherwise hide an executable with the name of a common utility (ls, for instance) in a lot of files so you might overlook it, and then it would be run instead of the utility you meant, potentially causing damage, loss of sensitive data, etc. Windows does search ., even if it's not explicitly in the path, for convenience and because of their lack of concern over security.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have opened a file through on Windows command prompt, just by navigating to that directory and then typing it's name. Now is there a way to close that (open) file through the command prompt? I've been searching around and I can't find out how. Seems to be a pretty simple command to not exist.
There is no MS-DOS in Windows and has not been since about 2003. The "Command Prompt" program (named cmd.exe) runs in a console window and looks and behaves like the command interpreter of MS-DOS, enough like it to seem the same to many people, although there are some small differences.
If you give a filename as a command to a command prompt and that named file is not a program, it looks at the extension to try to select an appropriate program to run and open the file. The .doc extension usually corresponds to MS Word (Office) or the stripped-down version MS Works, but depending on what software you have installed and how it is configured .doc could be something else. You can find out what it is on your system by the command-prompt commands assoc .doc and usually then ftype (value from assoc) or by looking in the registry under HKEY_CLASSES_ROOT. Once the program runs (a running program is also called a process) it may keep the file open while running (like Word) or only open it briefly and then close it (like notepad).
Once you know what program/process is running, you can direct that process to stop with the taskkill command. Type taskkill /? for help information. If there is more than one process running the same program and you use the /im option, it will stop all of them, not just the one you want. To use the /pid option, tasklist or TaskManager can help you find the right process -- but if you use TaskManager it can also stop the process, so taskkill is unnecessary. If the program malfunctions and doesn't stop when directed, taskkill /f will force it, but this may leave the open file(s) with damaged and incorrect or unusable data.
Also note that command itself effectively keeps the directory open. If you are trying to rename or move a subtree of files including that directory, you must first either cd the command process somewhere else, or terminate it with exit.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm using the robocopy command
robocopy empty_dir super_subfoldered_folder /s /mir
rmdir empty_dir
rmdir super_subfoldered_folder
to delete the folders at once but during this command robocopy.exe stops working.
I have tried to delete from a path that starts at least 50 sub folders inside the main folder still crashes.
I've tried renaming them to "1" but windows doesn't let me past 100+ folders and there are at least 1000 more. Tried to create new partition- subst j: . rename some folders and delete the partition but this takes forever because of their number.
Tried dir /x and del the shortened name -> doesnt work.
Is there another way to delete those folders ?
File path in Windows goes through several layers before it gets to the actual file system driver. As a result there are two limits. 1) MAX_PATH (260) limitation introduced by the top-level API 2) 32K actually used by the file system. Since you already have that path, it is obviously within the limits of the file system. Try using path by adding "\\?\" to the front. This is an indicator that Win32 API should not parse the string but pass it directly to the file system (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx). This will only work if the proces making the call is Unicode and 64-bit (on a 64-bit system). Otherwise the string must be converted and/or marshaled and you are back to the 260 limit.
Windows has a subdirectory depth limit and it's not very deep.
You may get a better result by booting up a Live Linux distro on cd or USB, like Ubuntu, and using the GUI file manager to delete the tree.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
This looks like a common question. But I was not able to find answer for it. When we try to install windows programs, what exactly happens? What files are copied where? What is written in the registry?
Most programs come with an installation program named Setup.exe or Install.exe. When you install a program, the installation program usually does the following:
Looks for a previous version of the program on your hard disk. If it
finds a previous version, the program may ask whether you want to
replace the previous version.
Creates a folder in which to store the program files. Most
installation programs ask where you'd like this folder. Some
installation programs also create additional folders within this
folder. Windows creates a folder named Program Files, usually in C:\
(if Windows is stored in a partition or drive other than C, the
Program Files folder is usually in the same partition). We recommend
you install all your programs in folders within the Program Files
folder.
note Some software vendors have the bad habit of installing
application programs in locations other than your Program Files
folder. You can't do much about this; the additional folders may
clutter up your root folder, but they don't do any harm.
Copies the files onto your hard disk. If the program files are
compressed, the installation program uncompresses them. Usually, the
installation program copies most of the files into the program's
folder, but it may also put some files into your C:\Windows,
C:\Windows\System, or other folders.
Checks your system for the files and hardware it needs to run. For
example, an Internet connection program might check for a modem.
Adds entries to the Windows Registry to tell Windows which types of
files the program works with, which files the program is stored in,
and other information about the program.
Adds a command for the program to your Start | All Programs menu
(some programs add submenus to the Start | All Programs menu to
contain several commands). The installation program may also add a
shortcut to your Windows desktop to make running the program easy for
you. You can change the position on the Start menu of the command for
the program, get rid of the command, or create a command if the
installation program doesn't make one. You can also create a shortcut
icon on the desktop, if the installation program hasn't done so, or
move or delete the program's shortcut.
Asks you a series of questions to configure the program for your
system. The program may ask you to type additional information, like
Internet addresses, passwords, or software license numbers. It may
also ask which users should be able to run the program.
Every installation program is different, because it comes with the application program, not with Windows. If your computer is connected to a LAN or to the Internet, the installation program may configure your program to connect to other computers on the network.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Why do some software require system restart in windows ?
Meanwhile , I have never encountered such situation in Linux based Distros.
It is innate to the way Windows was designed. Loading an executable doesn't load the file into RAM. Windows creates a memory-mapped file for the executable instead. Chunks of the program get loaded into RAM on demand only as needed. A page fault copies 4096 bytes from the file. The RAM pages themselves are not backed by the paging file. If RAM is needed for other processes then Windows simply unmaps the page and throws away the bytes it contains. If the process again lands on the page then a page fault reloads RAM from the file. Very efficient, this mattered a great deal when you need to run a 32-bit operating system and many processes in only 16 megabytes of RAM. Still efficient today, but not as critical as it once was.
One side-effect of the memory-mapped file is that it puts a write lock on the file. Necessary to prevent another processes from altering the executable. That would be disastrous, RAM could contain a mix of old and new bytes in the file. That's guaranteed to cause the program to malfunction.
Of course that makes the life harder for programs that intentionally want to change the executable. Including the malicious variety btw. So having to stop the processes that have the file loaded is required, it releases the write lock. An update delivered through Windows Update tends to update executables that cannot easily be unloaded since they are part of the operating system. Which is the reason they tend to require a reboot, the file is updated as part of the boot sequence when the machine restarts.
One way to bypass the lock is to rename the file. The lock only protects the file data, not the directory entry. You can then create a new directory entry with the same name as the old one. And the next time the process gets started, it will use the new entry. One minor complication is that you have to eventually delete the renamed file.
One thing I can think of is that some software requires services to be running for it to run properly. The restart likely adds these services to the ones that automatically run when you start the computer so that the program can run smoothly.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Can I run the batch file on UNIX? (Linux / Mac OS X)
I am looking for the interpreter to run the Windows Batch file on UNIX, like 'bash' for bash script, 'csh' for csh script, so 'XXX' for windows batch file.
I am developing a Java application.
Development environment is on Mac OS X
but target(primary executed) environment is on Windows.
The applicaiton uses Windows batch file & executable.
it generates *.bat to run the stub program (*.exe).
So I want to write Unit-tests and prepare the stub program (*.exe as bash script),
and want to run it on Mac OS X - not Windows.
but, it does not mean that I want to execute (emulate) Windows binary (*.exe)... I only want to launch *.bat and let it to invoke test stub *.exe made with sh/perl/ruby.
...Any ideas?
(Related to)
how i can execute windows batch file from UNIX-AIX?
cmd.exe is rated NSFW in my area code
On windows look at PowerShell
If you insist, use Wine on linux, Solaris, BSD etc. It comes with cmd.exe :)
Wikipedia on Wine
MacOSX support:
http://wiki.winehq.org/MacOSX
http://davidbaumgold.com/tutorials/wine-mac/
No, there isn't such a beast. And, if there is a god, there never will be :-)
While the effort to create a batch file interpreter is moderate to high (especially if you're not using every single feature of cmd.exe), running the executable is so much, much harder.
I would be investigating a solution of starting up a clean Windows virtual machine and running your application under Windows there. You could easily do your unit tests as Windows programs as well so as not to have to worry about driving the VM from OSX.
The only thing you then need to concern yourself with is how to get the results back to OSX from the Windows VM. That should be doable (though kludgy) via network storage (shared drives or NFS or something similar).