Is there any way to copy some files from an internal online storage to a local drive by using a *.bat-file on Windows XP?
Due to some strange internal restrictions I am only allowed to use a *.bat-file to do this.
The path to the files, which are to be copied, is kinda "http://files.in-house/section/linkages"
So I tried xcopy (xcopy goto.in-house/section/linkages U:\linkages) in any variations, with quotation marks, without etc. but it does not work
a) is there any way to do this?
b) how?
Very similar to a question asked on SuperUser.com, here. The accepted answer uses vbscript, which is not installed in all WinXP systems. To check if you have it, just type cscript at a command line prompt. If you need to download it, it's here.
The number two answer relies on bitsadmin, which is not part of XP, but can be obtained with the Windows XP Service Pack 2 Support Tools.
Related
I'm building a lightweight version of the ncurses library. So far, it works pretty well with VT100-compatible terminals, but win32 console fails to recognise the \033 code as the beginning of an escape sequence:
# include <stdio.h>
# include "term.h"
int main(void) {
puts(BOLD COLOR(FG, RED) "Bold text" NOT_BOLD " is cool!" CLEAR);
return 0;
}
What needs to be done on the C code level, in order that the ANSI.SYS driver is loaded and the ANSI/VT100 escape sequences recognized?
[UPDATE] For latest Windows 10 please read useful contribution by #brainslugs83, just below in the comments to this answer.
While for versions before Windows 10 Anniversary Update:
ANSI.SYS has a restriction that it can run only in the context of the MS-DOS sub-system under Windows 95-Vista.
Microsoft KB101875 explains how to enable ANSI.SYS in a command window, but it does not apply to Windows NT. According to the article: we all love colors, modern versions of Windows do not have this nice ANSI support.
Instead, Microsoft created a lot of functions, but this is far from your need to operate ANSI/VT100 escape sequence.
For a more detailed explanation, see the Wikipedia article:
ANSI.SYS also works in NT-derived systems for 16-bit legacy programs executing under the NTVDM.
The Win32 console does not natively support ANSI escape sequences at all. Software such as Ansicon can however act as a wrapper around the standard Win32 console and add support for ANSI escape sequences.
So I think ANSICON by Jason Hood is your solution. It is written in C, supports 32-bit and 64-bit versions of Windows, and the source is available.
Also I found some other similar question or post which ultimately have been answered to use ANSICON:
How to load ANSI escape codes or get coloured file listing in WinXP cmd shell?
how to use ansi.sys in windows 7
How can I get cmd.exe to display ANSI color escape sequences?
ansi color in windows shells
enable ansi colors in windows command prompt
Starting from Windows 10 TH2 (v1511), conhost.exe and cmd.exe support ANSI and VT100 Escape Sequences out of the box (although they have to be enabled).
See my answer over at superuser for more details.
Base on #BrainSlugs83 you can activate on the current Windows 10 version via register, with this command line:
REG ADD HKCU\CONSOLE /f /v VirtualTerminalLevel /t REG_DWORD /d 1
For Python 2.7 the following script works for me fine with Windows 10 (v1607)
import os
print '\033[35m'+'color-test'+'\033[39m'+" test end"
os.system('') #enable VT100 Escape Sequence for WINDOWS 10 Ver. 1607
print '\033[35m'+'color-test'+'\033[39m'+" test end"
Result should be:
[35mcolor-test[39m test end
color-test test end
Starting from Windows 10, you can use ENABLE_VIRTUAL_TERMINAL_PROCESSING to enable ANSI escape sequences:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx
If ANSICON is not acceptable since it requires you to install something on the system, a more lightweight solution that parses and translates the ANSI codes into the relevant Win32 API console functions such as SetConsoleTextAttribute.
https://github.com/mattn/ansicolor-w32.c
For coloring the cmd you need Windows.h and use SetConsoleTextAttribute() more details can be found in http://msdn.microsoft.com/en-us/library/windows/desktop/ms686047%28v=vs.85%29.aspx
In lastest win10, it can be done by SetConsoleMode(originMode | ENABLE_VIRTUAL_TERMINAL_PROCESSING). See https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example
Maybe ANSICON can help u
Just download and extract files, depending on your windows os: 32bit or 64bit
Install it with: ansicon -i
I personally like clink. It not only processes ANSI codes, it also adds many other features so Windows Console behaves like bash (history, reverse history search, keyboard shortcuts, etc.):
The same line editing as Bash (from GNU's Readline library).
History persistence between sessions.
Context sensitive completion;
Executables (and aliases).
Directory commands.
Environment variables
Thirdparty tools; Git, Mercurial, SVN, Go, and P4.
New keyboard shortcuts;
Paste from clipboard (Ctrl-V).
Incremental history search (Ctrl-R/Ctrl-S).
Powerful completion (TAB).
Undo (Ctrl-Z).
Automatic "cd .." (Ctrl-PgUp).
Environment variable expansion (Ctrl-Alt-E).
(press Alt-H for many more...)
Scriptable completion with Lua.
Coloured and scriptable prompt.
Auto-answering of the "Terminate batch job?" prompt.
Ansi.sys (in the system32 folder) is an "MSDOS driver" provided as part of Windows XP, 2000, and earlier versions of NT. In 2000 and XP, it is located in the system32 folder (I don't remember the structure of earlier versions of NT). Programs that run in the DOS subsystem and use standard output can use ANSI.SYS just as they could running over MSDOS.
To load ansi.sys, you must use the device= or devicehigh= command in config, just as you would in MSDOS. On Windows NT 5 (2K & XP), each copy of the DOS subsystem can be given a separate config file in the pif/shortcut (use the "advanced" button), and there is a default file called CONFIG.NT (also in the system32 folder), which is used if the pif/shortcut does not specify a special config file.
When ansi.sys is loaded correctly, mem /d will report that it is loaded. On earlier versions of NT, you can and must load a proper DOS environment to load ansi.sys, and ansi art will work at the prompt. On Win 2K and XP, loading ansi.sys will have no effect on your "CMD prompt" because CMD is not a DOS program: it is a 32 bit Windows console program. For some reason that I do not understand, on WinXP, even if you load a fixed copy of command.com using "command.com /p", the command prompt will not be ansi enabled: perhaps when you do it that way it only emulates loading command.com?
In any case, when you use an actual DOS version of command.com, ansi is enabled after being loaded: you can demonstrate it's use with a bit of ansi art like this:
command /c type ansiart.ans
(here is an example: http://artscene.textfiles.com/ansi/artwork/beastie.ans)
CONFIG.NT (in the system32 folder) contains an example of the syntax for loading device drivers. You will need to be an Administrator to edit that default file, or you can make a copy of it.
On Win 2K and XP, the default "shortcut" for MSDOS is a .PIF file, not a .LNK file. If you create a .lnk file to CMD, you won't be able to set special config and autoexec files, it will use the default CONFIG.NT. If you want to use a special config file for just one DOS application, you can make a copy of the "MSDOS shortcut", or you can make a copy of "_default.pif", found in your Windows folder.
Had the same issue. I installed ConEmu and that one solved my problem.
I found this tool to be working for my end.
Microsoft Color Tool from GitHub
Unzip the compressed file then open CMD with Administration permission.
Go to the folder where you unzip the file in CMD.
Then execute this command "colortool -b scheme-name"
The scheme-name needs to be replaced with any of these options below:
campbell.ini
campbell-legacy.ini
cmd-legacy.ini
deuternopia.itermcolors
OneHalfDark.itermcolors
OneHalfLight.itermcolors
solarized_dark.itermcolors
solarized_light.itermcolors
In my case, the command would be like this "colortool -b solarized_dark.itermcolors"
Click right on the console window and select Properties.
You don't need to change any value just click "OK" to save the setting. (You will notice that your font already contains colors).
Console Property
Then restart your cmd or powerShell.
The ANSI color should be enabled and working with the color scheme you chose before.
Somehow in Windows you just need to call any shell command first, rather call the system function. Just in start of your main method put system("");, and don't forget to include stdlib.h.
I noticed this when I looked at some of my old programs that also used ANSI codes to understand why they work, but my new code is not
because Bitsadmin is getting deprecated I would like to hear if you know about an alternative to Download files from within a batch script.
Best would be an alternative that already comes with windows so I don't need to download extra stuff.
Bacon Bits and I had the same idea at the same time. Here's an example using PowerShell's BitsTransfer module. Save this as a .bat file and run it.
#echo off
setlocal
set "URL=http://cdn.sstatic.net/stackoverflow/img/sprites.svg"
set "SaveAs=sprites.svg"
powershell "Import-Module BitsTransfer; Start-BitsTransfer '%URL%' '%SaveAs%'"
Good news -- BitsAdmin isn't being deprecated.
(I work for the BITS team at Microsoft)
The best alternative to BITSAdmin.exe is to use PowerShell.
If you cannot use PowerShell, you're pretty much stuck with copy, xcopy.exe, and robocopy.exe.
How can I download a file with batch file without using any external tools? - you can check this
Probably the powershell is the best alternative Though you still can find vista and XP machines without powershell - if portability is important for you
go to WSH.
.I don't think MSXML2.XMLHTTP and WinHTTPRequest (here I've a little bit more powerful tool based on winhttprequest - and more tested ) are going to be deprecated any time soon but they will require WSH or jscript or vbscript or powershell.
jscript.net and webclient will work better for bigger files.
I know this isn't strictly a programming related question, but I cannot seem to find an answer.
In what year was Batch created? Or is it more appropriate to talk about the year CMD was created? In which case - in what year was CMD created?
I apologize if this question is against the rules in any way. The reason I ask is to participate in a challenge over at the Code Golf StackExchange site.
Do you need to distinguish the command.com and cmd.exe ?
Command.com - was the command line interpreter from the earliest versions of DOS and QDOS created by Tim Paterson (around 1981) , but the command.com also passed through a lot of changes and may be the most drastic in its 5th version.
MSDOS 1.0 supported commands - (CD COPY DEL DIR EDIT FORMAT HELP MKDIR RD REN TYPE )
In MSDOS 5.0 (1991) more advanced commands were introduced - (even microsoft keeps a documentation for it) and may be its a little bit closer to a programing language.
In 1993 Windows NT was released packed with the new cmd.exe (along with the old command.com) created by Therese Stowell - it has a lot new features like additional switches for FOR and IF commands , subroutines and etc. And this is the 'modern' batch-scripting what we know today (though it is close to the ms-dos 5 command.com).
This has cost me some time in googling but hope the info is enough :)
The earliest reference to batch files is 1981, with the release of IBM PC DOS 1.0 - it used the file AUTOEXEC.BAT to run various commands at startup.
And imo this question falls into a grey area regarding whether or not it's on-topic; there's no specific programming question, but it's still related to programming, and that's apparently okay according to the review audit that I recently failed.
MSDos was based on CP/M features for compatability. Unix type features added in in Ver 2. CMD started as a command shell that would run MSDos batch files but have added features in OS/2 (IBM not MS did CMD). CMD got taken into NT and there are two main versions pre Win 2000 and post Win 2000. Prior to Windows 2000 Dos batch files and programs ran in the OS/2 sub system, not the Dos emulator in the Windows sub system.
The command.com in Windows now is ver 5.5 and passes all commands to cmd to execute unless started like this command.com /k ver (compare that to typing command.com then ver).
I don't remember exactly when I bought my first PC computer, but it should be around 1984 or 1985; it was a "PC clone" Printaform computer that featured MS-DOS 2.11 with Batch files executed by command.com program. I vividly remember that the Batch features of that time were enough to write many interesting programs. It had variable management via SET command and %variable% value replacement, and FOR, IF and CALL commands, including recursive subroutines.
Shortly after that I read an article in Dr. Dobb's Journal that show me how to modify command.com's environment variables from a running program, so I wrote my first program of this type, LET.COM, that allowed me to perform advanced variable management in Batch files, like arithmetic operations, data input, etc. many years before the modern cmd.exe Batch file features.
You may review the history of MS-DOS development, including Batch file features, in many sites in the web, like this one in Wikipedia.
I make a fair amount portable Apps for personal use and they work perfectly for the most part. I do, however, find it quite frustrating that if I run them on another computer none of my preferences are retained, as a program always looks in appData for the configuration files (which obviously don't exist on another system), so I'm wondering whether there is some kind of command line to launch an .exe with a custom .ini location.
I'm asking this firstly because Google has proved fruitless (once again) and secondly because I know it's possible - I've actually done this before, but with only one of my Apps. I accomplished this by launching the App via the command programFile.exe -f configFile.ini /s (I have also seen programFile.exe -d -f configFile.ini /s elsewhere). Naturally, I thought I would try to apply this to some other Apps but it seems it only works for that particular App.
So, is there a command/switch that I am unaware of that will do this for an .exe file?
Thanks
It really depends on each executable file you are using. Some have support for what you are looking for, and some don't. Some programs don't even use .ini files. What you should look for is if each and every program you use have support for user data custom location.
Edit
The only case where generic arguments would be avaialble for a group of EXE files is if they are generated with the same tool, which automatically provides these arguments for you. InstallShield and MSI install programs have that kind of feature (with the silent install and automated installation for instance).
I suggest you look into the tool you are using to generate your portable Apps, and see if it does provide those generic arguments for you, and how they work. If it does not have that feature, then look into the Apps you were able to specify a custom location for your INI file. Somewhere into the code, there must be a piece of code that handles the arguments you specify to the EXE file and handles them. You should share that piece of code with your other Apps, to make sure they provide the same arguments list.
I am running my development environment Windows XP. I need access to the function SHGetKnownFolderPath. My team proposes that I simply update my shell32.dll with theirs and update my header files.
The function is documented here:
http://msdn.microsoft.com/en-us/library/bb762188%28v=vs.85%29.aspx
Now, understand that the focus of this question is on the viability of overriding/updating the shell32.dll manually via copy-paste. Please do not respond with workarounds/alternatives to the function mentioned above. That is not the point of this question.
Is it safe to simply take the Windows 7 version of shell32.dll and paste over mine (in XP)? I am afraid to test that for fear of murdering my entire operating system. I do not know all of Windows' library inter-dependencies and whether this would even be compatible. It sounds incredibly unstable, but that is what is being proposed I do.
You should not change a Windows DLL manually. A Windows 7 DLL will have dependencies that will not resolve on XP. Even if this worked (very unlikely), next time you install a patch from Windows Update it may either break due to dependencies or replace your Windows 7 DLL back to XP version.
UPDATE: This just won't work. The Windows 7 DLL has dependencies on API sets which did not exist in XP.
Copying manually the dll via copy-paste will not work, because WFP will kick in and restore the original dll. IIRC only digitally-signed updates from Microsoft are allowed to replace system dlls on a running system to avoid messes like this. You should replace the file offline (e.g. from another copy of Windows/BartPE/Linux/...), or disable/workaround WFP in some way. So, it's not practical.
Taking a system dll from another version of Windows and copying it there seems like a terrible idea. The shell changed a lot from Windows XP to Windows 7, I'm sure that there will be a lot of missing dependencies. Even if you managed to copy every file of the Windows 7 shell to Windows XP, these files would depend from newer user32/gdi32/ntdll/... functions added in Vista and 7, so it would not work anyway.
So, I think that the most probable consequence of replacing shell32.dll would be the failure to load almost any non-core component of the OS: failing shell32.dll to load due to missing dependencies, almost any GUI executable that links against it would fail to start. So, it's not safe.
Other than being a problem from a technical standpoint, I strongly suspect that it's also illegal. Having a license for both Windows XP and Windows 7 would not help, I think that this is considered "modification of the software product", that is explicitly disallowed by the Microsoft EULAs. So, it's not legal.
If you want backwards compatibility with XP just use SHGetFolderPath instead of doing all this mess.
Is it safe/practical to manually update shell32.dll in
Windows XP?
No.
shell32.dll is a core operating system file. I would expect that minus the other dependencies underneath the Windows 7 version you would have all sorts of unexpected behaviors. It would be better to test within a VM a complete Windows 7 environment rather than copy over a part of another version of an operating system.
Bigger questions: Do you think anyone at Microsoft every tested this exact combination? If you run into issues and you call support do you believe that you will find that your configuration is a supported one for your efforts? Having worked for MSFT in the past I would think that the answer to both is likely not.
Probably they know what they're saying. Anyway I would suggest you creating a system restore point and, just in case, downloading a minimal linux distribution so that, in extreme cases (i.e. windows can't boot), you simply restore their shell32.dll with yours.
I don't think so...
But if still want to try, then i suggest you install a virtual machine and try it there. this way much safer.