Did you open the server share in Windows Explorer of the Windows 10 client PC, and double click vDos.exe in there? vDos is fully portable, if you can get to vDos.exe on a remote PC, a DOS application should just run. Certainly if it already proved to run locally at that remote PC. You would be the first having trouble with that…
Yes of course I did. I tried variations, starting from vDos from client, then opening Dos program (m.exe) from server. I tried opening vDos directly from shared server thru windows. I even tried opening vDos on both computers & running vDos within vDos which works. It's pretty clear the file is being locked, it's quite possible vDos is not handling the file lock correctly. I vaguely recall having to use a share.exe or dosx.exe on xp or else get same file lock message.
This is from my err description file: 0,100 : Disk read error (HARD DISK ERROR) CALL SERVICE TECH!! 0,101 : Disk write error (HARD DISK ERROR) CALL SERVICE TECH!! 0,102 : File not assigned 0,103 : File not open 0,104 : File not open for output 0,106 : Invalid numeric format
For some reason 0, 105 is not listed which it the error being received.
I also borrowed a win 7 computer today, the networking was super easy 1 step. However same file lock occurs
For SHARE you could have a look at www.vdos.info/faqs.html - SHARE - Record locking (RL) by multi-user applications. If your program would need dosx.exe to run in protected mode, it wouldn’t even run standalone. A file being locked is initiated by the program, vDos just caries that out. It certainly doesn’t lock files if not instructed to do so by the program. Could be the Share permissions at the server are set incorrectly. C: - Properties - Sharing - Advanced Sharing - Permissions. Eventually test by opening a server text file on the client PC with Notepad, add a space, delete it again, and save the file.
The error description list would be of the programming language (Borland Pascal?) the software is written in. 0,105 being File not open for input?
i want to register, however if I move the server from the WIndows 7 computer to Windows 10 computer, does the license follow or can I just call the Win 10 computer P8COREPRO? The reason is I can't get windows 7 to see windows 10 right now.
A vDos Network registration is based on the name of the server. So you can indeed use that for any server with that name. I also have no problem if you would move from one to another server (name), as long I’m somewhat satisfied it’s still you using vDos. If you use vDos on only 3 PC’s, that many Username registrations would also be an option.
I would however advice you to get a dedicated file server. Doesn’t have to be expensive/complicated Windows one. A simple NAS like a Synology DiskStation DS118 or DS119J would do. At least it’s dedicated, no user ‘messing’ around with it, while others depend on it.
hi, I havent used the vDos but will def register. Haven't had time to play with Win 10 home edition, but am not able to access any folders under C: even w my tech support, so haven't used this computer for Dos program yet.
I'm pretty positive I'll register next couple of days. Thanks for all your help so far!
I haven't used vDos for almost a week. Right now, I'm testing it for the 1st time from Win 10 to XP. there seems to be a couple of issues. The registration reminder screen came on when the dos software was minimized and completely locked the software. After 10 minutes of trying to close (Alt-Enter does not bring it open), I had to use the task manager. I hope this is just a quirk of the reminder screen?
Also, the record lock worked beautifully when directly accessing the same record (insurance companies). But when I access a screen that contains multiple fields (precisely, gender, employment status, marital status, and patient reminders), there isn't a "record in use" message, but rather the program stalls for 10 seconds before backing out to the previous screen. This is good, but in xp to xp is instantaneous. This shouldn't have any bearing either? Thanks so much for just a little bit more of your time.
The nag function is real basic, it displays the reminder on top of the vDos window and waits for a mouse button press in there. All other functionality is put on hold, so also redrawing the window. The next version will first activate its window, but the current one indeed has the mishap you can’t click the reminder if the window is minimized.
In a 'real' database program, a “record in use” should only be displayed when one is editing the record (has locked it), and another also tries to edit it (the second lock request fails). A program can try to lock the record again since locks are often short-lived. vDos already does that automatically three times with a small pause. If the program has its own scheme of retrying a lock, that doesn’t interfere. But the program will also pause between tries, I reckon your program simply goes into a loop for that pause (instead of using the system clock). That loop will execute fast on a real CPU (XP-NTVDM), but much slower on the emulated CPU of vDos. Nothing to do about that, except if the program has some setting to disable retrying a lock.
You made sure all PC’s have the same Workgroup name set, else they won't ‘see/find’ each other.
For Jos & all readers, it's been 2 weeks and counting and the registered vDos has been solid. I asked copius questions because dos program has been my lifeblood. it's in borland pascal, has an index database - the RL functions as promised but of course Jos you already knew that. Combined w a registered Dosprinter.exe, I get 2 outputs for lpt1/2 and 2 outputs for com ports. I've been directing one com to PDF. All in all, I highly recommend vDos & Dosprinter.exe, especially w Jos' quick repsonses. Thanks, James
Record locking (RL) is guaranteed/proven to work correctly under all circumstances. vDos even (first) tests it’s actually supported by a physical drive. Also retrying a failed RL is (transparently to DOS apps) handled. A DOS app could have its own retrying scheme, eventually relying on programmed CPU loops that take longer to execute on a simulated one. That doesn’t interfere with vDos RL, but just consumes more time. Noted as an attention point, but most likely unsolvable, that core CPU loop will still cause some delay. BTW, you’re the first confronted with (such a silly) mishap of your DOS program.
DOSPrinter is an excellent, surely the best and most versatile, DOS (Epson)-to-Windows print processor. The reason I once selected it to be included with the vDos installation as the default print processor. It was however (still) rather expensive, so replaced by an internal print processor that also supports PCL. Though that has some twists, like metric settings (I’m Dutch), program independent scaling/positioning, no graphic support to encourage/enforce better alternatives. I didn’t want to just mimic other print processors (still an alternative in vDos).
My advice: First try the internal print processor. That could need some experimenting, though external ones also do (and those are a real roundabout). If it comes short, you need for instance barcodes or more extensive formatting: Try those mentioned in the Printing.pdf document.
If you wonder why the vDos internal print processor doesn’t support generating PDF’s: Not that difficult to implement, you would even get real small PDF’s. But once added, I’ll get everlasting requests for more functionality. Many Print-to-PDF programs around to do that.