Re: [Freedos-devel] Booting and FDAPM

2023-03-18 Thread Bret Johnson
> ...
> By no means is VINFO perfect. In fact, there is a known issue in
> detecting some 486 based machines that I have not got around to
> fixing. Also, there some other things that could be done better.
> But, they are mostly minor issues that I have not found the time or
> motivation to remedy. Generally speaking, it is good enough for what
> it does and is under 3k when UPX compressed. 

Totally understandable, and I can completely relate to the lack of time and 
motivation.  I've got a LOT of programs I would like to update (some in some 
very major ways) and it's tough to get any of them done.

> ...

> I though I saw ISLOADED somewhere before. But, I just made a quick
> visit to your site and didn't notice it. If I recall correctly,
> the program does a lot of other things as well.

It's not on my web site because I've not yet officially released it.  I sent 
Jim a copy several weeks back which he posted -- that's probably where you saw 
a reference to it.  That was before I added all the VM stuff so it doesn't have 
that anyway, but it has over a hundred different things it can test for.  The 
version I sent to Jim did detect the Windows Virtual Machines (the VMs from 
DOS-based versions of Windows and NTVDM from Windows NT), but not the "modern" 
ones.  I know I've taken a thrashing recently on this forum over calling things 
VMs that some others call "Emulators", and you seem to use the term "Virtual 
Environment".  What Microsoft called Virtual Machines would probably not be 
called VMs by my modern detractors.

>> I also have another program called BATTSAVE which I think is sort
>> of "in-between" what IDELHALT does and what FDAPM does and it may
>> work better than either for the specific problem you're trying to
>> fix.  It's "not ready for prime time" either, but I can send it to
>> anyone who wants it...

> When you say not ready for prime time, why? Compatibility,
> incomplete, documentation, etc?
>
> Just generally speaking, how is it in-between IDLEHALT and FDAPM?

With ISLOADED, there are still a few tests I want to add, and need to do some 
more testing.  E.g., I was having problems with the VMware test where after I 
did the test VMware would start acting funny.  I need to track that down.

With BATTSAVE, there are several different C-states (power-saving states) that 
the CPU can be in.  C0 is the "normal" mode with no power saving.  C1 is 
triggered by the HLT CPU instruction used by IDLEHALT and FDAPM (at least last 
time I looked at it which was a long time ago).  On older CPUs C1 just stops 
the CPU from performing instructions but in 486+ CPUs the HLT instruction also 
disables some of the hardware clocks.  C2 saves even more power than C1 and 
also restarts everything when a hardware interrupt occurs.  C3 and beyond don't 
restart things when an interrupt occurs so probably aren't good for DOS.  There 
are also C-states like C1E and C2E.

Anyway, for BATTSAVE I want to allow C2 as an option to save even more power 
than HLT can do.  But C2 is started through an I/O port instead of a CPU 
instruction and there is no standard I/O port.  I think the only way to 
determine the correct I/O port to use is via ACPI, and if you've ever dealt 
with ACPI you know what a HUGE pain it is.  I've experimented with C2 a little 
bit, but still need to do more.

Also, I suspect that in VMs C2 won't actually do anything useful at all.  This 
is based on the fact that in VMs disabling the cache in the virtual CPU doesn't 
seem to do anything at all (at least on the VMs I've tested).  On real hardware 
disabling the cache has a HUGE effect.  That's actually one of the tests I use 
to detect a "generic" VM in ISLOADED.

For a power saving program to work in DOS it must monitor CPU instructions for 
programs to declare themselves "idle" (either directly or indirectly).  From 
the documentation on IDLEHALT, it only monitors a limited number of CPU 
instructions.  I think BATTSAVE monitors more than IDLEHALT, and FDAPM does a 
lot more than BATTSAVE (like interacting with the APM BIOS if there is one).

In addition, I have BATTSAVE right now toggle a character on the screen to 
indicate when it has entered the power saving mode and also indicates which CPU 
instruction caused the "trap".  This is there for testing purposes.  I 
originally thought I would remove this when I actually released the program, 
but kind of like it and think I will probably add some command-line options to 
control the toggling in case the user actually wants to see the operation, and 
maybe even a hot-key so the user can control the screen toggling in "real-time".

Neither program has currently any documentation other than the comments in the 
source code.

> Regardless, both programs sound interesting. When you feel they are
> ready for more public use/testing, it might be nice for them to get
> wrapped in a package and put on the download repo. Possibly, included
> on one of the release media as well. But, that is a 

Re: [Freedos-devel] Booting and FDAPM

2023-03-18 Thread jerome
Hi Bret,

> On Mar 17, 2023, at 9:41 PM, Bret Johnson  wrote:
> 
>> Tom's suggestion of using IDLEHALT is most likely the best solution.
>> 
>> As you suggest, Using IDLEHALT for VM's and FDAPM for real
>> hardware on installed systems will be easy to do.
>> 
>> Since such decisions cannot be made automatically during boot in the
>> CONFIG at present, probably just switch to using IDLEHALT on the
>> LiveCD as well.
> 
> Just a couple of ideas from some things I've been working on.  One is that 
> with my ISLOADED program I can now detect about 25 different specific VMs and 
> also have a set of tests that can detect the presence of a "generic" VM 
> without specifically being able to identify which one it is.  The program is 
> not yet "ready for prime time", but I will send the code and current version 
> of the program to anyone who wants it.  It might come in handy for the 
> FreeDOS install program.

At present, VM detection is performed with VINFO  (part of 
V8Power Tools for DOS). That  testing is very reliable. But, it only tests for 
the (in my opinion) major virtual platforms VMware, VirtualBox, QEMU and 
DOSBox. It also performs a generic VM test in an attempt to catch others. It 
also performs some other tasks related to installation, like CPU, hard drive 
and MBR boot code detection. 

By no means is VINFO perfect. In fact, there is a known issue in detecting some 
486 based machines that I have not got around to fixing. Also, there some other 
things that could be done better. But, they are mostly minor issues that I have 
not found the time or motivation to remedy. Generally speaking, it is “good 
enough” for what it does and is under 3k when UPX compressed. 

Possibly at some point, we may switch to “better” tools to perform the tasks 
required of VINFO. I’m definitely not opposed to switching. After all, I’m lazy 
and that would keep me from needing to eventually improve that utility. But at 
least for time being, I don’t think it would be worth the effort of trying to 
migrate to a different utility for a more nuanced VM detection. 

I though I saw ISLOADED somewhere before. But, I just made a quick visit to 
your site and didn’t notice it. If I recall correctly, the program does a lot 
of other things as well. 

> I also have another program called BATTSAVE which I think is sort of 
> "in-between" what IDELHALT does and what FDAPM does and it may work better 
> than either for the specific problem you're trying to fix.  It's "not ready 
> for prime time" either, but I can send it to anyone who wants it.  I 
> developed it mainly for use when I am traveling and using my laptop and need 
> the battery to last longer when I'm using DOS.

When you say “not ready for prime time”, why? Compatibility, incomplete, 
documentation, etc?
Just generally speaking, how is it “in-between” IDLEHALT and FDAPM? 

Regardless, both programs sound interesting. When you feel they are ready for 
more public use/testing, it might be nice for them to get wrapped in a package 
and put on the download repo. Possibly, included on one of the release media as 
well. But, that is a discussion for another day. :-)

On a completely unrelated and non-FreeDOS related topic…

When I was at your site, I noticed you put your city/state on the page. I’ve 
been out your way twice when the balloon thing was happening. Once in the 
mid-90s, and again a couple years later. Hundreds, if not thousands, of hot air 
balloons in the sky. Flying hamburgers, fork-lifts, animals and stranger 
things. Some not making it and crashing into trees and houses. It was 
definitely a sight to see. They still do that each year?

:-)

Jerome



> ___
> 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] Booting and FDAPM

2023-03-17 Thread Bernd Boeckmann via Freedos-devel

> Am 17.03.2023 um 19:25 schrieb tom ehlert :
> 
> in that case: WHAT REGRESSIONS?

To name one: The text editor segfaulted right after start. Can happen if you 
are using a development snapshot. It is fixed by now because the current 
maintainer is very committed to solving the bugs and tracks them thoroughly at 
https://github.com/open-watcom/open-watcom-v2/issues

The software is in flux and a „stable“ build has not been released.  A 
development snapshot may be shipped as the main C compiler, but one should be 
prepared for surprises.



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


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread tom ehlert

> IDLEHALT=1 works for my machines and reduces the CPU load under
> VirtualBox to nearly zero at the command prompt.

:-)))


  FDAPM whatever

should be REMified.

OTOH this seems to be a problem between FDAPM,
VirtualBOX and Watcom Installer. Whoever wants to develop ON FreeDOS
...



>> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net:
>> 
>> On a side note… Why run the watcom installer at all? Installing the FreeDOS 
>> WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded 
>> takes about 1 minute inside VirtualBox. We could most likely just provide a 
>> WATCOM2C package and avoid the whole issue completely. 
+1

> If v2 is packaged would it be possible to continue shipping the 1.9
> branch in parallel?

NO.

Anyone who hasn't installed watcom so far won't be able to answer this
question.

and anyone able to answer this question will be able to download the
other version.

and, of course, developing ON FreeDOS is self flaggelation ...



> My impression is that the v2 fork focusses on
> adding new stuff: Linux support, 64-bit and so forth… And from time
> to time they seem to break older stuff. I at least under Win9x encountered 
> some regressions.

in that case: WHAT REGRESSIONS?


Tom



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


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread Bernd Boeckmann via Freedos-devel
IDLEHALT=1 works for my machines and reduces the CPU load under VirtualBox to 
nearly zero at the command prompt.

> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net:
> 
> On a side note… Why run the watcom installer at all? Installing the FreeDOS 
> WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded takes 
> about 1 minute inside VirtualBox. We could most likely just provide a 
> WATCOM2C package and avoid the whole issue completely. 

Yes, was only for testing purposes :-) 

If v2 is packaged would it be possible to continue shipping the 1.9 branch in 
parallel? My impression is that the v2 fork focusses on adding new stuff: Linux 
support, 64-bit and so forth… And from time to time they seem to break older 
stuff. I at least under Win9x encountered some regressions.

Greetings, Bernd



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


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread wilhelm . spiegl
I ran a test with idlehalt=0 / -1 / 1 and put fdapm to rem in virtualbox


Fast speed with 0 and 1! 

idlehalt=-1 gave slow speed. 

After this I removed idlehalt and activated fdapm again - and then ran
fdapm off  : fast speed. 

Willi 

Am 2023-03-17 15:34, schrieb jer...@shidel.net:

> On Mar 17, 2023, at 10:07 AM, Rugxulo  wrote:
> 
> Hi,
> 
> On Fri, Mar 17, 2023 at 5:32 AM  wrote: 
> At present, the FreeDOS installed system and installer boot media load FDAPM 
> on many hardware configurations and virtual machines.
> 
> As most are aware, there has recently discussed issue that the watcom 
> installer was taking an excessively long time to install.  The problem only 
> occurred when FDAPM was loaded. This was regardless of which power saving 
> options were used.  Should we cut back on when it is loaded? 
> I almost forgot that the Borland IDE tools were also slowed down when
> FDAPM was loaded. That is a known issue.
> 
> What I'm thinking is we more or less keep things as they are. But, add an 
> exception to the various AUTOEXEC files that skips loading it as a driver 
> when the OS is running under a known VM like VirtualBox, VMware, etc.
> 
> Any thoughts? 
> Yeah, just turn it off if under a VM (and document why with a REM
> comment). Oh, and turn on IDLEHALT like Tom suggests.

Sorry, I forgot about it effecting other things as well. So, just making
a WATCOM2 package would not solve any other slowdown issues.

Assuming, there is no large slowdown in the watcom installer with
IDLEHALT. 

Tom's suggestion of using IDLEHALT is most likely the best solution. 

As you suggest, Using IDLEHALT for VM's and FDAPM for real hardware on
installed systems will be easy to do.

Since such decisions cannot be made automatically during boot in the
CONFIG at present, probably just switch to using IDLEHALT on the LiveCD
as well.

:-)

Jerome

> ___
> 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___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread jerome


> On Mar 17, 2023, at 10:07 AM, Rugxulo  wrote:
> 
> Hi,
> 
> On Fri, Mar 17, 2023 at 5:32 AM  wrote:
>> 
>> At present, the FreeDOS installed system and installer boot media load FDAPM 
>> on many hardware configurations and virtual machines.
>> 
>> As most are aware, there has recently discussed issue that the watcom 
>> installer was taking an excessively long time to install.  The problem only 
>> occurred when FDAPM was loaded. This was regardless of which power saving 
>> options were used.  Should we cut back on when it is loaded?
> 
> I almost forgot that the Borland IDE tools were also slowed down when
> FDAPM was loaded. That is a known issue.
> 
>> What I’m thinking is we more or less keep things as they are. But, add an 
>> exception to the various AUTOEXEC files that skips loading it as a driver 
>> when the OS is running under a known VM like VirtualBox, VMware, etc.
>> 
>> Any thoughts?
> 
> Yeah, just turn it off if under a VM (and document why with a REM
> comment). Oh, and turn on IDLEHALT like Tom suggests.

Sorry, I forgot about it effecting other things as well. So, just making a 
WATCOM2 package would not solve any other slowdown issues.

Assuming, there is no large slowdown in the watcom installer with IDLEHALT. 

Tom’s suggestion of using IDLEHALT is most likely the best solution. 

As you suggest, Using IDLEHALT for VM’s and FDAPM for real hardware on 
installed systems will be easy to do.

Since such decisions cannot be made automatically during boot in the CONFIG at 
present, probably just switch to using IDLEHALT on the LiveCD as well.

:-)

Jerome

> 
> 
> ___
> 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] Booting and FDAPM

2023-03-17 Thread jerome
Hi,

> On Mar 17, 2023, at 7:58 AM, tom ehlert  wrote:
> 
> Hallo Herr Bernd Boeckmann via Freedos-devel,
> 
> am Freitag, 17. März 2023 um 12:52 schrieben Sie:
> 
> 
>>> Any thoughts?
> 
>> I have some additional data:
> 
>> 1) Pentium MMX 166,  T2303 default installation:
> 
>> Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes.
>> After FDAPM OFF:  4:30 Minuten.
> 
>> 2) VirtualBox, activated APM: aborted after 2 minutes @ 10%
> 
>> 3) VirtualBox with LH FDAPM ADV:REG same as 2)
> 
>> 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-)
> 
>> BUT!
> 
>> Disabling FDAPM under VirtualBox significantly increases the CPU
>> load on the host system! It essentially maxes out one CPU core.
> 
> could you test also
> 
> CONFIG.SYS:
> 
> IDLEHALT 1
> 
> 
> which might be still fast, but saves most of the energy.
> Tom

Having the system decide wether to us FDAPM, IDLEHALT or nothing inside the 
CONFIG.SYS at boot time is not practical at present. However during 
installation process, the installer can make adjustments or install different 
config files based on hardware or virtual platform. So, using IDLEHALT instead 
of FDAPM when booting an installed system inside a VM would be easy to do.

Also… I’m not sure if during testing anyone tried to boot with things as they 
are now. Then, simply turn it off before running the watcom installer. By 
running: FDAPM APMoff

On a side note… Why run the watcom installer at all? Installing the FreeDOS 
WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded takes 
about 1 minute inside VirtualBox. We could most likely just provide a WATCOM2C 
package and avoid the whole issue completely. 

:-)

Jerome


> 
> ___
> 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] Booting and FDAPM

2023-03-17 Thread Rugxulo
Hi,

On Fri, Mar 17, 2023 at 5:32 AM  wrote:
>
> At present, the FreeDOS installed system and installer boot media load FDAPM 
> on many hardware configurations and virtual machines.
>
> As most are aware, there has recently discussed issue that the watcom 
> installer was taking an excessively long time to install.  The problem only 
> occurred when FDAPM was loaded. This was regardless of which power saving 
> options were used.  Should we cut back on when it is loaded?

I almost forgot that the Borland IDE tools were also slowed down when
FDAPM was loaded. That is a known issue.

> What I’m thinking is we more or less keep things as they are. But, add an 
> exception to the various AUTOEXEC files that skips loading it as a driver 
> when the OS is running under a known VM like VirtualBox, VMware, etc.
>
> Any thoughts?

Yeah, just turn it off if under a VM (and document why with a REM
comment). Oh, and turn on IDLEHALT like Tom suggests.


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


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread tom ehlert
Hallo Herr Bernd Boeckmann via Freedos-devel,

am Freitag, 17. März 2023 um 12:52 schrieben Sie:


>> Any thoughts?

> I have some additional data:

> 1) Pentium MMX 166,  T2303 default installation:

> Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes.
> After FDAPM OFF:  4:30 Minuten.

> 2) VirtualBox, activated APM: aborted after 2 minutes @ 10%

> 3) VirtualBox with LH FDAPM ADV:REG same as 2)

> 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-)

> BUT!

> Disabling FDAPM under VirtualBox significantly increases the CPU
> load on the host system! It essentially maxes out one CPU core.

could you test also

CONFIG.SYS:

IDLEHALT 1


which might be still fast, but saves most of the energy.
Tom



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


Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread Bernd Boeckmann via Freedos-devel


> Any thoughts?

I have some additional data:

1) Pentium MMX 166,  T2303 default installation:

Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes.
After FDAPM OFF:  4:30 Minuten.

2) VirtualBox, activated APM: aborted after 2 minutes @ 10%

3) VirtualBox with LH FDAPM ADV:REG same as 2)

4) VirtualBox FDAPM deactivated: installation time 4 seconds :-)

BUT!

Disabling FDAPM under VirtualBox significantly increases the CPU load on the 
host system! It essentially maxes out one CPU core.

Greetings, Bernd



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