ts>
  > i suspect that the os/2 dos box probably changes certain
  > file access rights of files shared between os/2 sessions
  > and os/2-dosbox-sessions.
  >
  > -   is this true?
ts>

  No. The DOS v 4.0 `open' API call (INT 21h, AX=6C00h) has a 1:1 mapping
  with the 16-bit OS/2 1.x DosOpen system call (which 32-bit OS/2 still
  supports).  This isn't surprising, because it was the development of the
  OS/2 1.x API that caused that addition to DOS v 4.0 to be made in the
  first place.

  The only cases where anything special happens are where DOS applications
  use "compatibility" sharing mode, or use the DOS v 3.x `open' API call
  (INT 21h, AX=3D00h), which doesn't allow a share mode to be specified
  (and "compatibility" share mode is thus implicit).

  There's no such thing as "compatibility" sharing mode in OS/2.  It's a
  legacy from DOS where file sharing was "optional", according to whether
  SHARE.EXE was loaded, what API call was used, whether Netware was
  loaded, the phase of the moon, etc..

  File sharing is compulsory in OS/2.  So the VDM kernel translates
  "compatibility" share mode into an appropriate real share mode (usually
  "deny none") before forwarding the call to the OS/2 kernel.  This
  doesn't produce behaviour that is 100% consistent with DOS (since
  "compatibility" share mode on DOS doesn't _always_ behave as
"deny none"
  share mode does).  But then again, with the vagaries of file sharing in
  many DOS LAN softwares (c.f. the "share" attribute in Netware) DOS isn't
  terribly consistent with _itself_ in this respect (which is a good
  reason for saying that any DOS programmer not using file sharing
  properly but instead relying on "compatibility mode" is a fool).

  It sounds, to be honest, that your DOS program is being too clever for
  its own good.  It sounds like it is using an underhand method of
  detecting the presence of SHARE.EXE.  Some programs try to adjust the
  "file lock count" as a means of detecting SHARE.EXE, which succeeds on
  DOS with the "real" SHARE.EXE (which has all sorts of internal
  shenanighans and fixed-length tables which a DOS program can fiddle
  with), but naturally fails on OS/2, because OS/2 doesn't have the stupid
  limitations of SHARE.EXE and fails any request to muck around with the
  internals of SHARE.EXE because they don't exist.

  If this is the case then when your program is run on DOS with the
  Netware Client for DOS (and thus SHARE.EXE) loaded it is using file
  sharing, and when it is run in a VDM on OS/2, it is using "compatibility
  mode" (because its back-door check for SHARE.EXE fails).

  The only way to check this absolutely is to use a DOS API snooping
  utility (such as Andrew Schulman's INTRSPY) to determine what API calls
  your DOS software is making.  Or to talk to the program's author, of
  course.

  If you talk to the program's author, and _do_ find out that he is being
  too clever for his own good by "intelligently" turning file sharing off
  when he doesn't detect SHARE.EXE, tell him that it's time that he came
  out of the dark ages of DOS 3.x, and used file sharing ALL OF THE TIME.
  That way, his program will work properly.

  If, on the other hand, you find out that the program is _definitely_
  using file sharing, and using it correctly, then try to find out exactly
  what combination of access modes are causing the sharing violation and
  come back to us (either here, or, preferably, in the OS2DOS echo).

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01