Hi Bart,
Yes, that has been in the kernel since the initial implementation by
Ron Cemer. It used to work on fnodes but now updates the SFTs.
These routines (mainly merge_file_changes() in fatfs.c) could be moved
to share.c if the hooks from RBIL table 01636 were implemented.
Given the
Hi Christian,
I know about the OEM ID and the DOS-C release string which can be
retrieved by Int21.33FF. I don't see how SHARE could use that...
I suppose there's no way to get the kernel's build number for SHARE then?
The revision number (eg 38 for 2038) is returned in BL
if you call int
Given the number of hooks, some of which are not even documented,
I would say that the current implementation of SHARE is smoother.
I agree.
This format of share exe hooks table about MS SHARE lists:
- a routine of unknown purpose, probably not called
Since SHARE of MS-DOS 3.3+ is
Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer e.a...@jpberlin.de:
Hi Christian,
I know about the OEM ID and the DOS-C release string which can be
retrieved by Int21.33FF. I don't see how SHARE could use that...
I suppose there's no way to get the kernel's build number for SHARE
then?
Please explain in what way Win 3 uses virtual(?) machine numbers
and why supporting them is needed to get a Win compatible SHARE.
MS-DOS usually sets the net machine number (offset 1Eh of SDA, table at
Int21.5D0B) to zero (indicating local) inside its Int21 dispatcher,
unless the server
Hi Ibid,
1470 builds and works fine (not much testing done though).
cd \ works again
Good...
HDPMI (HX 2.15 dpmi server) loads.
What was broken before?
Regarding the patch I saw mentioned, here's the thread:
I guess SHARE might be something to test w/ HX.
Japheth's documentation claims that SHARE is needed for pipes, Cygwin
requires pipes, and FD SHARE is too crippled to work.
If Japheth knows about a bug, he should explain what EXACTLY
is wrong so somebody has a chance to fix it...
I don't
Hi Christian,
I don't know what Japheth has to complain about it, but I know that
DOS-C's SHARE:
- is a C program that stays in memory without usage of any assembler code.
True. It might be interesting to rewrite it in pure Assembly, for size.
Increases memory usage much.
Already
- uses an interface on Int2F which probably isn't as good as an internal
hook. (MS-DOS uses a number of hooks partly documented in RBIL, I use
one
You mean table 01636, format of share exe hooks?
It doesn't matter, but probably yes. (I don't know the number, but it's
inside the Int21.52
- doesn't check whether it runs on the correct DOS version. It doesn't
..
I know about the OEM ID and the DOS-C release string which can be
retrieved by Int21.33FF. I don't see how SHARE could use that to
differentiate kernel releases. Does the string have a fixed format
specified anywhere?
2009/7/5 Christian Masloch c...@bttr-software.de:
Regarding the updating of SFTs opened for the same file (previous mail),
is that already in the kernel? If not, I want to add that point to your
list for SHARE.
Yes, that has been in the kernel since the initial implementation by
Ron Cemer. It
Hello all,
1470 builds and works fine (not much testing done though).
cd \ works again
(resources handled correctly) from Christian's test program.
HDPMI (HX 2.15 dpmi server) loads.
Regarding the patch I saw mentioned, here's the thread:
12 matches
Mail list logo
