On 2/14/24, Pali <[email protected]> wrote:
what is the state of the DJGPP project?
It is still developed or it is not active anymore?
Date: Sat, 17 Feb 2024 16:52:10 +0100
From: Pali <[email protected]>
Cc: [email protected]
On Wednesday 14 February 2024 16:47:42 Eli Zaretskii wrote:
From: "Ozkan Sezer ([email protected]) [via [email protected]]" <[email protected]>
Date: Wed, 14 Feb 2024 03:27:00 +0300
Cc: djgpp <[email protected]>
On 2/14/24, Pali <[email protected]> wrote:
Hello,
I figured out that you are one of the last contributors to the DJGPP project. I would like to ask, what is the state of the DJGPP project? It is still developed or it is not active anymore?
I have some changes for DJGPP documentation and if the DJGPP project is still active I can send you documentation file diffs. Please let me know
if you (or somebody else) would like to see them.
This must be asked / discussed on the djgpp mailing list: Added to CC.
Can you tell what kind of documentation changes you are talking about?
Hello, many thanks for all replies. Here is one simple change:
--- src/libc/dpmi/api/d0401.txh
+++ src/libc/dpmi/api/d0401.txh
@@ -14,8 +14,8 @@ Please refer to the DPMI Specification (@pxref{DPMI Specification})
for details on DPMI function call operation. Also see
the DPMI Overview (@pxref{DPMI Overview}) for general information.
-DPMI function AX = 0x0401 (DPMI 1.0 only). Not supported by CWSDPMI and -Windows.
+DPMI function AX = 0x0401 (DPMI 1.0 only). Supported by CWSDPMI v5+,
+but not by Windows.
Date: Sat, 17 Feb 2024 22:55:43 +0100
From: Pali <[email protected]>
Cc: [email protected]
Such changes are, of course, welcome. So how about posting them here,
and let people review and comment? Then we can install the parts that
look useful.
Thanks.
Ok, here is another simple change for web documentation. Text
"Capability not supported" is rendered above the HTML table. I have not
found where is the source file, so I'm writing diff against web URL:
--- https://www.delorie.com/djgpp/doc/dpmi/api/310508.html
+++ https://www.delorie.com/djgpp/doc/dpmi/api/310508.html
@@ -53,8 +53,8 @@ AX = <a href="errors.html">error cod
DJ, who and how maintains the Web docs?
Date: Sun, 18 Feb 2024 11:35:11 +0100
From: Pali <[email protected]>
Cc: [email protected]
I'm sending another simple documentation change. In documentation for
getting and setting attributes is written wrong name of the structure
field in which is stored number pages.
--- src/libc/dpmi/api/d0506.txh
+++ src/libc/dpmi/api/d0506.txh
@@ -20,7 +20,7 @@ not by Windows.
This function retrieves the attributes of a number of pages. Pass the
handle in @code{@var{info}->handle}, offset of first page (relative to
start of block) in @code{@var{info}->address}, and number of pages in -@code{@var{info}->count}. The buffer @var{buffer} gets filled in with +@code{@var{info}->size}. The buffer @var{buffer} gets filled in with
the attributes. For each page, a 16-bit attribute word in @var{buffer}
defines the attributes of that page as follows:
--- src/libc/dpmi/api/d0507.txh
+++ src/libc/dpmi/api/d0507.txh
@@ -20,7 +20,7 @@ not by Windows.
This function sets attributes of a number of pages. Pass handle in
@code{@var{info}->handle}, offset within block in
@code{@var{info}->address}, and number of pages in -@code{@var{info}->count}. @var{buffer} points to an array of 16-bit +@code{@var{info}->size}. @var{buffer} points to an array of 16-bit
words which specify the new attributes.
@xref{__dpmi_get_page_attributes}, for the definition of the page
attribute word.
Date: Sun, 25 Feb 2024 13:42:23 +0100
From: Pali <[email protected]>
Cc: [email protected]
Hello, the next documentation change is for __djgpp_map_physical_memory() function. Document requirements / restrictions for out_addr/num_bytes parameters and extend example how to use this function. I think that the
full example is useful because without it I had to read djgpp source
code to understand what kind of pointer I can pass for out_addr. If you
like this change, feel free to reformat or rephrase new description.
--- src/libc/dpmi/helper/mapmem.txh
+++ src/libc/dpmi/helper/mapmem.txh
@@ -21,6 +21,22 @@ be set to @code{EINVAL} and the routine will fail.
This routine properly handles memory ranges that span multiple DPMI
handles, while @code{__dpmi_map_device_in_memory_block} does not.
+Every page in the specified address range @var{out_addr}, @var{num_bytes} +must belong to some DPMI handle in @code{__djgpp_memory_handle_list} +allocated by @code{sbrk()}.
Date: Sun, 25 Feb 2024 12:55:26 +0100
From: Pali <[email protected]>
Cc: [email protected]
Hello, I have there another documentation change. It fixes mistake in __dpmi_map_conventional_memory_in_memory_block() function. This function takes linear address, not the physical one (as defined in DPMI 1.0 spec).
Date: Sun, 25 Feb 2024 17:51:54 +0100
From: Pali <[email protected]>
Cc: [email protected]
On Sunday 25 February 2024 14:49:38 Eli Zaretskii wrote:
Date: Sun, 25 Feb 2024 12:55:26 +0100
From: Pali <[email protected]>
Cc: [email protected]
Hello, I have there another documentation change. It fixes mistake in __dpmi_map_conventional_memory_in_memory_block() function. This function takes linear address, not the physical one (as defined in DPMI 1.0 spec).
What exactly is the difference between a physical address below 1MB
and the linear address there?
I'm not sure now if I understood it correctly. But my understanding of
the spec is that DPMI host which supports paging may page-out also
linear addresses below 1 MB.
There are DPMI functions 0602H and 0603H which client may use to enable/disable paging for memory below 1 MB. And once paging is
active then virtual linear address does not have to match physical
address.
From: "A. Wik ([email protected]) [via [email protected]]" <[email protected]> Date: Mon, 26 Feb 2024 08:23:27 +0000
I think there's a misunderstanding here. The issue at hand is whether
the DOS memory's linear address, as it appears within a certain VM,
can ever have the value above 1MB. If the linear address is _always_
below 1MB, then for all practical purposes it is the same as the
"physical address", since what the VM does under the hood is none of
the business of the DJGPP programmer.
Linear V86 addresses are obviously below 1 MB, but (via the page
tables) they can be (and in Wndows often are) mapped to any physical
address, including above 1 MB.
Date: Sun, 25 Feb 2024 12:55:26 +0100
From: Pali <[email protected]>
Cc: [email protected]
Hello, I have there another documentation change. It fixes mistake in __dpmi_map_conventional_memory_in_memory_block() function. This function takes linear address, not the physical one (as defined in DPMI 1.0 spec).
Date: Tue, 27 Feb 2024 23:51:19 +0100
From: Pali <[email protected]>
Cc: [email protected]
On Sunday 25 February 2024 14:56:07 Eli Zaretskii wrote:
Please specify function by their name alone, as in @code{sbrk},
without the parentheses. "sbrk()" looks like a call to 'sbrk' with no arguments, which is not what you mean here. Same with references to
other functions in the patch. (I realize that the fashion of
referencing functions by using the parentheses exists out there in
other projects, but we don't follow it here.)
Thanks.
It is the only issue in this change? If yes, would you trivially change
it before applying?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 138:58:30 |
| Calls: | 12,087 |
| Files: | 14,997 |
| Messages: | 6,517,405 |