Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Louis Santillan]

BTW, Ladislav did some performance testing on a Pentium 4 last
October.  He gives hints on how to make FD a bit faster, though still
about 50% performance of MS-DOS in a best case scenario.  Namely,
Ladislav suggests (on a 512MB RAM machine) using UIDE w/a 160MB cache,
and LBAcache with 16843KB (16MB) cache.

https://sourceforge.net/p/freedos/mailman/message/37727725/
https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/Dog.2N9f.5Ml4lqeFp6Q.1ZND6x%40seznam.cz/#msg37727725

On Tue, Mar 7, 2023 at 8:35 PM Louis Santillan  wrote:
>
> You haven't detailed anything about system configuration for this
> machine.  What hardware (CPU, RAM, DISK)?  Are you using FAT32 or
> FAT16? LFN?  LFN provided by which driver?  Which drivers do you have
> loaded w/FD and with MS-DOS?  Are you using a drive cache in either
> one?
>
> On Tue, Mar 7, 2023 at 5:08 PM Volkert via Freedos-devel
>  wrote:
> >
> >
> >
> > On Wed, Mar 8, 2023 at 2:02 AM Ralf Quint  wrote:
> >>
> >> Well, I just download both v1.9 and the latest 2.0 and the later is 1.75x 
> >> as big as v1.9 (143MB vs 81MB), so there must be some more than trivial 
> >> difference between the installers...
> >
> >
> > I was referring specifically to the DOS installer code within the sources. 
> > The side of the payloads may (the stuff being installed by the installer) 
> > may indeed have changed considerably.
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

On Wed, Mar 8, 2023 at 2:02 AM Ralf Quint  wrote:

> Well, I just download both v1.9 and the latest 2.0 and the later is 1.75x
> as big as v1.9 (143MB vs 81MB), so there must be some more than trivial
> difference between the installers...
>

I was referring specifically to the DOS installer code within the sources.
The side of the payloads may (the stuff being installed by the installer)
may indeed have changed considerably.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Ralf Quint]

On 3/7/2023 4:54 PM, Volkert via Freedos-devel wrote:


The last time I installed OW was on one of my physical laptops,
which are currently in storage, so I can't easily test this right
now, and I am pretty sure that I installed the v1.9 from
openwatcom.org . Not sure if both 1.9 and
2.0 are actually using the same installer...

I would guess they do, since it doesn't look like the DOS installer 
was touched much since the project was forked.


Well, I just download both v1.9 and the latest 2.0 and the later is 
1.75x as big as v1.9 (143MB vs 81MB), so there must be some more than 
trivial difference between the installers...



Ralf

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

[Volkert via Freedos-devel]

You might want to take a look at the VMusic project by javispedro
. It's an
open-soure extension pack for VirtualBox that enhances sound emulation
support, notably adding high quality OPL3 FM synthesis emulation and
MPU-401 emulation with MIDI passthrough to the host. It only supports Linux
hosts, though. Perhaps this extension pack could be further improved by
having it include an alternative SB16 emulation option that would implement
the fixes suggested in that VirtualBox ticket.

On Fri, Jan 27, 2023 at 6:24 PM Ben Collver  wrote:

> On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:
>
> > any reason you don't download VirtualBox for your platform, select
>
> > proper devices (there is even a Soundblaster16 emulated), install DOS
>
> > on it and go.
>
> VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.
> VirtualBox developers have gaslit DOS users about this in their forum.  It
> is a known problem and VirtualBox developers rejected fixes for it.  For
> technical details, see the following support ticket.
>
> https://www.virtualbox.org/ticket/14883
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

On Wed, Mar 8, 2023 at 1:40 AM Ralf Quint  wrote:

>
> Well, I know some folks will hate me for that (what else is new) but there
> is no MS-DOS 7.1. It's the bootup DOS system of Windows 95SR2 and up.
>

That's just getting pedantic about things. Whatever you prefer to call it,
the "bootup DOS system of Windows 95SR2" doesn't have this problem, but
FreeDOS does. At least as of version 1.3. By the way, I'm pretty sure I
used FAT32 in both cases. And even if I didn't, the use of FAT32 really
shouldn't lead to such an excessive slowdown. I would still consider that a
bug that ought to be looked into.


> So possible issues at hand could be the use of FAT32 and/or long file
> names, which I somehow recall OW2 defaulting to.
>

Funny you'd mention LFN support, since the maintainer of OW2 disabled it
when I initially reported this finding there, before someone else pointed
out that it ran fine in "MS-DOS 7.1":

https://github.com/open-watcom/open-watcom-v2/issues/1025

Anyway, disabling LFN support in the installer did not resolve the issue,
so it's not that.


> The last time I installed OW was on one of my physical laptops, which are
> currently in storage, so I can't easily test this right now, and I am
> pretty sure that I installed the v1.9 from openwatcom.org. Not sure if
> both 1.9 and 2.0 are actually using the same installer...
>
I would guess they do, since it doesn't look like the DOS installer was
touched much since the project was forked.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Ralf Quint]

On 3/7/2023 4:11 PM, Volkert via Freedos-devel wrote:

Hi,

Over a month ago, I opened an issue on the FreeDOS project on GitLab 
about the Open Watcom v2 installer being extremely slow in FreeDOS. It 
takes an hour or more on FreeDOS, while the same installation 
completes on MS-DOS 7.1 within just a few minutes. I've reproduced 
this in VM instances, both with VirtualBox and Qemu/KVM on a Linux 
host. I have not tested this on a bare-metal DOS machine.


See https://gitlab.com/FreeDOS/issue-reporting/-/issues/42

But I haven't seen anybody respond to the issue. Is that really the 
proper place to report FreeDOS bugs these days? With the 
`issue-reporting` subproject, this is at least implied.


To be clear, I used a recent DOS build of the Open Watcom v2 fork 
 to test this. I did 
not explicitly test this with the old original v1.9 release, but since 
the installer runs fine on MS-DOS, it seems unlikely that this issue 
with FreeDOS was introduced in the forked project.


The difference in installation time is extreme, which suggests some 
kind of bug or inefficiency in the file access routines of FreeDOS.


Could somebody maybe take a look at this?

Also, I wonder if others have noticed similar poor file I/O 
performance under FreeDOS with other DOS software.
Well, I know some folks will hate me for that (what else is new) but 
there is no MS-DOS 7.1. It's the bootup DOS system of Windows 95SR2 and up.


So possible issues at hand could be the use of FAT32 and/or long file 
names, which I somehow recall OW2 defaulting to.


The last time I installed OW was on one of my physical laptops, which 
are currently in storage, so I can't easily test this right now, and I 
am pretty sure that I installed the v1.9 from openwatcom.org. Not sure 
if both 1.9 and 2.0 are actually using the same installer...



Ralf

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

Hi,

Over a month ago, I opened an issue on the FreeDOS project on GitLab about
the Open Watcom v2 installer being extremely slow in FreeDOS. It takes an
hour or more on FreeDOS, while the same installation completes on MS-DOS
7.1 within just a few minutes. I've reproduced this in VM instances, both
with VirtualBox and Qemu/KVM on a Linux host. I have not tested this on a
bare-metal DOS machine.

See https://gitlab.com/FreeDOS/issue-reporting/-/issues/42

But I haven't seen anybody respond to the issue. Is that really the proper
place to report FreeDOS bugs these days? With the `issue-reporting`
subproject, this is at least implied.

To be clear, I used a recent DOS build of the Open Watcom v2 fork
 to test this. I did not
explicitly test this with the old original v1.9 release, but since the
installer runs fine on MS-DOS, it seems unlikely that this issue with
FreeDOS was introduced in the forked project.

The difference in installation time is extreme, which suggests some kind of
bug or inefficiency in the file access routines of FreeDOS.

Could somebody maybe take a look at this?

Also, I wonder if others have noticed similar poor file I/O performance
under FreeDOS with other DOS software.

Thanks.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] 386MAX

[Volkert via Freedos-devel]

On Mon, Mar 6, 2023 at 7:45 PM Bret Johnson  wrote:

>
> Or just take some of the important stuff that Bob Smith and Qualitas
> discovered about Windows/GEMMIS/EMM386 and import it into something like
> JEMM.  There's some knowledge embedded in 386MAX about what MS did that you
> will never directly get out of MS.


I already opened a ticket for this on GitHub
 a few years ago,
but Japheth
(a.k.a. Baron-von-Riedesel on GitHub) has expressed reluctance to implement
this functionality in Jemm, unfortunately.

By the way, DOSBox already has an open-source GEMMIS implementation
, which would likely be
easier to port to Jemm than any of the 386MAX sources.

I was hoping that 386MAX could ship with FreeDOS as an alternative EMM
manager because there appeared to be no near-term prospect of having GEMMIS
support (and thus Windows 3.x 386 Enhanced mode compatibility) added to
Jemm. Also, since 386MAX implements the same port trapping API as that of
Microsoft EMM386, I was hoping that it would offer compatibility with
certain drivers and emulators such as SoftMPU, which don't work with Jemm.

At least there's some encouraging news on that front, in the form of a Jemm
Loadable Module that adds support for QPI (QEMM's port trapping API), or a
subset of it. Baron-von-Riedesel recently developed that module, so
crazii's recently developed Sound Blaster emulator called SBEMU
 (also a very promising project for
FreeDOS!) can work with Jemm.

So GEMMIS support appears to be the one missing feature that would make
Jemm a complete replacement for all the known EMM managers of old (EMM386,
QEMM, 386MAX).

But perhaps if someone creates a pull request for adding GEMMIS support to
Jemm, Japheth might be persuaded to merge it. (Although he has expressed
skepticism towards that as well.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Rugxulo]

Hi again,

On Tue, Mar 7, 2023 at 12:41 PM Rugxulo  wrote:
>
> On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson  wrote:
> >
> > That model sort of illustrates the concept, though.  Both Windows and Linux 
> > want to manage the _entire_ machine's
> > resources while they are running and one OS must give give up that control 
> > to let the other OS take over.
> > I'm proposing that the control be outside either OS -- in a sense, give it 
> > back to the "BIOS".   The "BIOS" in this case
> > can be considered a common Hardware Abstraction Layer (HAL) that all OS's 
> > can share, but it could be "subdivided"
> > (e.g., a "memory BIOS" and an I/O BIOS" and ...).  Some might consider that 
> > a step backwards, but I'm not so sure.
> > The direction we've been heading may actually be backwards, or at least a 
> > dead-end.
>
> Maybe you mean something like this?
>
> "Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR

Or maybe something like this?

* https://en.wikipedia.org/wiki/Genode


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Steve Nickolas]

On Tue, 7 Mar 2023, Rugxulo wrote:


Maybe you mean something like this?

"Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR

"The Power Macintosh 6100/66 DOS Compatible is a fascinating machine.
For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks
to an Intel 486 and a PowerPC 601 inside! Yeah, mid-90s Apple was
rather amusing."


I actually have the LC630, an earlier 68LC040 version of that machine, 
albeit without the PC compatibility module.


-uso.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2303

[Rugxulo]

Hi,

On Tue, Mar 7, 2023 at 5:59 AM  wrote:
>
> > On Mar 6, 2023, at 10:19 AM, Bernd Boeckmann via Freedos-devel 
> >  wrote:
> >
> > I noticed edlin32 2.21 is not working because of missing dos4gw.exe, but 
> > perhaps that is already obsoleted by the 2.22 release?

A quick fix is copying CWSTUB.EXE (Causeway) to DOS4GW.EXE. Then it
should work. Or run WDOSX's STUBIT on it.

> Gregory has only been releasing edlin updates in source form. That requires 
> me to compile them.
> For most projects, if a precompiled binary is not provided, I won’t compile 
> them. It get’s to be a very
> time consuming process putting all the dependencies together and a successful 
> compile. At least
> for edlin, that is not the case and it is not difficult to compile. But that 
> is all I do, I don’t go through
> the process of attaching a stub to the 32-bit version. So, it still requires 
> the external dos4gw.
> Which as you noted is not normally present.

Use the "-l=causeway" flag with WCL386 to attach it when compiling and linking.

> Maybe, I should just not bother compiling the 32-bit version for DOS.

I think normally 16-bit Edlin is compiled with the Compact model,
right? It doesn't mean someone somewhere wouldn't also need a 32-bit
pmode version, but I think a 16-bit Compact build is good enough for
our needs.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Michael Brutman]

On Tue, Mar 7, 2023 at 7:13 AM Bret Johnson  wrote:

>
> The way I'm trying to getting around that problem is to monitor the InDOS
> and Critical Error flags and some other things (like INT 28h).  But I'm
> sometimes getting false readings, especially in some Virtual Machines.  For
> example, some VM's don't seem to implement the InDOS flag at all (or if
> it's there it's not located where it's supposed to be) which is causing me
> some grief.
>
>
That doesn't make sense.  A VM is a hardware emulator.  It doesn't get to
choose to relocate the InDOS flag.  DOSBox can do whatever it wants when it
is emulating DOS, but a hardware emulator doesn't get to do those things.

What VMs are you seeing this behavior in?


-Mike
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Rugxulo]

Hi,

On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson  wrote:
>
> That model sort of illustrates the concept, though.  Both Windows and Linux 
> want to manage the _entire_ machine's
> resources while they are running and one OS must give give up that control to 
> let the other OS take over.
> I'm proposing that the control be outside either OS -- in a sense, give it 
> back to the "BIOS".   The "BIOS" in this case
> can be considered a common Hardware Abstraction Layer (HAL) that all OS's can 
> share, but it could be "subdivided"
> (e.g., a "memory BIOS" and an I/O BIOS" and ...).  Some might consider that a 
> step backwards, but I'm not so sure.
> The direction we've been heading may actually be backwards, or at least a 
> dead-end.

Maybe you mean something like this?

"Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR

"The Power Macintosh 6100/66 DOS Compatible is a fascinating machine.
For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks
to an Intel 486 and a PowerPC 601 inside! Yeah, mid-90s Apple was
rather amusing."

* https://youtu.be/9UclHrIIaYA


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Bret Johnson]

> After thinking a bit about this, I'm fairly certain that FreeDOS is
> NOT (sufficiantly) SDA compliant.

> ...
>
> some of the problems above might be handled by placing CLI/STI at
> proper locations. some are more difficult.
>
> but I'm pretty certain that FreeDOS hasn't a lot of CLI/STI's
> sprinkled at clever positions.

Probably not.  That's something you really need to think about as you're 
writing the code.  You also need to do things like preserving things (usually 
in CPU registers or on a stack) instead of using static memory variables.

> I have absolutely no idea how this situation is for MSDOS and DRDOS.
> as MS 'invented' the SDA, they might have put some (and probably
> more) into the proper places. at least I would think so.

I would certainly hope so, too.  Based on the description it seems as though 
that was the intention of IBM/MS.  In the particular case I'm considering, what 
I was hoping to do is have the TSR temporarily "take over" DOS so that it could 
use the DOS open/read/write file functions.  Allocating memory would also be a 
nice thing to have in TSRs at times.

The way I'm trying to getting around that problem is to monitor the InDOS and 
Critical Error flags and some other things (like INT 28h).  But I'm sometimes 
getting false readings, especially in some Virtual Machines.  For example, some 
VM's don't seem to implement the InDOS flag at all (or if it's there it's not 
located where it's supposed to be) which is causing me some grief.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Bret Johnson]

> There is an existing standard definition for re-entrant code, and
> multiple tools and frameworks support it.
>
> https://en.wikipedia.org/wiki/Reentrancy_(computing)

My terminology is compliant with that definition.  A couple of quotes from what 
you provided:

"A computer program or subroutine is called reentrant if multiple invocations 
can safely run concurrently on multiple processors...", and "Often, subroutines 
accessible via the operating system kernel are not reentrant..."

> If you want something else, fine, but you don't get to unilaterally
> redefine existing words. Linux is already a reentrant kernel: the
> kerne's code is reentrant and the kernel can preempt itself.

I haven't redefined anything.  Individual subroutines may be re-entrant but the 
entire kernel itself is not.  E.g., you can't have the _same_ copy of the 
kernel running on multiple CPU's concurrently (which is what the definition 
says).  Preempting a single running instance of something is not the same thing 
as running multiple copies concurrently.  The kernel can divide what it's 
trying to accomplish among the resources of multiple CPU's, but it does work 
the other way -- the CPU's don't (currently) divide the resources of the OS 
kernel among each other.

As long as the code (and even the data) is static and not self-modifying, you 
can have the exact _same_ copy of the code running on different cores/CPU's 
simultaneously and you never need to worry about synchronization or preemption 
or re-entrancy.  You do need to worry about multiple CPU's trying to read the 
same portion of RAM (where the code might be stored) at the same time, but that 
is a memory access issue and not a re-entrancy issue.

Here's another way of thinking about it.  One of the primary things the OS does 
is resource management (memory, I/O, CPU, time, etc.).  What if instead of one 
centralized, monolithic resource manager (the OS kernel) the resource 
management was distributed among the resources themselves?  E.g., what if the 
memory, at least in a sense, "managed itself" and each running OS could request 
memory resources from the (external) "memory manager" when it needed them?

Here's another thing that has happened over the years.  The concentration has 
been on making individual CPU's faster.  With the 486's (and maybe 386's?) you 
could have multiple CPU's on the same computer, and now we're into multiple 
cores on the same chip die, but the concentration has always been focused on 
making an individual CPU faster.  The problem is, the CPU's _themselves_ really 
haven't gotten a whole lot faster than they were in the 386 days.  They've 
"played games" with things like pipelining and caching to make the CPU's _seem_ 
faster than they really are.  But if you disable the caching of modern CPU's 
they are really very lackluster and you would not be happy at all with their 
performance.

We've really just about reached the physical limits of what we can do with raw 
CPU clock speed.  That's why we've starting going with multiple cores/CPU's and 
rewriting code to take advantage of that and are hoping for some 
"step-function" leap in technology like quantum computing or something.  What 
if we took a step back and started putting 100's of older technology (like 
386-class) CPU's on the same chip die and had them running at around 5 GHz (I 
think something like that might be possible)?  How would the computing world be 
different if we had started doing that a long time ago -- distributing the load 
(including resource management) instead of consolidating it?

> Windows is too, AIUI, and Solaris, AIX, HP-UX, macOS, QNX, and most
> mainstream OS kernels.

No, you're conflating preemption with re-entrancy and sub-functions with 
kernels.

> Your description is not clear to me, but it sounds similar to
> several existing technologies:

I know it's not -- it's probably not clear to most people since it's it's a 
completely different way of thinking than what they're used to.  And again, I'm 
not saying that it's a "good" idea or that it should even be implemented -- but 
it can at least give a different perspective on how things _could_ be done.

> One kernel loading another:
> https://sourceforge.net/projects/monte/
>
> Linux kernel as a user space process under another kernel:
> https://en.wikipedia.org/wiki/Cooperative_Linux
>
> Linux kernel as a user space process under the Linux kernel:
> https://en.wikipedia.org/wiki/User-mode_Linux

Again, while interesting, none of those are what I'm talking about.  The second 
one is interesting (running Windows and Linux on the same hardware), but they 
are not running concurrently.  They are task-switching with a cooperative model 
instead of a preemptive model.  I think you would probably classify that as a 
step backwards instead of forward.

That model sort of illustrates the concept, though.  Both Windows and Linux 
want to manage the _entire_ machine's resources while they are running and one 
OS 

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

> The SDA of MS seems fairly well documented in RBIL, but I'd be
> pretty surprised if all DOS clones (particularly Virtual Machines
> like DOSBox) are compliant so it may not be a good idea to pursue. 
> I suspect FreeDOS would be pretty close to compliant, but I'm not even sure 
> about that.

After thinking a bit about this, I'm fairly certain that FreeDOS is
NOT (sufficiantly) SDA compliant.

Even assuming that all static state of the FreeDOS kernel is contained
in the SDA, there is more 'state' in a DOS machine then that. at least
5 problem cases come to mind:

(1) DOS_MEM_ALLOC()

is basically

   a) segment = find_first_free_segment(size_wanted)

   b) mark_segment_as_used(segment)
  build_mcb_chain(segment, size_wanted)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_MEM_ALLOC, both the TSR and the old instance
will get the same segment and treat it as their own to use. BAD things
will happen...



(2) DOS_FILE_OPEN(filename)
is basically

   a) file_number = find_first_closed_file()

   b) mark_file_as_used(file_number)
  initialize_file_table(file_number, filename, ...)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_FILE_OPEN, both the TSR and the old instance
will get the same filenumber and treat it as their own to use. BAD things
will happen...

(3,4) DOS_FILE_WRITE()
   the problem is with the internal (and /or some external) cache.

   basically

   a) buffer = locate_LRU_buffer()

   b) clean_buffer_if_dirty(buffer)
  init_buffer(buffer, sectornumber)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_FILE_WRITE, both the TSR and the old instance
will use the same buffer for differenrt sectors. usually not a good
idea.


(5) INT_13_WRITE_SECTOR(LBA, buffer, count)

basically

  a)disk_controller_position(LBA)
disk_controller_initiate_write()
disk_controller_send_data(buffer,count)
disk_controller_wait_while_busy()
return disk_controller_status == STATUS_OK
  b)

  if the TSR interrupts anywhere and calls INT_13_WRITE (or
  INT_13_READ) between a) and b) data will be lost.


some of the problems above might be handled by placing CLI/STI at
proper locations. some are more difficult.

but I'm pretty certain that FreeDOS hasn't a lot of CLI/STI's
sprinkled at clever positions.


I have absolutely no idea how this situation is for MSDOS and DRDOS.
as MS 'invented' the SDA, they might have put some (and probably
more) into the proper places. at least I would think so.

Tom






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2303

[jerome]

Hi Bernd,

> On Mar 6, 2023, at 10:19 AM, Bernd Boeckmann via Freedos-devel 
>  wrote:
> 
> Hi Jerome,
> 
>> However, it should be tested that it creates a single 2gb FAT-16 partition 
>> on real hardware. It will also need tested from other booted install media 
>> under other circumstances as well. 
> 
> today I tested the live CD. At least on my hardware it creates a single 2 GB 
> FAT-16 partition like intended and successfully installs a bootable system 
> (plain installation without extras and source).

Thanks. :-)

> 
> There seems to be a minor graphics glitch at the end of the installer, see
> 
> https://nextcloud.iww.rwth-aachen.de/index.php/s/aze9r4pmAzKAxn4

Hmmm, apparently on that hardware, FDISK is doing something that is causing a 
minor issue when returning to the installer. Should be easy enough to fix. 
Hopefully, I’ll get to it before T2304.

> 
> I noticed edlin32 2.21 is not working because of missing dos4gw.exe, but 
> perhaps that is already obsoleted by the 2.22 release?

Gregory has only been releasing edlin updates in source form. That requires me 
to compile them. For most projects, if a precompiled binary is not provided, I 
won’t compile them. It get’s to be a very time consuming process putting all 
the dependencies together and a successful compile. At least for edlin, that is 
not the case and it is not difficult to compile. But that is all I do, I don’t 
go through the process of attaching a stub to the 32-bit version. So, it still 
requires the external dos4gw.  Which as you noted is not normally present.  
Maybe, I should just not bother compiling the 32-bit version for DOS. 

> 
> Greetings, Bernd

Jerome.

> 
>> 
>> :-)
>> 
>> Jerome
>> 
>> P.S., here is a short list of changes since last months build not related to 
>> NLS:
>> 
>> 2023-03-01 10:04:42 project_RBE (shidel): freespace error, report failed
>> 2023-03-01 08:42:01 project_FDI [unstable] (shidel): fix, RBE build fail, 
>> boot floppy to big
>> 2023-02-27 14:10:05 project_FDI-x86 [unstable] (shidel): create only a 
>> single partition using FDISK
>> 2023-02-27 13:56:59 project_FDI [unstable] (shidel): create only a single 
>> partition using FDISK
>> 2023-02-26 07:12:37 project_FDI [unstable] (shidel): if CDROM.BAT exists, 
>> missing GOTO
>> 2023-02-22 08:53:48 opengem (shidel): fixed corrupt nested zip error duing 
>> release build
>> 2023-02-22 01:56:27 project_FDI [unstable] (shidel): added PlayCD to FULL, 
>> added PlayCD & SJGPLAY to BonusCD
>> 2023-02-20 10:01:30 playcd (Shidel): Initial commit
>> 2023-02-20 06:58:37 7zdec (shidel): extracted sources from 7z archive for 
>> consistency
>> 2023-02-20 05:34:36 playcd (shidel): added PlayCD project
>> 2023-02-19 22:57:29 sjgplay (Shidel): Initial commit
>> 2023-02-19 18:33:21 sjgplay (shidel): added package SJGPlay v1.29
>> 2023-02-19 14:47:31 project_FDI [unstable] (shidel): Excluded Seal, oZone 
>> and CDP from install media
>> 2023-02-19 11:14:28 e100pkt (shidel): updated to v0.3
>> 2023-02-19 06:02:31 jwasm (shidel): updated to v2.16
>> 2023-02-19 05:12:16 mkeyb [unstable] (shidel): added 0.54 fork version
>> 2023-02-19 04:44:24 mkeyb [unstable] (shidel): commit prior to creating 
>> branch unstable
>> 2023-02-15 10:17:35 bladeenc (shidel): added missing sources
>> 2023-02-15 10:11:55 gnufonts (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 10:04:28 watcomf (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:52:42 watcomc (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:37:55 tinyasm (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:36:12 msa (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:31:12 i16nlelk (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:27:08 i16gcdoc (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-15 09:25:43 i16budoc (shidel): added README for sources to satisfy 
>> package creation requirements
>> 2023-02-13 04:47:24 upx (shidel): updated to v4.0.2
>> 2023-02-13 03:56:07 shsucdx (shidel): updated to v3.09
>> 2023-02-13 03:42:29 mined (shidel): updated to v2022.27
>> 2023-02-13 02:50:53 dosmid (shidel): updated to v0.9.6
>> 2023-02-13 02:40:27 debug (shidel): updated to v2.0
>> 2023-02-13 02:33:34 debug (shidel): updated to v1.29
>> 2023-02-05 09:41:23 jemm (shidel): updated to v5.83
>> 2023-02-05 09:33:45 himemx (shidel): updated to version 3.38
>> On a side note: When Bernd feels the changes he has made to FDISK are ready 
>> for general testing, we can include them in the FreeDOS archive on GitLab 
>> under an unstable branch. Then, those would get used by the RBE for the 
>> Interim Builds. But, no rush. :-)
>> 
>> 
>> ___
>> Freedos-devel mailing list
>>