Hi,
I have an idea which may prove fruitful for many FreeDOS users:
creating a catch-all shared pool of old (or even new) DOS programs.
I know, there are already websites with legacy software collections,
but what I have in mind would be something better, and more organized,
and above all
Hi. You hit on the sticking point: copyright. It is illegal in many
countries (including the US, where FreeDOS is hosted) to distribute
non-free, proprietary software in the way you propose. And much of the
legacy software you refer to is proprietary.
Even hosting copies of these proprietary
I would be happy to have an open, editable directory of legacy DOS
software, including screenshots descriptions. I think that part is a
great idea. But we would be unable to host or distribute any files, nor
link to sites that have them unless they are original shareware or other
distributable
There are various tools for Windows/Linux, which can display actual
CPU workload. Since DOS doesn't do multitasking, my guess is, that
here external utility won't be of any use. But DOS-program could
have it built-in. Could someone tell me the basic algorithm, which
could be used in DOS
Hi Zbigniew,
There are various tools for Windows/Linux, which can display actual
CPU workload. Since DOS doesn't do multitasking, my guess is, that
here external utility won't be of any use. But DOS-program...
Actually you can use FDAPM for that: While the APMDOS
function is active, FDAPM
2012/3/28, Eric Auer e.a...@jpberlin.de:
Actually you can use FDAPM for that: While the APMDOS
function is active, FDAPM keeps MSDOS POWER compatible
statistics of which percentage of the timer tick time
slices contains signs of DOS and the apps being idle.
In such situations, the cpu is
On Wed, Mar 28, 2012 at 5:21 PM, Zbigniew zbigniew2...@gmail.com wrote:
There are various tools for Windows/Linux, which can display actual
CPU workload. Since DOS doesn't do multitasking, my guess is, that
here external utility won't be of any use. But DOS-program could
have it built-in.
Hi Zbigniew,
Actually you can use FDAPM for that: While the APMDOS
function is active, FDAPM keeps MSDOS POWER compatible
statistics of which percentage of the timer tick...
You do not have to explicitly program anything for this:
Just run FDAPM APMDOS at some time, e.g. in your autoexec
and
2012/3/28, dmccunney dennis.mccun...@gmail.com:
While it *can* be done, I'm not sure why you want to.
On a multi-tasking OS like Windows or Linux, I'll use Process Explorer
(Win) or top (Linux), to get an idea of which programs are hitting the
CPU.
This time I would compare, how much CPU
2012/3/28, Eric Auer e.a...@jpberlin.de:
You do not have to explicitly program anything for this:
Just run FDAPM APMDOS at some time, e.g. in your autoexec
and then run FDAPM STATS to see how much of the time the
CPU was idle - to be exact, which percentage of the time
slices contained any
Hi Z,
This time I would compare, how much CPU time will my toy program
need on different machines. I would to make it show, how many percent
of CPU time was needed, if this can be possible.
For total runtime, you could do RUNTIME YOURPROGRAM at the prompt...
Why? Because I'm not going to
Since DOS environments typically don't multitask, there's no need to
time applications as they consume CPU resources and preempt them to let
other applications run. Modern multi core processors can do real
multitasking and don't have to simulate process concurrency. In DOS
environments,
2012/3/28, Michael Robinson plu...@robinson-west.com:
Since DOS environments typically don't multitask, there's no need to
time applications as they consume CPU resources and preempt them to let
other applications run. [..]
Ability to detect heavy CPU load can be important information
Op 29-3-2012 1:20, Zbigniew schreef:
Ability to detect heavy CPU load can be important information for me,
that e.g. I did something wrong (for example, some loop has to be done
differently).
In-app profiling, or using a debugger maybe, could help.
Otherwise, run DOS and your program inside
You know: graphics is one thing - this is just actual fun project -
but being able to detect instantly the weak place in program, which is
causing unnecessarily high CPU load (say: looping for a key without
any pause 10 ms), is the other useful thing. Then actually I'm
looking for something of
2012/3/28, Bernd Blaauw bbla...@home.nl:
In-app profiling, or using a debugger maybe, could help.
Otherwise, run DOS and your program inside an emulator
(QEMU/Bochs/DosEMU) and get detailed output (timestamped logfiles) from
that.
But of course using debugger I can check this in its every
On Wed, 2012-03-28 at 23:27 +, Zbigniew wrote:
You know: graphics is one thing - this is just actual fun project -
but being able to detect instantly the weak place in program, which is
causing unnecessarily high CPU load (say: looping for a key without
any pause 10 ms), is the other
On Wed, 28 Mar 2012 18:33:42 -0400, Zbigniew zbigniew2...@gmail.com
wrote:
This time I would compare, how much CPU time will my toy program
need on different machines. I would to make it show, how many percent
of CPU time was needed, if this can be possible.
Why? Because I'm not going to
18 matches
Mail list logo
