I'm trying to install Daggerfall onto my computer.
It asks me for the installation directory; the default is C:\dagger, but I want it to install to C:\Program Files (x86)\Dagger. Problem is it doesn't allow for spaces or pretty much any punctuation, so what I tried to do was replace spaces with underscores.
Sadly, that didn't work, because now I get the error message, "You have entered an invalid DOS path. Please correct this."
Is there a way to designate the installation directory as C:\Program Files (x86) here? If so, how do I do it?
NOTE: This may seem at first like it would be better posted in Arqade, but I feel it's more appropriate for this site since this question has more to do with DOS input than it does at all the game. I'm asking about the directory itself and the way to type it correctly, so it's not 100% game-specific.
DOS did not support long directory names. Usually, we would install games under C:\games or similar. You are limited to 8 characters (excluding the extension).
Windows knows this, and will present "short" path names for backward compatibility with FAT16.
Your directory will most likely be C:\PROGRA~1 or similar. An easy way to find out is to run cmd.exe and then go to the directory in question:
cd "c:\program files (x86)"
Now use the trick from this answer to get the short name:
for %I in (.) do echo %~sI
Related
I was running some code on SAS that was generating data and for some reason, it froze. I quit the program and relaunched SAS, but noticed it didn't clear the memory. It's a lot of data, about 20 gigs, so losing that much space is more than I'm willing to give up. Normally, when I close and relaunch SAS it clears that memory, but this time it didn't, even after restarting the desktop (it's a Windows PC on Windows 10). Any suggestions or ideas?
Sometimes runaway processes that do not end gracefully will leave their temporary data in your WORK directory. Here are two ways to do it:
Use cleanwork.exe
Run the following in an elevated command prompt, where C: is the drive SAS is installed and your SAS WORK directory resides.
"C:\Program Files\SASHome\SASFoundation\9.4\cleanwork.exe" /v C:
This will search your entire volume for temporary SAS files and it could take a while. If you want to only clean your WORK directory and make it run faster, you can find it in sas9.cfg file. For example:
"C:\Program Files\SASHome\SASFoundation\9.4\cleanwork.exe" /d "%TEMP%\SAS Temporary Files"
Documentation
Delete it manually from WORK
To get to your WORK directory:
Open SAS
Type the following code:
%put %sysfunc(getoption(work));
Check your log. You'll see something like this:
C:\Path\_TD_<numbers and letters>\<id>
Go to the directory that the _TD is in.
Delete all files/folders in this directory that start with:
#TD
_TD
SAS_util
NOTE: If you are using Enterprise Guide, you can delete everything in the "EGTEMP" folder. If you're having issues deleting temporary files in it, check out Unlocker. It's a bit oldschool but still works on Windows 10! Great little tool.
I'm very new to LaTeX and its distributions so this might be a very newbie question.
I was following this tutorial and I'm not being able to compile the document. The code so far is very simple i don't think there are any typos and also I did not find a similar question in the forum.
can someone point me in the right direction ?
I'm using windows XP and I've installed TexMaker 4.4.1 found here
The code I have so far is simply:
\documentclass[11pt]{article}
\begin{document}
This is my first LaTeX document.
\end{document}
the error I'm getting is:
Could not start the command. pdflatex -synctex=1
-interaction=nonstopmode %.tex
Cheers !
If you meet the error:
Error : could not start the command
while executing TexMakerX commands in Windows 7 x64, it is probably due to environment path of LaTex compiler.
The following steps may help you solve this error:
Make sure that you did install a LaTex compiler like MiKTeX. You know, TexMakerX is just an editor of latex input, not a compiler.
Locate the bin directory in the installation directory of the LaTex compiler.
Add the directory of bin like d:\Program Files (x86)\MiKTeX 2.9\miktex\bin to the environment paths of Windows.
Right click computer in start menu, choose properties.
Find the "Advanced system settings" in upper left corner.
Click the button "Environment Variables".
Find the row of variable path in the group of "System Variables" and add bin path like ;d:\Program Files (x86)\MiKTeX 2.9\miktex\bin to the tail.
Remember to add a semicolon to separate different path.
Then, try it again...
I found this question on another forum and it says that you should install MiKTex for windows too. Worked like a charm !
I came across a page which mentions that MiKTeX has two major bugs due to which users haven't been able to compile at all.
Use TeX Live compiler instead
Source
https://wiki.lyx.org/Windows/TeXLive
Most of the time errors occur due to space in the file names. while saving the Latex file one should always remember don't put spaces in between the file name.
this is a self answered question, it may be useful to others.
After installation, trigger.io won't start if the installation path includes special characters such as accented letters.
I found such problem after installing trigger.io on a windows XP in spanish machine (trigger.io installs in "C:\Documents and Settings\USER\Local Settings\Application Data" which in spanish is "C:\Documents and Settings\USER\Configuración local\Datos de programa", there is an accented ó in the path).
The log file toolkit.log reported some kind of unicode error.
Here is a quickfix, assuming your filesystem is NTFS:
0. Uninstall trigger.io
create a junction point for "C:\Documents and Settings\USER\Configuración local\Datos de programa" to a path without special characters, such as C:\USER\appdata. You could use Mark Russinovich's junction utility to do that.
open regedit and go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Change the value for "Local AppData" to the new path and reinstall trigger.io.
By using a junction you don't have to copy the content from the previous dir to the new location, it's kind of a hardlink that works on directories.
IMPORTANT: this hack may have unintented consecuences on other applications, so use it at your own risk.
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.
I am attempting to install the IP3000 components into my Delphi 6 environment.
I figured I'd see if any of you have had experience getting it installed. From the files I have, there seems to be an installer missing (I have the UNWISE.exe).
I've tried including just about every folder in the environment's library path and browsing path and then build and install the packages (.DPK) with no luck.
Unfortunately, these Tww DB aware components are interleaved throughout my project so I can't get by without this package.
Any help is appreciated.
IME, most component install problems have some variation of the word 'path': Search Path (Delphi), Library Path (Delphi), System Path (Windows).
My advice is to put the *.bpl and *.dcu generated by the compilation in a path contained
in the Windows path (if you want to have some sanity on this, get the Rapid Environment Editor tool to deal with the Win path - which have a system one and user env one).
After dealing with that, install again. And:
Create a new vcl forms project
Put a random sample of their components on the form (if you can see then on pallete)
Press F9 to compile
So, if works, your install is complete. Don't try this with your own projects, as you can get nasty surprises when this fail....