maybe it might be time to go bug hunting

Nope.

I bet the fakeshare in the windows 3.1x guide takes care of this.

wd wrote:

maybe it might be time to go bug hunting

Nope.

Any particular reason why not? I don't know much about the internal architecture of DOSbox, but I would assume that fixing regressions (which the breaking of VSHARE was, given that it worked until some point after the release of 0.72 and before the release of 0.73) is a normal part of a software project. Was VSHARE deliberately broken during the 0.73 dev cycle or were changes simply made to the memory emulation that would make it really hard to fix? Either way, I figured folks might be interested in a game that uses unemulated features generally considered to be "non-game".

If you search vogons you will learn that it never worked. It just "appeared" to be working and this was rightfully fixed, be it intentionally or not. The problem with it only appearing to work is that data corruption is very very likely when programs actually do make use of the share functions. So fixing this does take care of users feeling secure while their data actually wasn't.
So for the adventurous that doesn't do any productive work with share needing programs, fakeshare is the answer.

Dominus wrote:

If you search vogons you will learn that it never worked. It just "appeared" to be working and this was rightfully fixed, be it intentionally or not. The problem with it only appearing to work is that data corruption is very very likely when programs actually do make use of the share functions. So fixing this does take care of users feeling secure while their data actually wasn't.
So for the adventurous that doesn't do any productive work with share needing programs, fakeshare is the answer.

Hmm. I'd love to know how SHARE works and how it conflicts with DOSBOX memory management... It would make an interesting study.

It doesn't conflict memory management but file handling. It's complex interwined into the dos internals so go on and have fun.