Batch Processing in Vista vs. XP

[Kurash]

I have a customer who we built a screensave app for and it installs a configuration directory and a single .scr file in the windows/system32 folder.

Rather than have to manually navigate to the folder and remove it they want a quick method to remove the file. I wrote a .bat file and it works just fine on XP. Customer says it does not work on their Vista machine.

I don't have any experience with Vista so was wondering if anyone can provide some direction.

Here is the .bat file I wrote:

@echo off
cd c:\windows\syst em32
del "MyWiFi.scr "
echo y | del "MyWiFi dir"
rd "MyWiFi dir"

Thanks in advance for any assistance you can provide.

Lewis

[AmberJain]

Yeh, there had been such cases reported that some batch files don't work on Vista. But I don't know whether this is rumour or truth. But I expect this to be just a rumour or another outcome in vista due to some feature (or maybe a outcome due to backward compatibilty in VISTA). There would be certainly a way to do as you wish using some tweaking.

I don't have a Vista machine at my disposal or else I would have tested this thing. Next time whenever I am able to put my hands on a Vista machine, I would certainly investigate the matter.

============
AmbrNewlearner
============

[questionit]

Hi

Batch files are not very much windows friendly and you can not do many

things using it. Use VBScript instead - it is a much better alternate and is used only for Windows unlike batch file.

If you know VB then you can easily write a VBScript. There are many sample VbScript you can find on internet also.


Regards
Qi

[AmberJain]

Hi

Batch files are not very much windows friendly

You may be right but I'm of personal opinion that it is easy to learn, code, work and tweak with batch files. Almost every task (on a standalone machine) can be done using batch files. And so an average computer user need not learn VBS just to perform the tasks as posted in this thread by Kurash. i.e. just to perform---->

[CODE=txt]@echo off
cd c:\windows\syst em32
del "MyWiFi.scr "
echo y | del "MyWiFi dir"
rd "MyWiFi dir"[/CODE]

one need not learn VBS. Still if the person in consideration is interested in learning VBS, he may try to learn it.

and you can not do many things using it.

As far as I know about batch file programming, then a lot can be done using batch files.

Use VBScript instead - it is a much better alternate and is used only for Windows unlike batch file.

I repeat, if person in consideration is interested to learn VBS, then it is fine. But if he wants it to be done using a batch file, then we should help him to write a batch file which fulfills his purpose.
BTW, When you said,

and is used only for Windows unlike batch file.

you probably meant to say that batch files can also be used on DOS besides Windows OSes. (I don't know of other OSes which supports batch files). If batch files can be used on DOS+Windows, while VBS only on windows then it is better to use batch files as they can be PORTED to 2 OSes.

If you know VB then you can easily write a VBScript. There are many sample VbScript you can find on internet also.
Regards
Qi

Agree with you on this......


============
AmbrNewlearner
============

[questionit]

You may be right but I'm of personal opinion that it is easy to learn, code, work and tweak with batch files. Almost every task (on a standalone machine) can be done using batch files. And so an average computer user need not learn VBS just to perform the tasks as posted in this thread by Kurash. i.e. just to perform---->

[CODE=txt]@echo off
cd c:\windows\syst em32
del "MyWiFi.scr "
echo y | del "MyWiFi dir"
rd "MyWiFi dir"[/CODE]

one need not learn VBS. Still if the person in consideration is interested in learning VBS, he may try to learn it.


As far as I know about batch file programming, then a lot can be done using batch files.


I repeat, if person in consideration is interested to learn VBS, then it is fine. But if he wants it to be done using a batch file, then we should help him to write a batch file which fulfills his purpose.
BTW, When you said,

you probably meant to say that batch files can also be used on DOS besides Windows OSes. (I don't know of other OSes which supports batch files). If batch files can be used on DOS+Windows, while VBS only on windows then it is better to use batch files as they can be PORTED to 2 OSes.


Agree with you on this......

============
AmbrNewlearner
============

The main advantage of using VBS is that it is Windows friendly - it means it can perform some tasks that batch files cant (in Windows). Moreover, this was my suggestion, too for the questioneer since he wishes to implement something on Vista and he has been unable to use batch file in Vista enviroment - it is probably because the commands he has used in batch files are not supported in Vista's VDM (virtual dos machine).

Regards
Qi

[AmberJain]

The main advantage of using VBS is that it is Windows friendly - it means it can perform some tasks that batch files cant (in Windows). Moreover, this was my suggestion, too for the questioneer since he wishes to implement something on Vista and he has been unable to use batch file in Vista enviroment - it is probably because the commands he has used in batch files are not supported in Vista's VDM (virtual dos machine).

Regards
Qi

Never mind about my last reply #4,

but I will like to make it clear that although the batch file the questioneer wrote a batch file which is not working in Vista, even then there ought to be a way to perform the task using some alternative commands or option. It just need a bit of playing with commands to make them do what the questioneer want to do i.e. Vista's VDM might be different from previous versions of Windows OSes still there must be a way to do what questioneer want.

BTW, I'm just making clear what I think personally. These are my suggestions and opinions and nothing else. So never mind them.

THANKS.......

============
AmbrNewlearner
============

[klint]

Hi, I'm a new member and this is my first posting. I have a lot of experience of programming in batch in both Windows XP and older systems including MS-DOS, and was interested to read your post. I would like to offer a correction. The Command Processor runs under the Win32 Console, not the VDM. The VDM is a 16-bit DOS emulation layer, and has no relevance whatsoever to batch files, which run as full 32-bit windows console applications. The batch file language under Windows (NT, 2000, XP and Vista) is also much more advanced than the DOS version, and is fully aware of Windows-specific things.

I think the reason it's failing in Vista is UAC, or the over-zealous protection Vista imposes on system folders.

[AmberJain]

Hello klint,
Welcome to bytes.com.

I have a lot of experience of programming in batch in both Windows XP and older systems including MS-DOS, and was interested to read your post. I would like to offer a correction. The Command Processor runs under the Win32 Console, not the VDM.

Well, I indirectly disagree with this reply of yours. OK, I agree I was not clear in my reply. I mean to say that although cmd.exe runs under WIN32 console but command.com doesnot. On Windows NT family command.com runs under VDM. And for a guy like me (who loves to run FreeDOS as a separate OS on my PC to do what an ancient DOS user would do with MS-DOS) command.com is still the preferred choice over cmd.exe as I can replace my FreeDOS command interpreter [command.com] with the command.com available on Windows NT family (and it therefore supports portability across 2 OSes).

To add more, cmd.exe is a 32-bit binary executable (possibly 64-bit if you run a 64-bit version of windows). COMMAND.COM is a 8/16 bit DOS 1 compatible binary. This is the BACKWARD compatibility which must be maintained in all the future versions of Windows OSes (as backward compatibilty matters when it comes to OS development). And so when cmd.exe is typed in Run box in start menu and return key is pressed, then Windows TaskManager shows only one associated process [cmd.exe], while in case of command.com typed in Run, taskManager shows two new processes [cmd.exe] and [ntvdm.exe].

_NOTE_ ntvdm.exe is VDM on XP (it might also exist on Windows Vista with a different name but I don't have any idea as I don't run Vista).

The VDM is a 16-bit DOS emulation layer, and has no relevance whatsoever to batch files, which run as full 32-bit windows console applications.

I agree with this only if they are executed from cmd.exe and not from command.com. Command.com runs only under VDM. If you terminate (or kill) the ntvdm.exe process when command.com is running under taskmanager, then cmd.exe comes into action.

The batch file language under Windows (NT, 2000, XP and Vista) is also much more advanced than the DOS version, and is fully aware of Windows-specific things.

I agree with you about this.
To add more about capabilties of cmd.exe here's an excerpt from a blog---->

1. cmd.exe launches a windows NT command shell. NT's capabilities without the GUI (well as long as there's a program available for what you want to do or if you write one yourself). Long filenames, vastly extended batch language (try /? against each of pushd,popd,for, set,if for a start), command history, access to NT services and security model that aren't available with command.exe. multi-threaded. Disallows messing with memory owned by other processes.

cmd.exe is absolutely essential to any system administrator as a commandline scripting environment. Many can't do without it.

2. cmd does more things, one of my fav being the tab based auto complete, similar to that of Unix shells.

3. cmd.exe can create ANSI output by using the /a switch.

When it comes to command.com, here's more------------>

1. On NT-based systems, command.com launches a DOS window - an emulated Microsoft's DOS 16 bit command interpreter running in a window. 640k base memory + extended, no long filenames, all that jazz. Single thread. Allows DOS programs to run that expect to be able to write to memory with impunity (but is limited by the virtual machine to the 640k+extended that it can see). If you want command history, you run doskey.exe, as you would in DOS. Yes, only really useful for backward compatibility.

2. It is recommended to use COMMAND when MS-DOS programs may not be able to be ran in Windows NT.

3. The old command.com honors ANSI escape sequences like any decent vt100 terminal or emulator since the 1980s.

More information can be found below-------->

.EXE files were a late arrival to DOS, allowing for programs larger than 64K. A .COM file has no header, so does not require relocation in memory. The CS and DS pointers point to the same 64K conventional memory page, all addresses are 16-bit so you cannot address any memory outside you programs 64K page. EXEcutables allow you to set a different DS (Data Segment) and CS (Code Segment) page, taking your programs to 128K and you can add a seperate SS (Stack Segment) and ES (Extra Segment) all witout using any Memory manager.

The Executive Kernel of DOS 3+ (And some extended versions of DOS 2) will allocate these memory pages for you according to the EXE Header. .COM files have no header. EXE defines an MZ header, but when the 386 came along with Protected and Extended modes for 32-bit processing, we aquired true 16-bit LE headers in .EXE files for Windows 3.1.

The PE header was added for true 32-bit executables in Windows NT2, as taken from Microsoft OS/2 before that became IBM OS/2 v2. PE was ported to DOS based windows Kernels with the Win32s extension to Windows for Workgroups 3.2, optionally, you can add this to Windows 3.1. It was finally the standard executable format on Windows 95 and up.

The fact of the matter is that the APIs provided by cmd.exe are true 32/64 bit windows APIs and are far to complex for any DOS based system.

It's not a matter of adding backwards compatibility to cmd.exe, it's a case of what you could not do with cmd.exe if it had to be run under the 16-bit VDM (Virtual DOS Machine) or WOW (Windows16 On Windows32, that's 16-bit Windows applications on a 32-bit Windows Kernel) as COMMAND.COM does.

For many 16-bit applications to work under VDM or WOW, the standard COMMAND.COM has to be accessible to them. 64K page frames don't exist once the processor is bumped into 32-bit Extended / Protected mode, so it is not possible to run .COM files without the VDM virtualisation that emulates those CPU features to the application. However, 16-bit applications will expect COMMAND.COM to be in a certain 64K page frame. Once in that Virtual Machine you have no access to the 32-bit APIs of Windows.

Many extension, for long file names and Workgroup LAN access and such have been added to more recent Windows versions after 3rd party developers made their money from them in the bad old days of Windows 3.1. Essentially using a copy and paste, system between 16Bit virtual code and 32Bit native code applications. But this is very slow. Windows NT and OS/2 have always had a cmd.exe native to them. Adding back COMMAND.COM is only so that 16Bit applications designed for DOS or 16/32 hybrid Windows versions can call "COMMAND.CO M" and load it in the same 16Bit Virtual Machine as they are running.

I hope this makes things clearer.

For Your Information, this traditional trend of physical architectural change to PCs and the havoc it wreaks on backward compatibility while taking advantage of the much needed technological improvements of those architecture changes, is probably Microsofts real reason for wanting developers to switch to producing .Net code, which is not compiled to a native Binary form, but rather interpreted or JIT compiled (compiled as the executable is loaded from disk, into memory).

Despite the fact that this makes programs load up slower from disk, and execute slower on the PC it leaves iNTEL, Motorola and AMD free to change their CPUs as much as they want, and leave the OS to handle how the executable is actually run. Meaning they all make more money, and we (the users) stop winging that our applications don't work on our new PC, and they don't need to add 15 layers of virtualisation for backward compatibility. (See VDM, WOW, WOW64 etc or Apples Fat Binaries, Universal Binaries and Classic compatibility layers and X-Windows Server) Open Source Applications and Operating systems hold a distinct advantage in this field. Especially the Unicies, (Unix, Linux, BSD, HP-UX and Solaris) because they traditionally expect the user to modify the source files, headers etc. and compile the source for their platform as part of the installation process. Programs which depend on other programs will therefore never make assumptions about what hardware they are running on, and never modify code in memory as many DOS and 16-bit Windows applications did.

It also means you can install the exact same program on your ARM based palmtop PC as your desktop Intel/AMD PC, without there being two different binary code files to do the same job on the different platforms. The reason why PowerPC and DEC Alpha versions of Windows NT 4 and 2000 failed to make a dent in any market at all. There's more Apple and NeXT software for PPC and more Sun/Solaris and HP-UX software for DEC Alpha than there is Windows Software compiled for either processor.

I think the reason it's failing in Vista is UAC, or the over-zealous protection Vista imposes on system folders.

I don't have any idea about this as I'm not on Vista.





HOPE THIS EXPLAINS WHAT I MEANT.......... .........

============
AmbrNewlearner
============

[klint]

Hi AmbrNewlearner, that's very interesting. I used to do lots of low-level stuff on DOS and was familiar with its memory model, but that was more than 10 years ago. Nowadays, I never use command.com but always use cmd.exe instead. I don't have any old DOS programs so I'm not worried about backward compatibility. I guess that most people writing a new batch file will not need to worry about backward compatibility either, and therefore they are better off using the new features of cmd.exe

[firozfasilan]

I think you can run batch file on windows vista also........... ..
for that right click on it.......and choose runas administrator option....
..i hope this will also work