I've noticed subtle differences in [exec]ing a batch file on MS Windows with or without prepending the call with the command interpreter, cmd.exe.
Here's an example:
======
(portal_01024) 2 % cd c:/iskv/portal_01024
(portal_01024) 3 % glob *
config cti dist help resource resource_cti start_portal.bat
(portal_01024) 4 % exec -- start_portal.bat
Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar        <==== batch starts, but somethings going wrong internally
Das System kann den angegebenen Pfad nicht finden.
(portal_01024) 6 % exec -- cmd.exe /c start_portal.bat &            <==== this works the same way as if i call the batch from outside of tcl
4660
(portal_01024) 7 % exec -- [auto_execok start_portal.bat]           <==== didn't help
Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar
Das System kann den angegebenen Pfad nicht finden.
======
----
Don't know what's going on yet.

If I use '''[auto_execok] xyz.BAT''', it gives back '''./xyz.BAT''', which makes not much sense, since Batches are always interpreted by the command interpreter, cmd.exe, on windows, and ar not executable by themselves. exec bat and exec [auto_execok] are basically the same and both don't work for me in all cases, since the environment of the BAT is then different than if called via cmd.exe.

   * '''So What does tcl do when execing a BAT? It must be something different than execing cmd.exe /c bat.'''

Thru a simple echo and pause, I discovered the difference which leads to an error:
======
(portal_01024) 24 % exec -- start_portal.bat
c:\iskv\PORTAL~1                                     <============ without cmd.exe /c, the system uses SHORT FILENAMES..... WHY?????????
Druecken Sie eine beliebige Taste . . . 
Unable to access jarfile c:\iskv\21c_winbk_\bin\csvstart.jar
Das System kann den angegebenen Pfad nicht finden.
(portal_01024) 25 % exec -- cmd.exe  /cstart_portal.bat
c:\iskv\portal_01024
Druecken Sie eine beliebige Taste . . . 
(portal_01024) 26 % 
======
Unfortunally, there's no way to retrieve a long from a short filename, so I cannot work around this...

[APN] Does file attribute -shortname/-longname not help ?

[MHo] No, as the called BAT is a Windows Batch procedure, not a tcl script. The thing is, that the called BAT sees a short filename as it's own name (%~dp0) in one case, and a long filename in normal cases. That is something that's out of the tcl scripters scope, in this case.

[MHo] Addition: One can simply reproduce the (I think) wrong behaviour:

1. Create a simple batch file which resides in a folder with "long file name" components (that is, subfolder names longer that 8.3) like this:

======
@echo (((This is the folder from where I get called: %~dp0)))
======

2. Execute this batch from a cmd.exe windows, this gives:

======
(((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\batchExecTest\)))
======

3a. Execute the batch from within tclsh via exec, method 1 - somethings going wrong:

======
% exec -- ./batch1.bat
(((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\BATCHE~1\)))
======

3b. Execute the batch from within tclsh via exec, method 2 - result is correct:
======
% exec -- cmd.exe /cbatch1.bat
(((This is the folder from where I get called: d:\Home\Hoffmann\pgm\tcl\usr\Src\menue\batchExecTest\)))
======

I hope it's not that command.com, the 16bit MSDOS command processor is called in case 3a.....