In the documentation of the OPEN statement there is a discussion of sharing and locks that mentions:
"in PC-BASIC, the locks are only implemented internally. Whether other processes may access the file will depend on the host OS"
So for a business app that accesses files on a network share (mapped to a drive letter obviously) from Windows hosts, is it safe to use PC-BASIC or will locks not be respected? In other words will the sharing/locking behavior be the same as when running GW-BASIC on Win32.
I had read about data corruption problems with shared access in DOSBox and was hoping PC-BASIC might be a better option, but I'm not sure if the above statement about locking is cause for concern or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whether locks are respected will depend on what kinds of locks you're using. If this is a Windows network, presumably it's up to Windows to enforce file locking - PC-BASIC doesn't get involved in that.
If you depend on the MS-DOS style SHARE.EXE locks that the sharing and locking feature of OPEN emulates, then the answer is no - e.g. a file that is opened LOCK READ WRITE in one instance of PC-BASIC can be opened inanother instance of PC-BASIC without any effect of that lock.
I don't know what the sharing/locking behaviour of GW-BASIC under Win32 is, so I don't know the answer to that particular question.
I imagine you'll have to try and see if it works as expected - note that this is an emulator developed as a hobby and I would recommend against using it for any kind of critical application. If it is of use to you, great, but I'm not going to be able to guarantee it's 'safe' for any particular business use.
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick reponse - and sorry, meant to post this in general, not bugs.
We're defintely not using share.exe, just plain Win7-32 command prompt. So maybe the app already isn't safe :) It's not often used, and even less often used in a way that concurrency could be a problem, so maybe we've just never noticed if locking isn't working as expected. I'll have to do some testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just checking, do you in fact have any LOCK, UNLOCK statements or SHARED or LOCK clauses in OPEN statements in your code? If not, then the remark in the documentation is not relevant since that is the only kind of locking it refers to.
Let me know if you find any particular issues with during testing - not sure how much I can help here since I don't really know the details of what your needs are but if there are specific problems with PC-BASIC I can try to fix them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
In the documentation of the OPEN statement there is a discussion of sharing and locks that mentions:
"in PC-BASIC, the locks are only implemented internally. Whether other processes may access the file will depend on the host OS"
So for a business app that accesses files on a network share (mapped to a drive letter obviously) from Windows hosts, is it safe to use PC-BASIC or will locks not be respected? In other words will the sharing/locking behavior be the same as when running GW-BASIC on Win32.
I had read about data corruption problems with shared access in DOSBox and was hoping PC-BASIC might be a better option, but I'm not sure if the above statement about locking is cause for concern or not.
Whether locks are respected will depend on what kinds of locks you're using. If this is a Windows network, presumably it's up to Windows to enforce file locking - PC-BASIC doesn't get involved in that.
If you depend on the MS-DOS style
SHARE.EXElocks that the sharing and locking feature ofOPENemulates, then the answer is no - e.g. a file that is openedLOCK READ WRITEin one instance of PC-BASIC can be opened inanother instance of PC-BASIC without any effect of that lock.I don't know what the sharing/locking behaviour of GW-BASIC under Win32 is, so I don't know the answer to that particular question.
I imagine you'll have to try and see if it works as expected - note that this is an emulator developed as a hobby and I would recommend against using it for any kind of critical application. If it is of use to you, great, but I'm not going to be able to guarantee it's 'safe' for any particular business use.
Rob
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thanks for the quick reponse - and sorry, meant to post this in general, not bugs.
We're defintely not using share.exe, just plain Win7-32 command prompt. So maybe the app already isn't safe :) It's not often used, and even less often used in a way that concurrency could be a problem, so maybe we've just never noticed if locking isn't working as expected. I'll have to do some testing.
Just checking, do you in fact have any
LOCK,UNLOCKstatements orSHAREDorLOCKclauses inOPENstatements in your code? If not, then the remark in the documentation is not relevant since that is the only kind of locking it refers to.Let me know if you find any particular issues with during testing - not sure how much I can help here since I don't really know the details of what your needs are but if there are specific problems with PC-BASIC I can try to fix them.