Hi,
On Fri, Jan 20, 2017 at 6:48 PM, Jerome Shidel wrote:
>
> It is even worse than you suggested for Turbo Pascal compiled programs for LF
> only files.
> The entire built-in text I/O system can't go anywhere near such files. If it
> does, you end up
> with an infinite display loop crash.
But
> Because ACPI, even in the oldest versions, is a complex description
> and programming language with a virtual machine and everything, the
> few things done with ACPI by FDAPM are based on "keyword spotting"
> in the ACPI code. In particular on newer systems, this often fails.
> However, implement
Rugxulo,
It is even worse than you suggested for Turbo Pascal compiled programs for LF
only files. The entire built-in text I/O system can't go anywhere near such
files. If it does, you end up with an infinite display loop crash.
Hi,
(changing the subject a bit)
On Thu, Jan 19, 2017 at 3:35 PM, Ralf Quint wrote:
> On 1/19/2017 1:16 PM, Eric Auer wrote:
>> Rugxulo, Tom,
>>
>> DOS files should always use DOS linebreaks,
>> even if some DOS apps can deal with Unix ones.
> +1
>
> It's just too bad that a lot of people are se
On Fri, Jan 20, 2017 at 6:06 PM, Rugxulo wrote:
> On Thu, Jan 19, 2017 at 5:51 PM, dmccunney wrote:
>>
>> At one point, I had to insert a step in a *nix script that generated
>> and emailed nightly reports. The recipients would get them as
>> attachments on Windows machines, and double click the
Hi,
On Thu, Jan 19, 2017 at 5:51 PM, dmccunney wrote:
>
> At one point, I had to insert a step in a *nix script that generated
> and emailed nightly reports. The recipients would get them as
> attachments on Windows machines, and double click them to read them,
> which by default invoked Notepad
Hi,
On Thu, Jan 19, 2017 at 4:40 PM, Jerome Shidel wrote:
>
> As a side note on this issue, there are many dos2unix programs out there.
> But, last time I
> checked (many years ago) very few unix2dos versions.
A quick check at D2U734B.ZIP shows: dos2unix.exe, unix2dos.exe,
mac2unix.exe, unix2m
Hi Ralf and Ira,
> The problem is just to load everything and the kitchen sink by default,
> regardless if needed or not. FDAPM is not necessary to run FreeDOS
The kernel has a built-in IDLEHALT option which you can activate
in config sys and which already implements the core idea: To stop
the
> The version of FDAPM is dated 11 Sep 2009 and does not have an ADV option.
Yes it does. Even the 2005 version has it, but it is not
shown in the /? help screen. Only the longer explanations
included as separate text document mention ADV options ;-)
Eric
The version of FDAPM is dated 11 Sep 2009 and does not have an ADV option.
I installed using the legacy CD.
Ira
irami...@gmail.com 805-212-0588
On Fri, Jan 20, 2017 at 1:24 PM, Eric Auer wrote:
>
> Hi Ira,
>
> if FDAPM APMDOS slows down your FreeDOS (on which hardware?
> or in which environme
On 1/20/2017 1:24 PM, Eric Auer wrote:
> Hi Ira,
>
> if FDAPM APMDOS slows down your FreeDOS (on which hardware?
> or in which environment, if not on bare physical hardware?)
> then you can try FDAPM ADV:REG instead, as APMDOS defaults
> to ADV:MAX which might be "overdoing" the energy savings in
>
Thanks. I was using the fdconfig.sys and autoexec.bat that were generated
when I installed FreeDOS. At bootup I use the first choice. I am running
natively on a 486.
once I commented out LH FDAPM APMDOS in autoexec.bat and rebooted my
compiles run at full speed. FDAPM has a SPEED subcommand that ch
Hi Ira,
if FDAPM APMDOS slows down your FreeDOS (on which hardware?
or in which environment, if not on bare physical hardware?)
then you can try FDAPM ADV:REG instead, as APMDOS defaults
to ADV:MAX which might be "overdoing" the energy savings in
certain situations.
Note that the SPEED settings
On Fri, Jan 20, 2017 at 2:58 PM, Ira Minor wrote:
> My guess is that the default in FreeDOS is to run slow so games will run
> correctly.
I don't believe so. DOS is a single user, single tasking OS. When
you ran a game, DOS was involved in loading it, but the game then took
over and directly a
What is your EMS/XMS configuration? Do you have a drive cache in
installed? Do you have a RAM Disk Driver installed?
Providing the autoexec.bat and config.sys for both installs would be helpful.
On Fri, Jan 20, 2017 at 11:58 AM, Ira Minor wrote:
> I recently installed FreeDOS 1.2 in order to d
I recently installed FreeDOS 1.2 in order to develop DOS apps using Turbo C
2.01. Small apps that compile almost instantly on DOS 7.1 take a very long
time using FreeDOS. I REMed out LH FDAPM APMDOS in autoexec.bat and my
compiles sped up and are now as fast as DOS 7.1. My guess is that the
default
> Am 20.01.2017 um 17:21 schrieb Tom Ehlert :
>
> as stated elsewhere, the bug happens when
>
>FIND is compiled using TC 2.01
>you have no drive in A:
>
> it's simply a bug in FIND
Thank you very much. I was just curious. Never came across it before.
--
>> Am 16.01.2017 um 13:12 schrieb BlameTroi :
>> I got this after a FIND command.
>>
>> C:\ELVIS\DOC>find /i "env" e*.htm
>> file list ...
>> Error reading from drive A: DOS area: general failure
>>
>> I've triple checked and I have nothing in my autoexec or config that
>> points to drive A
> Am 16.01.2017 um 13:12 schrieb BlameTroi :
> I got this after a FIND command.
>
> C:\ELVIS\DOC>find /i "env" e*.htm
> file list ...
> Error reading from drive A: DOS area: general failure
>
> I've triple checked and I have nothing in my autoexec or config that
> points to drive A:, nor do
On Thu, 19 Jan 2017 17:40:03 -0500, Jerome Shidel wrote:
> Other than install and remove, I don’t think
> FDNPKG & FDINST do anything with them.
FDNPKG & FDINST only read the LSM files indeed, and they are designed to
handle both CR/LF and LF line endings ("a line ends with a single LF" +
"if it
20 matches
Mail list logo
