|
Post by daryl on Sept 5, 2019 7:55:25 GMT 1
Trying to run VDos with an application which calls a batch file, it seems to call "cmd /c \runit.bat" but it just flashes up quickly and never actually runs?
The batch file is supposed to call an external app (sftp) to download some info for importing but since it cannot grab this info it fails at this point, is there anything that can be done to remedy the issue?
|
|
|
Post by Jos on Sept 5, 2019 8:57:36 GMT 1
Change the line to "cmd /k \runit.bat", or add PAUSE to the end of runit.bat, so the Windows command line processor (CMD) will be kept open.
C: in vDos doesn’t match that of Windows. CMD expects Windows paths, so runit.bat in "cmd /c \runit.bat" would have to be located in (Windows) C:\. Not vDos C:\, probably Windows C:\vDos\.
Jos
|
|
|
Post by daryl on Sept 5, 2019 10:40:12 GMT 1
Change the line to "cmd /k \runit.bat", or add PAUSE to the end of runit.bat, so the Windows command line processor (CMD) will be kept open. C: in vDos doesn’t match that of Windows. CMD expects Windows paths, so runit.bat in "cmd /c \runit.bat" would have to be located in (Windows) C:\. Not vDos C:\, probably Windows C:\vDos\. Jos Hi Jos, The path is hard-coded into the application which I cannot change, the batch file itself consists of "SFTP.exe -s:<servernamehere>" the cmd /c is part of the log files collected from the application when running vDos with "/log" and hitting return on the menu item to download the relevant files and import them this is not something I have access to change. Even if I have the runit.bat in the root folder of where the application is running from or the vDos "C:\" mapping it still does not seem to run it, if I type the command manually it flashes up and closes but if I remove the leading "\" on runit.bat it works?
|
|
|
Post by Jos on Sept 5, 2019 11:25:25 GMT 1
What if you try "cmd /k \runit.bat" manually?
Jos
|
|
|
Post by daryl on Sept 5, 2019 15:37:02 GMT 1
What if you try "cmd /k \runit.bat" manually? Jos Works fine if the runit.bat is in the root folder but it's actually under a subfolder in this instance the output of the log file is cmd /c \bbsconfig\runit.bat if I run cmd /k \bbsconfig\runit.bat it says it cannot find the path specified but at least it doesn't just flash up and vanish, if I remove the leading "\" before bbsconfig it can find the file but I cannot edit this as it's hardcoded in the application.
|
|
|
Post by Jos on Sept 5, 2019 16:07:35 GMT 1
What is the current work directory shown by CMD (cmd /k \bbsconfig\runit.bat). So what location does \bbsconfig address.
Jos
|
|
|
Post by daryl on Sept 6, 2019 7:51:46 GMT 1
The current work directory is mapped as P:\ with bbsconfig being a folder under the root of P:\ with the batch file within. The application is also in P:\ so we simply run the exe from the root of P:\
It maps to a network share outside of vDos, the log file literally shows 'COMMAND.COM - /C cmd /c \bbsconfig\runit.bat'
|
|
|
Post by Jos on Sept 6, 2019 8:41:41 GMT 1
At the vDos command prompt, did you: C:\>P: P:\>cmd /k \bbsconfig\runit.bat
CMD requires the current work directory to be a (mapped) drive letter, while vDos internally uses UNC paths. The current version also sets the current work directory to the corresponding UNC path. CMD then just quits, or changes it to the Windows directory (C:\Windows).
Jos
|
|
|
Post by daryl on Sept 6, 2019 16:04:33 GMT 1
At the vDos command prompt, did you: C:\>P: P:\>cmd /k \bbsconfig\runit.bat CMD requires the current work directory to be a (mapped) drive letter, while vDos internally uses UNC paths. The current version also sets the current work directory to the corresponding UNC path. CMD then just quits, or changes it to the Windows directory (C:\Windows). Jos In the autoexec we use "Net use P: \\<server ip>\<share>" then we go to P:\ and run the executable for the main application all within autoexec file so no user interaction is required. The application itself has menu items which, when the user chooses them, should effectively run this batch file behind the scenes (I have only gathered this from the vDos logs and error messages provided from the app itself) The application then throws up an error stating it cannot connect to the BBS Server. What should happen is it runs a file called "Runit.bat" which has some code to call "SFTP.exe -s:BBSConfig.scr" which is a simple document containing the input lines to open a connection to the BBS server, login, access the folders, download the files and disconnect. It then imports the information via some internal process which I don't know anything about myself, unfortunately since this batch file fails, the "FindFirst" that it tries to use to determine whether or not the files exist fails and this it cannot continue and throws the error message "Cannot connect to BBS Server" So to answer your question, the application is automatically executed from P:\<appname>.exe in vdos where P:\ is mapped to the servers network share, the "cmd \c \BBSConfig\runit.bat" is part of the output log file which is recorded when the user presses on the menu option within the application itself and is not something I can see or have access to change myself as it's hard-coded into the application.
|
|
|
Post by Jos on Sept 6, 2019 17:18:05 GMT 1
Before the Windows command line processor CMD.EXE (cmd /c \runit.bat) is started, vDos sets the Windows current work directory to the UNC path that matches the DOS current work directory at that moment. So that will be \\<server ip>\<share>\<probably more>. An inheritance of DOS (compatibility) is that CMD.EXE requires a drive letter based path. It however starts off with that UNC path, not <drive letter>:\<probably more>. CMD.EXE will then either just exit, or complain and switch to the Windows directory. So the current work directory will become C:\Windows, NOT \\<server ip>\<share>\<probably more>.
If you execute at the vDos command prompt: C:\>P: P:\>cmd /k \bbsconfig\runit.bat
You can at least verify that. If CMD.EXE switches to the Windows directory, you should be able to work around that in the batch file.
Jos
|
|
|
Post by daryl on Sept 11, 2019 16:40:20 GMT 1
Before the Windows command line processor CMD.EXE (cmd /c \runit.bat) is started, vDos sets the Windows current work directory to the UNC path that matches the DOS current work directory at that moment. So that will be \\<server ip>\<share>\<probably more>. An inheritance of DOS (compatibility) is that CMD.EXE requires a drive letter based path. It however starts off with that UNC path, not <drive letter>:\<probably more>. CMD.EXE will then either just exit, or complain and switch to the Windows directory. So the current work directory will become C:\Windows, NOT \\<server ip>\<share>\<probably more>. If you execute at the vDos command prompt: C:\>P: P:\>cmd /k \bbsconfig\runit.bat You can at least verify that. If CMD.EXE switches to the Windows directory, you should be able to work around that in the batch file. Jos Right you are, UNC path not supported, still no way of working around this in the batch file, however I have managed to determine the process behind the system which is "SFTP.exe -s:bbsconfig.scr" this file basically contains line by line instructions to login to their FTP server, grab 2 files and store them in the local directories, after this is done the user can simply run the import process from within the application. I have given the user a simple batch file which does the equivalent of this SFTP call manually, they should be able to tell me if it worked by next week, if all goes well then we have a solution for now. Thanks for your help. If you have an alternative to make the UNC path failure work and reference the file correctly then I'm all ears.
|
|
|
Post by Jos on Sept 11, 2019 19:17:06 GMT 1
Well, no real (nice) alternative since you cannot change that “/C cmd /c \bbsconfig\runit.bat” command. Also COMMAND.COM is called by your program, not C:\COMMAND.COM as defined by the COMSPEC environment variable. Executing “cmd /k \bbsconfig\runit.bat” by hand gave you: So the only option with the current vDos version would be to copy runit.bat to (Windows local) C:\bbsconfig\runit.bat so it will actually be found by CMD. Jos
|
|
|
Post by daryl on Sept 16, 2019 7:48:30 GMT 1
Yeah, I tried that first and foremost but it still failed, that's why I came here Waiting to see if the manual workaround works, it's not ideal but it's good enough. The program is referencing to the comspec because when I changed it the error message became different accordingly.
|
|
|
Post by daryl on Sept 18, 2019 10:31:27 GMT 1
I have an intermittent issue with "Pagefault - directory or table entry not set" when it tries to create a CSV file but this seems to be random? Once it occurs it happens every time after? any reason for this?
|
|
|
Post by Jos on Sept 18, 2019 11:15:04 GMT 1
Page fault errors have been around since vDos supports virtual memory paging in protected mode as used by FoxProX (PharLap DOS extender). It means the program is referring a virtual memory address for which no directory or table entry is setup by the program.
The vDos download page states: “Long awaited fix of the occasionally (and illusive) Page Fault errors with FoxProX”. And I thought they were finally fixed with version 2019.05.01. It surely doesn’t occur as frequent as before, but you’re the third to report they still exist. I did meanwhile find an extremely rare situation that could cause a page fault. But fixing that didn’t resolve it either (for the one who tested).
A page fault forces vDos to shut down since it can’t resolve the given virtual address to a linear one. When vDos is restarted, it (of course) has no knowledge of previous page fault errors in a different instance. So there’s no vDos related “Once it occurs it happens every time after. For now you simply have to live with that error. I suppose you don't start a second FoxProX program from inside the first one.
Jos
|
|