This may come to a surprise to some of us, but about 2 years back engineering guys implemented a batch logon script which is run on in Windows XP workstations. The domain controllers are centralised to Singapore and the small branches (e.g. Thailand) logon to the DC in Singapore.
A strange thing happened at logon, it was taking a few minutes to execution. We all thought that it was the bandwidth was causing the problem, it couldn’t be the XP machines, since they are new and no way would execute a simple logon script that slowly. However, the bandwidth was found to be acceptable and so I had a look at the logon script. Nothing unusual with it, its a few lines and calls some other routines.
So I modified the logon file and piped “time /t” commands between codes to see where it was slowing down. The result was interesting, it took a few minutes to execute the starting portion of the logon script. When I looked at it, there was no routines or programs being executed, only REM as part of documentation and change history. It was just too weird, I had thought that REM would not cause any penalties to the execution cycles. Disbelieving myself, I took all the REM statements out and the logon script went through at normal speed!
This was 2 years ago, so I don’t know if it has changed much, but my conclusion went something like this:
- REM statements are evaluated in Windows and takes up cycle time.We don’t notice them most of the time because of the speed of execution. However, because the batch file was run from a moderate to low bandwidth location across a WAN, this becomes obvious.
- The execution engine for BAT (legacy DOS) and CMD are different. The logon file was running as a BAT file uses possibly a 16-bit DOS engine, whereas CMD used the 32-bit engine. I tested the same batch file by renaming it to CMD and it ran perfectly. (I cannot find any reference for this, so I might be wrong).