USE C: from network share

[dave]

My question may be similar to mrc2048's, but I think it's a little different.

I would like to run vDos from a network share, and be able to access a data folder, let's call it "C:\Folder". If I can get this running, I'm keen to buy a site license and kill off our 32 bit machines.

With the latest vDos 2018.05.01, I have found I can only USE C: C:\ if vDos is started from the local drive.

If vDos is started from a mapped drive, C: can't seem to be reassigned even in autoexec.txt. It returns "C: is already assigned".

I saw, and tried, your note about adding a "Start In", but that requires all the config.txt, autoexec.txt, etc. files to also be localized into C:\Folder, which defeats the purpose of defining (and protecting) them in the network share.

I tried vDos 2015.04.10, and C: can be reassigned just fine, even when started from a mapped drive. I think this is what mrc2048 was referring to in his second post. But this previous vDos version has other issues that make it unworkable for us.

The only alternate option I can see is to USE F: C:\Folder.

We do have some ability to tweak the software that will be running, but there are more than 400 programs that would need to be modified and recompiled if we want to change the path from C:\Folder to F:\. Even after all that work this is still not ideal, as after the files saved from F:\ they are automatically opened by the software into Windows, which needs to be as "C:\Folder..." from the users perspective instead of "F:\…".

I tried the spinoff project, vDosPlus. It also allows us to USE C: C:\ and while it has some other great added features (like ctrl-scroll display resize, the ability to disable the Close 'X' altogether), I found vDosPlus too unreliable.

[Jos]

Well, it seems I’ve to apologize to mrc2048: If vDos is started off a Windows mapped drive letter, the check for whether vDos C: may be (re)assigned fails. vDos internally stores/uses UNC paths, not the Windows drive letters. The moment it checks for USE C:, it however compares the windows mapped drive path with the UNC path initially assigned to C: to test if C: is already (re)assigned.

For the moment the solution is of course quite simple: Don’t use Windows mapped drive letters (as also recommended), but UNC paths instead. So start vDos by “\\network share\directory\vDos.exe”, not “mapped Windows drive letter\directory\vDos.exe”.

Jos

[dave]

Thank you Jos. That seems to be a very workable solution.
One more great hurdle out of the way in getting this project off the ground.

[Mark]

I want to use my applications on a computer network.

My scenario is as follows:

1) We use the S drive, my network computer name = 111.12.111.12
our network share name = apps
location folder of application = s:\vdos\bwc\2001
application = mfs.exe
VDOS is installed on the S drive

2) I enter the following in autoexec.txt file

use s:\\111.12.111.12\apps\bwc\2001\mfs.exe

Nothing happens,

I also tried use \\111.12.111.12\apps\bwc\2001\mfs.exe

nothing happens


please advised, thanks!

[emendelson]

Two things to change:

1 You need to add a space between "use s:" and the network address.

2 The address should be a folder, NOT the application.
 
So the correct command is:

    use s: \\111.12.111.12\apps\bwc\2001

Then you can enter this command on the command line:

    s:\mfs.exe

Also, you don't need to use S:. It doesn't matter what drive vDos is installed on. You can have 

    use C: \\111. etc.

or any other letter you prefer.

When you have tested these, add the "use" line and the command to autoexec.txt

[dave]

Jos,
Picking up where I left off earlier in this thread, the final thing I need to resolve is making single instance applications. I've been struggling with this bit for some time.

I wish to deploy two separate instances of vDos for two programs (in different folders, obviously), but each program must only be run once by each network user.

Under 32 bit windows this is trivial. I can do this with the following .CMD file on the server:
@t:\folder\program1.exe 2> c:\folder\program1.lock
The DOS based program executes in the same shell as the .CMD, so the user sees nothing but the normal program.


Under vDos obviously I can't do "2>" so I am trying to do it in the pre-vDos environment. As I mentioned earlier, it's important to have access to real drive C:. So I will be using \\server\share\program1\start.cmd (instead of mapped to T:\program1\start.cmd), so I can reassign C:.

I would have this start.cmd contain:
\\server\share\program1\vDos.exe 2> c:\folder\program1.lock
This basic locking part works well. A second instance is rejected.

Separately, if I run \\server\share\program1\vDos.exe by double clicking it, or a shortcut, the program works perfectly. But it's not single instance.


However, when I execute \\server\share\program1\start.cmd which calls on \\server\share\program1\vDos.exe, two things happen:
1: vDos doesn't seem to run its config/autoexec set. I just get a blank vDos with no parameters.
2: I have an extra command box I want to avoid. It will confuse users.

Interestingly, and this is no good, but if I run the very same batch file as T:\program1\start.cmd, then the config/autoexec set executes. But I don't have access to C:, and I still get the second CMD box.

I have also tried creating a .NET application as a "wrapper", marking it as single instance, and using it to start vDos. Likewise, it ignores auto config/autoexec set.

Can you suggest any workaround for forcing a single instance, per program, per user, while allowing drive C: access?
Or at least how to start vDos silently from a CMD or other starter, using UNC paths, and have the config/autoexec run?

Thanks for any suggestions.

[Jos]

Problem with vDos ‘ignoring’ config and autoexec.txt will be that it looks for these files in the Windows current work directory. If you execute \\server\share\program1\start.cmd the windows command processor can’t display the leading drive letter, so the current work directory won’t be set .

In my DOS programming days (a real long time ago) I used PWONE to ensure only one instance was running.

Since you provide access to the C: drive, you could do something like this in autoexec.txt:

rem vDos C: is assigned to Windows C: (\directory)
if exist c:app1.txt exit
echo running>c:app1.txt
app1.exe
del c:app1.txt
exit

And eventually clean up app1.txt etc. at Windows start for if app1.exe crashed?

Jos

Attachments:

PWONE.EXE (15 KB)

PWONE32.TXT (2.34 KB)

[dave]

Thank you. I think I understand why it is not executing.

Sounds like starting from CMD at all is not going to work. I can't run it with, or without, mapped drive letters.

I am not satisfied with the sentinel file method of preventing multiple instances. If the app crashes, which it does occasionally, then I must provide a mechanism by which users can clean up and start a new instance. The very idea is to prevent users who WANT to run two instances. So with this, they will have their way. The "2>" error output mechanism prevented this easily and beautifully.

While I appreciate the PWONE, having to install further VBRUN modules on PCs defeats the purpose of the project. I'll keep digging and if I find anything useful I'll share it.
Thank you for your help.

[Jos]

If the application (actually vDos, not completing autoexec.txt) is prone to crash, it will be better to use virtual Windows 32-bit machines instead.

Jos

[dave]

Actually, to be fair to the DOS program, the crashing will largely be mitigated by the use of vDos. You see, even 32 bit windows workstations keep having their CONFIG.NT replaced after every update, reverting it to FILES=40. Gah!

Now, I've had a bit of success making a single instance with VBS, and will share in case it's useful for anyone else.
The following allows multiple programs to be run by vDos, but by renaming vDos.exe as vDos1.exe, each can only be run once.
The only downside is that the VBS (the shortcut to that VBS can be anywhere) seems to need to be in the same folder as vDos, or again it calls a blank session.
I can live with that. Thanks for all your help.

ProgramName = "vDos1.exe"
ProgramPath = "\\server\share\program1\vDos\vDos1.exe"

Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
Set ProcessList = objWMIService.ExecQuery ("Select * from Win32_Process where Name = '" & ProgramName & "'")

If ProcessList.Count > 0 Then
MsgBox "Program is already running!"
Else
Set objShell = CreateObject("WScript.Shell")
objShell.Run ProgramPath
End If

[mrc2048]

I posted some additional info under a different thread - this might be useful here

when you have started in a network share C: is mapped to the UNC of the share and cannot be remapped. I suspected it was because i was on it that I could not re-use it so I first used D: then did a 'cd D:' and then I was able to 'USE C: C:\' just fine

[Jos]

A bit late, but this idea also came later to me, would have a closer look at some time, and forgot about it.
If you want to ensure only one combination of vDos and a DOS program will be running on a PC, or even the whole network, add this line to config.txt:

COM5 = “Windows path to a (non-essential/dummy) local or network file”:

COM5 can of course be any port you don’t use. The trailing colon tells vDos to open the file exclusively. It has to exist, but not already opened as vDos starts, so a second attempt will only produce an error message.



Not informative to the user, but at least you ensure only one instance of the DOS program is running.

EDIT: If there's more interest for such functionality, I could of course add an optional error box caption and text to the DOS device=Windows device: directive.

Jos