Re: [Freedos-user] Some driver updates

[Tom Ehlert]

during the time that all the contributions in this thread were
written AND READ, competent programmers could have ported the kernel
to GCC, with some time left to save the planet, and fight for peace on
earth.

just my 2 cents.

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Some driver updates

[Tom Ehlert]

during the time that all these responses were written AND READ, competent
programmers could


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Some driver updates

[Tom Ehlert]

> Also, did you know that UMBPCI is actively maintained
> and more reliable in finding out which areas can be
> used for UMB etc. than JEMM / JEMM386? So it can be
> a good idea to use explicit EMM options based on what
> UMBPCI detected: This avoids more conflicts than the
> easier method of letting JEMM / JEMM386 autodetect.

interesting.

can you try to contact Uwe Sieber if he would be willing to
share his used memory detection logic.

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Some driver updates

[Tom Ehlert]

Dear Eric,


> Hi :-) Quick news from Jack's drivers: He has a closed
> source update for XMGR (more fail-safe 386 XMS move)
> and UHDD: The new UHDD has the interesting feature of
> read-ahead for cache sizes of at least 20 MB. It is
> a simplified version without I/O overlap and DOS RAM
> search table location and "/G" command line options.
> Sample copies can be requested from Johnson or Jack.

even closed, unfree, paid for software usually comes with a link so I
can find more description (rather then 'more fail-safe 386 XMS move'),
download it, see fee ( '25$ per PC'), limitations ('not for military'),
price and more.

but 'can be requested from Johnson or Jack', meaning
 'on a good day, Jack might decide to send you a copy.
  on a bad day, NOT.'

is the stupidest thing I have read for a long time.
this has no place on this list, and you should know that.

it's even stupider as most readers of this list have no email address
of Johnson or Jack.



just as a tiny side note:

I am only aware of 2 persons THAT CONSISTENTLY SHOUT.
Jack and the american president.


Tom




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New FreeDOSers Monthly Reminder

[Tom Ehlert]

Hallo Herr John Price,

can we please have this monthly remainder stopped?

it is just unnecessary

Tom


am Mittwoch, 1. November 2017 um 07:00 schrieben Sie:


> MONTHLY REMINDER FOR THE FREEDOS MAILING LISTS

> Hello, and welcome to the FreeDOS mailing list!

> If you have been a list member for some time, then you can skip this
> as you should be familiar with the rules by now.

> --

> The FreeDOS Project aims to create a free, complete implementation of
> classic DOS. DOS is still a popular system, and plenty of people use
> FreeDOS to play classic DOS games, run legacy software, and support
> embedded systems. For more information about FreeDOS, visit:

>   http://www.freedos.org/


> We have only a few rules for posting to the FreeDOS mailing lists:

> 1. Don't swear. We don't want this mailing list to become what Usenet
>turned into.

> 2. Keep posts on-topic. Remember, we set up this mailing list to
>discuss FreeDOS issues.

> 3. No flame wars. If you feel really strongly against what someone has
>said, send a reply off-list.


> Some suggestions:

> ** Please send only plain text email messages, rather than messages
>formatted in HTML. Plain text makes it easier for everyone to read
>your posts. Above all, HTML email is particularly difficult for
>some screen readers.

> ** When replying to messages, please quote just the bit of email you
>are replying to. Don't copy the whole conversation if you don't
>need to.

> --

>   
>   

> /* This is an automated message sent out to the mailing list at the
> first of each month.  It is automagically downloaded from 
> http://freedos.sourceforge.net/freedos/lists/remind.txt 

> Feel free to contact John Price if necessary by replying to this
> message. */


> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] V8Power Tools -- Update

[Tom Ehlert]

>> Hi Jerome,
>> I've just tried your veach.com utility and it looks like it shall really
>> come in handy! I was missing a program capable of appending a command to a
>> sorted list (like a  |   in Unix ) .
>> Nice job, and thanks for your effort

> Thank you.

> Just like you, I would find myself either doing some things the long way 
> because
> there was just no easy way to do X on a list of things. Wether that list was 
> some
> generic things I wanted to run through a program or something more complex.

> Besides, what other utility will let suicidally run every program in a 
> directory with a
> simple “veach /d *.* /c /x”  command? :-)

> I could have really used veach in FDI. But, I didn’t require it. With all the 
> ASCIIZ
> string juggling and parsing it would need to do, I procrastinated making it. 
> But alas,
> I finally got to it.

veach /d *.bmp  /x resize * /scale 50%

is more or less the same as

 FOR %i in (*.bmp) do resize %i /scale 50%

(use %%i when used in batch files)

from a batch file, FOR has also lower memory requirements although
this is most likely irrelevant for FDI

unfortunately this turns up a bug in FOR:


for %i in (*.*) do echo %i

works as expected, also echoing the command itself.

E:\FREEDOS\SRC>echo SOFTIC~1.IMA
SOFTIC~1.IMA

however

for %i in (*.*) do @echo %i

E:\FREEDOS\SRC>@echo SOFTIC~1.IMA
Bad command or filename - "@ECHO".


bug report filed

Tom.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS as a everyday/common-use system; Pros of making FreeDOS and Windows3 more compatible

[Tom Ehlert]

> It's more possible than ever [0] to compile the kernel with GCC.
'This part of DJGPP is dedicated to the 16-bit tools that have been developed 
to assist in using DJGPP.

Note: I lost interest in these projects before I completed them.'


> Yes, it would be a large under taking but maybe a long term worthwhile
Yes, as long as YOU invest YOUR time on this.

> goal as OW has seem to lost a bit of steam.
a reliable, proven compiler is all we need.
we don't need a compiler with steam.

btw, just in case you lived on a different planet for the last 10+ years,
freedos also lost a bit (or all ) of steam,


with the sole and remarkable
exception of etherdfs, where some new, and even useful software was
recently created. no, a new setup every 5 years doesn't count.


> [0] http://www.delorie.com/djgpp/16bit/


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] bsum - compute BSD checksums of your files

[Tom Ehlert]

From: Tom Ehlert <t...@drivesnapshot.de>

>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>> "jumps", MASM "option ljmp", etc).
right.

>> I won't argue about what opcode is or is not available on 8086, since I
>> did not bother decoding their exact meaning.

meaning 'I am a lazy, clueless guy, but write anyway ...'

>> I do see however that (NASM
>> at least) can assemble JZ and JZ SHORT in two very different forms, JZ
>> SHORT being significantly shorter.
>>
>>   5  B80100  mov ax, 1
>>   6 0003 48  dec ax
>>   7 0004 746Ajz short gameover
>>
>>   5  B80100  mov ax, 1
>>   6 0003 48  dec ax
>>   7 0004 7503E9DD01  jz gameover
>>
>> Of course NASM always uses the short form whenever it's possible, but
>> when the jump is too far away it silently uses the longer form, hence the
>> need to always specify SHORT if one wants to be sure what's going on.

> AFAIK,
meaning 'I am completely clueless , but offer my unfounded opinion anyway ...'

> the longer one is 386+ only, hence not available with "cpu
> 8086". Thus, if it still quietly assembles, that is a bug (but I
> thought that was long-ago fixed/avoided).

the longer one is 2 instructions instead, automatically generated by NASM
because the intended jump goes farther then 127 bte


c:\>debug
-e 100
1430:0100  00.75   00.03   00.e9   00.dd   00.01
-u 100
1430:0100 7503  JNZ 0105
1430:0102 E9DD01JMP 02E2


Tom



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (276:10/901)
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedo

[Tom Ehlert]

From: Tom Ehlert <t...@drivesnapshot.de>

Hello again,

> Do you want to load FreeDOS High, UMB?

there is no good reason (for normal use) to have ever

DOS=HIGH,UMB

disabled. if no HIGH or UMB memory is found, it is silently ignored.


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (276:10/901)
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedo

[Tom Ehlert]

From: Tom Ehlert <t...@drivesnapshot.de>



> Why not use the CHOICE option-a to let the user decide?

because 99,9 % of all user have no need for SHARE.

> I have a
> menu system which is designed to be used on a network and requires share to
be loaded

are really multiple machines accessing the same files at the same
time?

> IMHO this should be used of the FDNET option as well to allow users
> to copy their specific packet driver to the /FDOS/NETWORK dir to
> avoid an error msg after initial installation..

Tom

> On Sat, Jan 21, 2017 at 6:21 PM, Jerome Shidel <jer...@shidel.net> wrote:

> Tom,

 >> what purpose is SHARE supposed to have?
 >> SHARE is useful when the machine is running as a server, or with
 >> windows (or any other multitasking OS).
 >>
 >> don't install this.

> You are probably correct that it should load it by default.

>  I remrCOd it out for future releases.

>  Jerome

> --
>  Check out the vibrant tech community on one of the world's most
>  engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>  ___
>  Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user





Mit freundlichen Gr|+|fen/Kind regards
Tom Ehlert
+49-241-79886


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (276:10/901)
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedo

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

Hi,

to reproduce this FIND problem, I tried to setup a new FD1.2 machine.

what I did:

download FD12LGC.ISO

create a new virtual box machine with 512 MB disk
use FD12LGC.ISO to boot the machine.
boot machine.


'Unfortunately, this method of installation is not supported on this
hardware platform. Please try a different installation method.'

Welcome to the FreeDOS 1.2 operating system.



now what?
a hint to use the other .ISO would have been be helpful

eventually I figured this out, and setup was successful.


some remarks though:

the setup results in

FDCONFIG.SYS:

12:DOS=UMB

makes virtually never sense. DOS=HIGH,UMB is always the better
option.

what purpose is SHARE supposed to have?
SHARE is useful when the machine is running as a server, or with
windows (or any other multitasking OS).

don't install this.

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] after

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>


I could reproduce this.

it happens in/after findnext()

this error is related to the compiler.

if the source is compiled using TurboC 2.01 the error occures.

compiling the exact same source with TCPP the error is gone.

try www.drivesnapshot.de/freedos/findtcpp.com and
www.drivesnapshot.de/freedos/findtc21.com

of course this can be a kernel bug, but as well a turbo library bug,
or some sort of interference between them.

Tom







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] dma cr

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>


> I keep getting the error-adma crosses 64k boundary when using tools
> like rawrite3 or hard drive manufacturers tools floppy creation
> software. I need to boot from Windows 98 bootdisk to get rid of it.

> Please let me know if there is a way to get rid of this problem under
FreeDOS.

MSDOS redirects int 13 to an internal driver, detects DMA access crossing a
64k boundary,
and avoids it.

FreeDOS ddoes not do this; sorry.

there was no need to do this so far; IMO rawrite3 could/should handle
this by itself. of course, software is usually only tested against
MSDOS, so there is little motivation to do so for rawrite3
programmers.

I'm still surprised this comes up today, and not 15 years ago.
do you have remarkable hardware?

Tom


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

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] How to

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

Hallo Herr Kai Schaetzl,

am 18. August 2016 um 15:31 schrieben Sie:

> Tom Ehlert wrote on Mon, 15 Aug 2016 16:00:55 +0200:

>> an amazing amount of effort to get a german keyboard driver

> Not really once you know that you don't need the .kl file.
> According to
> http://help.fdos.org/de/hhstndrd/base/keyb.htm
> you have to run (as an example) "keyb GR,,GR GR.KL /E".
> You need the .kl file for this.
> However "keyb gr" suffices. Just that it's not mentioned anywhere. As I
> said I assume the GR layout is embedded in keyboard.sys, anyway.

> With that in mind, it's the same as with your driver: download and run
> "keyb gr". Anyway, just to see if there's a difference I changed now to
> mkeyb. Both keyboard drivers work.

> But I have the same problem with it. Adding "keyb gr" to autoexec.bat does
> not run it. It seems autoexec.bat isn't executed at all.

if something 'seems', add

   echo HELLO WORLD

to the front of your autoexec.bat


> Shouldn't it run
> automatically once DOS is loaded?

yes.
as our clairvoyant has left us, how about posting CONFIG.SYS?



> Thanks!

> Kai




Mit freundlichen Grn#en/Kind regards
Tom Ehlert
+49-241-79886


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

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] How to

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

Kai,

an amazing amount of effort to get a german keyboard driver :<<


> Hi Eric,

> thanks for the quick reply. In the meantime I found out that I can load a
> German layout with just "keyb gr", just not the layout file itself or the
> /E switch that is mentioned in that article. I assume the gr.kl is
> embedded in the keyboard.sys file.
> That's good enough for me. I don't need the Euro sign. I use FreeDOS
> mainly on a USB stick for flashing bios and controller cards on rack
> machines and my own workstations. And it drives me crazy if I have to
> input some special characters like - _ / which commonly occur. Each time I
> have to go by trial and error. And it seems you cannot type a ~ (tilde) at
> all on a German keyboard under an en-us layout.
> Now I can :-)
> There is one thing still with keyb, though, that makes me wonder.
> Shouldn't I be able to run it from autoexec.bat? I added "keyb gr" to it,
> but it isn't executed (or it doesn't work at this stage). I have to run it
> manually at the prompt. I'm also running keybw.com in autoexec.bat, right
> before that. I don't know what that does. I just have it in there and
> don't know if I added it some time ago or if it came with the first
> FreeDOS configuration. Should I remove it?

>> The KEYB layouts can be found here:
>>
>> http://www.freedos.org/software/?prog=kpdos

> That's the point where the circle starts (and ends). There are no plain
> keyboard layout files (.kl) in there, only the .key files. But these need
> kc for compiling to a .kl file. And there's nowhere you can get kc from.

in that case, KPDOS does not qualify as open source, and I recommend to
remove KPDOS from future releases of FreeDOS


> I don't need it now anymore it seems. But still wondering if it's really
> not available from anywhere.

>> Viel Spass!

> Gleichfalls, von Berlin nach Berlin :-)

> Kai


instead I recommend

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/mkeyb/mkeyb041
zip

and a command line

  KEYB GR

(note: I'm the author)



Mit freundlichen Grn#en/Kind regards
Tom Ehlert
+49-241-79886


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Ynt: U

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

Dear Eric Auer,

could concentrate ONCE on the problem at hand, and not on all this
blablabla about file versions?


the problem seems to be that this freedos.img, booted in VirtualBox,
is able to generate funny characters (i without dot, C with hook, ...)
and not on real hardware.

now it would be cool if we had a screenshot (photo) of this iamge,
booted on real hardware.

btw: don't use EMM386 at all (for the moment), although I would not
expect problems.

now remove EVERYTHING not strictly necessary except keyboard.sys

last question: do you have the problem on the command line as well, or
only in VTUR?

Tom




am 10. September 2016 um 13:52 schrieben Sie:


> Hi Salih,

> thanks for sharing the 1.44 MB boot floppy image. It is correct that
> you cannot send files to the list, but the config & autoexec easily
> fits into a mail for the list by cut and paste:

>> !DEVICE=A:\DRIVER\HIMEM.EXE

> Supports options to manually select things but default should be okay.

>> !DEVICE=A:\DRIVER\EMM386.EXE FRAME=d800 X=TEST

> If you do not really need EMS 3 support, you should not force EMM386
> to provide a page frame. In particular, you should not force it to
> use a hardcoded location which may or may not work on a given system.

> You could for example try: X=TEST I=TEST NOEMS /VERBOSE

>> !COUNTRY=090,857,A:\DRIVER\COUNTRY.SYS
>> !SHELL=A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FREEDOS\FDAUTO.BAT

>> !DEVICEHIGH=A:\DRIVER\XDMA.SYS

> XDMA is rather old. If you do not need it, you can skip it.

>> !DEVICE=A:\DRIVER\SRDXMS.SYS

> You may want to specify the size of the desired ramdisk here?

>> !DOSDATA=UMB
>> !DOS=HIGH,UMB
>> !FILES=120
>> !BUFFERS=30
>> !LASTDRIVE=Z

>> @echo off
>>
>> PATH=A:\;A:\FREEDOS;A:\DRIVER
>>
>> DISPLAY con=(EGA,857,1)
>> mode con codepage prepare=((857) A:\FREEDOS\EGA.CPX)
>> mode con codepage select=857
>> NLSFUNC /Y A:\DRIVER\COUNTRY.SYS
>> KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179

> Interesting that you specify a special variant of keyboard.
> As mentioned earlier, you may want to use /NOHI for KEYB.

>> VTUR

> Your software gets started at boot automatically.



> Finally, here is a full list of versions of used files. They
> seem to be a bit old in general, but it is quite possible that
> many files simply had no updates since then, as they already
> had reached the desired state.

> File sizes & versions root:

>315 fdconfig.sys
>  46685 KERNEL.SYS 2042 (build 2042 OEM:0xfd) [compiled May 11 2016]
>  66945 COMMAND.COM 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]

> File sizes & versions freedos:

>   233 fdauto.bat
>   504 getargs.com reads memdisk command line
>   510 hdd.bat textinst / postinst installer caller??
>  1024 xmssize.com 2005, checks free XMS
>  1456 iniadd.com 2004, edits config
>  1530 oscheck.com 2004, checks boot sector type
>  2839 nlsfunc.exe 2004, version 0.4, /Y loads optional Y/N tables
>  2977 append.exe 2004, appends search path for data files
>  3657 DISPLAY.EXE 0.13b, loads custom fonts
>  3759 localize.com 2003, shows translateable messages
>  4149 choice.exe 2003, version 4.4, lets user make choices
>  5861 DOSKEY.COM obsolete, command.com has functionality built-in
>  6464 EGA.CPX from CPIDOS, with fonts 437, 850, 858, 852, 853, 857
> 11446 KEYB.EXE version 2.01
> 11681 sys.com version 3.6e
> 13077 KEYBRD4.SYS keyboard definitions
> 14395 VTUR.COM (your own software)
> 16254 MODE.COM old 2005 version
> 17049 USBKEYB.COM version 0.09
> 29722 KEYBRD2.SYS keyboard definitions
> 30189 EDIT.HLP compressed help texts
> 36640 KEYBRD3.SYS keyboard definitions
> 40332 KEYBOARD.SYS keyboard definitions
> 49264 srdisk.exe version 2.09 (Marko Kohtala's resizeable ramdisk)
> 64046 EDIT.EXE (text editor)

> File sizes & versions driver:

>  1577 eltorito.sys version 1.4
>  2423 shsucdhd.exe version 3.01
>  2535 xdma.sys old version 3.3
>  2882 srdxms.sys version 2.09 (see above)
>  3069 devload.com version 3.15
>  3745 xcdrom.sys version 2.3
>  4595 cdrcache.sys 2004 version
>  5612 shsucdx.com version 3.03a (SHCDX33A)
>  8058 himem.exe version 3.26, Aug 25 2006
> 15201 USBUHCI.OVL overlay for usbuhci
> 16799 emm386.exe version 2.26, Aug 25 2006
> 20776 USBUHCI.COM version 0.14, apparently 2010
> 30250 country.sys data file for nlsfunc country specific settings

> Maybe the others have additional comments on the used file versions!

> Regards, Eric



>
--
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.s

Re: [Freedos-user] Ynt: Y

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>


as usual.

urgent problem.
even 'Solver of this problem will be rewarded with 500$.'

a lot of more or less helpful messages exchanged.

then all of sudden the original poster vanishes, without any feedback
if all the given advice helped, or not, and how he solved his problem
(or not).

after wasting our time this is not nice behaviour.

Tom


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

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Ynt: Y

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

Hello Salih,

did you try to boot your image on real, but different hardware, like a
standard PC?

Tom


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

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Ynt: Y

[TOM EHLERT]

From: Tom Ehlert <t...@drivesnapshot.de>

> On physical machine any of keyboard layouts not work. In Virtualbox every
keyboard layout is working.
>
> We think real machine memory side has a problem with loading keyb.exe.

there is a tool called MEM.EXE where you can detect if KEYB is loaded
or not.

it may be as well that MEM gets loaded, but your BIOS or hardware does not
behave
as KEYB is expecting it.

to debug your problem:

reduce FDCONFIG.SYS to

  !SHELL=A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FREEDOS\FDAUTO.BAT

and FDAUTO.BAT to

DISPLAY con=(EGA,857,1)
mode con codepage prepare=((857) A:\FREEDOS\EGA.CPX)
mode con codepage select=857
NLSFUNC /Y A:\DRIVER\COUNTRY.SYS
KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179


or possibly even

  KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179

are you able to produce turkish characters?

if not, you are runnning interesting hardware.

no way to debug this over the internet, you have a real problem.


you may try if MKEYB behaves differently.

   MKEYB GR

should swap 'Y' and 'Z'.

Tom


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

--- Internet Rex 2.29
 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99)

---
 * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] bsum - compute BSD checksums of your files

[Tom Ehlert]

>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>> "jumps", MASM "option ljmp", etc).
right.

>> I won't argue about what opcode is or is not available on 8086, since I
>> did not bother decoding their exact meaning.

meaning 'I am a lazy, clueless guy, but write anyway ...'

>> I do see however that (NASM
>> at least) can assemble JZ and JZ SHORT in two very different forms, JZ
>> SHORT being significantly shorter.
>>
>>   5  B80100  mov ax, 1
>>   6 0003 48  dec ax
>>   7 0004 746Ajz short gameover
>>
>>   5  B80100  mov ax, 1
>>   6 0003 48  dec ax
>>   7 0004 7503E9DD01  jz gameover
>>
>> Of course NASM always uses the short form whenever it's possible, but
>> when the jump is too far away it silently uses the longer form, hence the
>> need to always specify SHORT if one wants to be sure what's going on.

> AFAIK,
meaning 'I am completely clueless , but offer my unfounded opinion anyway ...'

> the longer one is 386+ only, hence not available with "cpu
> 8086". Thus, if it still quietly assembles, that is a bug (but I
> thought that was long-ago fixed/avoided).

the longer one is 2 instructions instead, automatically generated by NASM
because the intended jump goes farther then 127 bte


c:\>debug
-e 100
1430:0100  00.75   00.03   00.e9   00.dd   00.01
-u 100
1430:0100 7503  JNZ 0105
1430:0102 E9DD01JMP 02E2


Tom



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EtherDFS - a network drive for DOS

[Tom Ehlert]

Mateusz,

really cool.

unfortunately I don't have a linux machine around, so testing must
wait.

may I suggest to use UDP/IP instead of raw packets?

UDP/IP requires just a few bytes set up in the right way, and the
calculation of the IP checksum; shouldn't be too much work.

this would be much easier to use in multi-everything environments like
linux or windows. specifically raw sockets are not available in
standard windows

many thanks anyway for starting this project

Tom

am 31. Januar 2017 um 10:19 schrieben Sie:

> Hi all,

> I write this short announcement to present an alpha version of a new 
> software I have been creating these past weeks. EtherDFS is an 
> "installable filesystem" for DOS. It installs a network drive that is 
> seen like any "normal" drive to DOS and its application, with the 
> exception that the actual data is located on a server. The server part is
> called EtherSRV and currently only a Linux version of it exists. EtherDFS
> uses raw ethernet frames to communicate with EtherSRV - this means only a
> working packet driver is required, nothing else.

> More information on the project's homepage:
> http://etherdfs.sourceforge.net

> I cannot stress enough the fact that this is an alpha version - it's in a
> very early stage, and lots is to be done yet. It does work however, and
> seems stable enough so it shouldn't make your PC explode. Its memory 
> footprint is quite huge for now, since its resident size is of 16 KiB.
> Future versions will surely improve on that. Also, it *should* work with
> MSDOS 5+, but I tested it only with FreeDOS so far.


> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedo

[Tom Ehlert]

Hello again,

> Do you want to load FreeDOS High, UMB?

there is no good reason (for normal use) to have ever

DOS=HIGH,UMB

disabled. if no HIGH or UMB memory is found, it is silently ignored.


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bug with FreeDOS 1.2 and "find"?

[Tom Ehlert]

>> 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 does A: show up in any of the environment
>> variables. Of course, that drive is empty.

> I can verify the problem in FreeDOS 1.2. It doesn’t happen in FreeDOS 1.1.
> Look at the screenshot:
> https://lazybrowndog.net/freedos/files/find-bug.png

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

Tom




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedos 1.2 LSM files without CR

[Tom Ehlert]

in the APPINFO directory, the LSM files are formatted UNIX style LF,
and not DOS style CR LF

btw: I'm no longer able to locate FreeDOS sources for FIND and it's
maintainer from freedos.org.


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedo

[Tom Ehlert]

Originally to: ALL


Hi,

to reproduce this FIND problem, I tried to setup a new FD1.2 machine.

what I did:

download FD12LGC.ISO

create a new virtual box machine with 512 MB disk
use FD12LGC.ISO to boot the machine.
boot machine.


'Unfortunately, this method of installation is not supported on this
hardware platform. Please try a different installation method.'

Welcome to the FreeDOS 1.2 operating system.



now what?
a hint to use the other .ISO would have been be helpful

eventually I figured this out, and setup was successful.


some remarks though:

the setup results in

FDCONFIG.SYS:

12:DOS=UMB

makes virtually never sense. DOS=HIGH,UMB is always the better
option.

what purpose is SHARE supposed to have?
SHARE is useful when the machine is running as a server, or with
windows (or any other multitasking OS).

don't install this.

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] after

[Tom Ehlert]

Originally to: ALL



I could reproduce this.

it happens in/after findnext()

this error is related to the compiler.

if the source is compiled using TurboC 2.01 the error occures.

compiling the exact same source with TCPP the error is gone.

try www.drivesnapshot.de/freedos/findtcpp.com and
www.drivesnapshot.de/freedos/findtc21.com

of course this can be a kernel bug, but as well a turbo library bug,
or some sort of interference between them.

Tom







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

[Tom Ehlert]

I could reproduce this.

it happens in/after findnext()

this error is related to the compiler.

if the source is compiled using TurboC 2.01 the error occures.

compiling the exact same source with TCPP the error is gone.

try www.drivesnapshot.de/freedos/findtcpp.com and
www.drivesnapshot.de/freedos/findtc21.com

of course this can be a kernel bug, but as well a turbo library bug,
or some sort of interference between them.

Tom







--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] freedos 1.2 install

[Tom Ehlert]

Hi,

to reproduce this FIND problem, I tried to setup a new FD1.2 machine.

what I did:

download FD12LGC.ISO

create a new virtual box machine with 512 MB disk
use FD12LGC.ISO to boot the machine.
boot machine.


'Unfortunately, this method of installation is not supported on this
hardware platform. Please try a different installation method.'

Welcome to the FreeDOS 1.2 operating system.



now what?
a hint to use the other .ISO would have been be helpful

eventually I figured this out, and setup was successful.


some remarks though:

the setup results in

FDCONFIG.SYS:

12:DOS=UMB

makes virtually never sense. DOS=HIGH,UMB is always the better
option.

what purpose is SHARE supposed to have?
SHARE is useful when the machine is running as a server, or with
windows (or any other multitasking OS).

don't install this.

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Ynt: Ynt: Ynt: Ynt: Ynt: Urgent FreeDos Keyboard Layout Hardware Help

[Tom Ehlert]

as usual.

urgent problem.
even 'Solver of this problem will be rewarded with 500$.'

a lot of more or less helpful messages exchanged.

then all of sudden the original poster vanishes, without any feedback
if all the given advice helped, or not, and how he solved his problem
(or not).

after wasting our time this is not nice behaviour.

Tom


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

Re: [Freedos-user] Ynt: Ynt: Ynt: Ynt: Urgent FreeDos Keyboard Layout Hardware Help

[Tom Ehlert]

Hello Salih,

did you try to boot your image on real, but different hardware, like a
standard PC?

Tom


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

Re: [Freedos-user] Ynt: Ynt: Ynt: Ynt: Urgent FreeDos Keyboard Layout Hardware Help

[Tom Ehlert]

> On physical machine any of keyboard layouts not work. In Virtualbox every 
> keyboard layout is working.
>  
> We think real machine memory side has a problem with loading keyb.exe.

there is a tool called MEM.EXE where you can detect if KEYB is loaded
or not.

it may be as well that MEM gets loaded, but your BIOS or hardware does not 
behave
as KEYB is expecting it.

to debug your problem:

reduce FDCONFIG.SYS to

  !SHELL=A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FREEDOS\FDAUTO.BAT

and FDAUTO.BAT to

DISPLAY con=(EGA,857,1)
mode con codepage prepare=((857) A:\FREEDOS\EGA.CPX)
mode con codepage select=857
NLSFUNC /Y A:\DRIVER\COUNTRY.SYS
KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179


or possibly even

  KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179

are you able to produce turkish characters?

if not, you are runnning interesting hardware.

no way to debug this over the internet, you have a real problem.


you may try if MKEYB behaves differently.

   MKEYB GR

should swap 'Y' and 'Z'.

Tom


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

Re: [Freedos-user] Ynt: Urgent FreeDos Keyboard Layout Hardware Help

[Tom Ehlert]

Dear Eric Auer,

could concentrate ONCE on the problem at hand, and not on all this
blablabla about file versions?


the problem seems to be that this freedos.img, booted in VirtualBox,
is able to generate funny characters (i without dot, C with hook, ...)
and not on real hardware.

now it would be cool if we had a screenshot (photo) of this iamge,
booted on real hardware.

btw: don't use EMM386 at all (for the moment), although I would not
expect problems.

now remove EVERYTHING not strictly necessary except keyboard.sys

last question: do you have the problem on the command line as well, or
only in VTUR?

Tom




am 10. September 2016 um 13:52 schrieben Sie:


> Hi Salih,

> thanks for sharing the 1.44 MB boot floppy image. It is correct that
> you cannot send files to the list, but the config & autoexec easily
> fits into a mail for the list by cut and paste:

>> !DEVICE=A:\DRIVER\HIMEM.EXE

> Supports options to manually select things but default should be okay.

>> !DEVICE=A:\DRIVER\EMM386.EXE FRAME=d800 X=TEST

> If you do not really need EMS 3 support, you should not force EMM386
> to provide a page frame. In particular, you should not force it to
> use a hardcoded location which may or may not work on a given system.

> You could for example try: X=TEST I=TEST NOEMS /VERBOSE

>> !COUNTRY=090,857,A:\DRIVER\COUNTRY.SYS
>> !SHELL=A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FREEDOS\FDAUTO.BAT

>> !DEVICEHIGH=A:\DRIVER\XDMA.SYS

> XDMA is rather old. If you do not need it, you can skip it.

>> !DEVICE=A:\DRIVER\SRDXMS.SYS

> You may want to specify the size of the desired ramdisk here?

>> !DOSDATA=UMB
>> !DOS=HIGH,UMB
>> !FILES=120
>> !BUFFERS=30
>> !LASTDRIVE=Z

>> @echo off
>> 
>> PATH=A:\;A:\FREEDOS;A:\DRIVER
>> 
>> DISPLAY con=(EGA,857,1)
>> mode con codepage prepare=((857) A:\FREEDOS\EGA.CPX)
>> mode con codepage select=857
>> NLSFUNC /Y A:\DRIVER\COUNTRY.SYS
>> KEYB.exe tr,857,A:\FREEDOS\keybrd2.sys /id:179

> Interesting that you specify a special variant of keyboard.
> As mentioned earlier, you may want to use /NOHI for KEYB.

>> VTUR

> Your software gets started at boot automatically.



> Finally, here is a full list of versions of used files. They
> seem to be a bit old in general, but it is quite possible that
> many files simply had no updates since then, as they already
> had reached the desired state.

> File sizes & versions root:

>315 fdconfig.sys
>  46685 KERNEL.SYS 2042 (build 2042 OEM:0xfd) [compiled May 11 2016]
>  66945 COMMAND.COM 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]

> File sizes & versions freedos:

>   233 fdauto.bat
>   504 getargs.com reads memdisk command line
>   510 hdd.bat textinst / postinst installer caller??
>  1024 xmssize.com 2005, checks free XMS
>  1456 iniadd.com 2004, edits config
>  1530 oscheck.com 2004, checks boot sector type
>  2839 nlsfunc.exe 2004, version 0.4, /Y loads optional Y/N tables
>  2977 append.exe 2004, appends search path for data files
>  3657 DISPLAY.EXE 0.13b, loads custom fonts
>  3759 localize.com 2003, shows translateable messages
>  4149 choice.exe 2003, version 4.4, lets user make choices
>  5861 DOSKEY.COM obsolete, command.com has functionality built-in
>  6464 EGA.CPX from CPIDOS, with fonts 437, 850, 858, 852, 853, 857
> 11446 KEYB.EXE version 2.01
> 11681 sys.com version 3.6e
> 13077 KEYBRD4.SYS keyboard definitions
> 14395 VTUR.COM (your own software)
> 16254 MODE.COM old 2005 version
> 17049 USBKEYB.COM version 0.09
> 29722 KEYBRD2.SYS keyboard definitions
> 30189 EDIT.HLP compressed help texts
> 36640 KEYBRD3.SYS keyboard definitions
> 40332 KEYBOARD.SYS keyboard definitions
> 49264 srdisk.exe version 2.09 (Marko Kohtala's resizeable ramdisk)
> 64046 EDIT.EXE (text editor)

> File sizes & versions driver:

>  1577 eltorito.sys version 1.4
>  2423 shsucdhd.exe version 3.01
>  2535 xdma.sys old version 3.3
>  2882 srdxms.sys version 2.09 (see above)
>  3069 devload.com version 3.15
>  3745 xcdrom.sys version 2.3
>  4595 cdrcache.sys 2004 version
>  5612 shsucdx.com version 3.03a (SHCDX33A)
>  8058 himem.exe version 3.26, Aug 25 2006
> 15201 USBUHCI.OVL overlay for usbuhci
> 16799 emm386.exe version 2.26, Aug 25 2006
> 20776 USBUHCI.COM version 0.14, apparently 2010
> 30250 country.sys data file for nlsfunc country specific settings

> Maybe the others have additional comments on the used file versions!

> Regards, Eric



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



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


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

Re: [Freedos-user] dma crosses 64k boundary error

[Tom Ehlert]

> I keep getting the error dma crosses 64k boundary when using tools
> like rawrite3 or hard drive manufacturers tools floppy creation
> software. I need to boot from Windows 98 bootdisk to get rid of it.

> Please let me know if there is a way to get rid of this problem under FreeDOS.

MSDOS redirects int 13 to an internal driver, detects DMA access crossing a 64k 
boundary,
and avoids it.

FreeDOS ddoes not do this; sorry.

there was no need to do this so far; IMO rawrite3 could/should handle
this by itself. of course, software is usually only tested against
MSDOS, so there is little motivation to do so for rawrite3
programmers.

I'm still surprised this comes up today, and not 15 years ago.
do you have remarkable hardware?

Tom


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

Re: [Freedos-user] How to use German keyboard layout with FreeDOS?

[Tom Ehlert]

Hallo Herr Kai Schaetzl,

am 18. August 2016 um 15:31 schrieben Sie:

> Tom Ehlert wrote on Mon, 15 Aug 2016 16:00:55 +0200:

>> an amazing amount of effort to get a german keyboard driver

> Not really once you know that you don't need the .kl file.
> According to
> http://help.fdos.org/de/hhstndrd/base/keyb.htm
> you have to run (as an example) "keyb GR,,GR GR.KL /E".
> You need the .kl file for this.
> However "keyb gr" suffices. Just that it's not mentioned anywhere. As I
> said I assume the GR layout is embedded in keyboard.sys, anyway.

> With that in mind, it's the same as with your driver: download and run
> "keyb gr". Anyway, just to see if there's a difference I changed now to
> mkeyb. Both keyboard drivers work.

> But I have the same problem with it. Adding "keyb gr" to autoexec.bat does
> not run it. It seems autoexec.bat isn't executed at all.

if something 'seems', add

   echo HELLO WORLD

to the front of your autoexec.bat


> Shouldn't it run
> automatically once DOS is loaded?

yes.
as our clairvoyant has left us, how about posting CONFIG.SYS?



> Thanks!

> Kai




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


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

Re: [Freedos-user] How to use German keyboard layout with FreeDOS?

[Tom Ehlert]

Kai,

an amazing amount of effort to get a german keyboard driver :<<


> Hi Eric,

> thanks for the quick reply. In the meantime I found out that I can load a
> German layout with just "keyb gr", just not the layout file itself or the
> /E switch that is mentioned in that article. I assume the gr.kl is 
> embedded in the keyboard.sys file. 
> That's good enough for me. I don't need the Euro sign. I use FreeDOS 
> mainly on a USB stick for flashing bios and controller cards on rack 
> machines and my own workstations. And it drives me crazy if I have to 
> input some special characters like - _ / which commonly occur. Each time I
> have to go by trial and error. And it seems you cannot type a ~ (tilde) at
> all on a German keyboard under an en-us layout. 
> Now I can :-)
> There is one thing still with keyb, though, that makes me wonder. 
> Shouldn't I be able to run it from autoexec.bat? I added "keyb gr" to it,
> but it isn't executed (or it doesn't work at this stage). I have to run it
> manually at the prompt. I'm also running keybw.com in autoexec.bat, right
> before that. I don't know what that does. I just have it in there and 
> don't know if I added it some time ago or if it came with the first 
> FreeDOS configuration. Should I remove it?

>> The KEYB layouts can be found here:
>> 
>> http://www.freedos.org/software/?prog=kpdos

> That's the point where the circle starts (and ends). There are no plain
> keyboard layout files (.kl) in there, only the .key files. But these need
> kc for compiling to a .kl file. And there's nowhere you can get kc from.

in that case, KPDOS does not qualify as open source, and I recommend to
remove KPDOS from future releases of FreeDOS


> I don't need it now anymore it seems. But still wondering if it's really
> not available from anywhere.

>> Viel Spass!

> Gleichfalls, von Berlin nach Berlin :-)

> Kai


instead I recommend

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/keyb/mkeyb/mkeyb041.zip

and a command line

  KEYB GR

(note: I'm the author)



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] upper memory trick

[Tom Ehlert]

> On 22/07/2016 10:34, Tom Ehlert wrote:
>>> (Honestly, FreeCOM needs to be better optimized for size and then we
>>> wouldn't have to worry at all. That is one of our weakest links.)
>>
>> seriously: command.com has ~3 K resident size. what are you
>> complaining about?

> This implies swapping capability, which not every PC has. FreeCom is 
> nearly unusable on my 8086 fitted with 256K of RAM,
you are absolutely right. FreeDOS without HIMEM is almost useless,
with only ~93 K memory remaining for this machine.

however note the topic of the post is 'upper memory trick', which
excludes 256 K RAM machines.


> unless recompiled
> with all possible compile-time options disabled.
use a CSWAP'ing command.com


> COMMAND.COM from MS is
> a much better performer in this (very specific) context.
amen.

Tom


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] a unique directory tree question?

[Tom Ehlert]

> I have a rather Unusual question about directory trees in dos.
> I have a zip compressed file that contains rather a large number of .txt
> files.
> the files  are of stories, and series, with the person who put the 
> materials together using  some major breakdown, for example an item might
> look like this.
> d:\stories\abandoned\series\the-end-of-time.txt
> Now when I ran pkunzip on the archive, the directory tree was created 
> correctly.
> By which I mean  there is a directory for abandoned, then a sub-directory
> for series, then the stories underneath.
> However in allot of cases the actual directory holding the .txt file is
> different.

Here would be a nice place to be more specific, and give an explicit
example.


> for the record, I am using word perfect to read the files.
shouldn't matter.
use the DIR command to show *real* filenames.


> My question is this.
> is there a limit to the number of branches so to speak, one can have in a
> dos directory tree?
no.

sounds like a bug in LFNDOS.

> Frankly I have never seen this problem before.  I do have lfn loaded, so do
> not think it is the names of the files, especially since some of the 
> content is present, and I got no error when I was unzipping the archive.
> Thoughts?
> Thanks,
> Karen


> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Games

[Tom Ehlert]

>> I'm building the new website. I'll update the notice to encourage new
>> users to install FreeDOS in a virtual machine.
>  
> any reason why we don't provide ready to run virtual machines as .VHD
> images?
>  
> Tom

> Hmm... I don't know why we haven't. I don't know anything about VHD
> though. Is that a standard virtual disk image that any PC
> emulator/virtual machine can read? Can free/open source software
> virtual machines read these (or create them)? 

.VHD is a fairly generic virtual *disk* format, and most virtual
machines providers should be able to read them.

a tiny bit more specialized are the virtual machine configuration
files, but we should be able to provide multiple formats, for Virtual
Box, DosBox, HyperV, ...

still no rocket science, and no risk to damage user data.

Tom


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Games

[Tom Ehlert]

> I'm building the new website. I'll update the notice to encourage new
> users to install FreeDOS in a virtual machine.

any reason why we don't provide ready to run virtual machines as .VHD
images?

Tom


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command / shell conflict

[Tom Ehlert]

Don,

in my opinion this is a SHELL bug.

after executing a program (being it command.com or dataperfect), shell
does some 'cleanup' code.

it simply thinks that all (MZ) memory blocks above SHELL.EXE are leftovers
from external execution, and calls DOSfree(). if they are leftover
PSPs, the potential environment at psp:[2c] is also freed.



now freedos command.com loads it's own environment as high as
possible; usually at around 9F9F:0.

when SHELL executes an external program, this environment gets freed,
and soon after trashed.


SHELL bug. case closed.

Tom









am 6. Juni 2016 um 12:42 schrieben Sie:

>>So "all my path variables are intact" means there is probably a memory
>>corruption issue somewhere??

>  Since this happens on every PC (7 total) that is unlikely; and 
> this does not happen with the regular DOSes. 

> I am now using a menu (PowerMenu by Brown Bag Software)  with the
> %WPSHELL%/C command and  our current FreeCOM which is working well. 

>>You mean "SET" within FDCONFIG.SYS??
>  
> I have a MENU selection in FDCONFIG.SYS pointing to an IF
> "%config%" option in AUTOEXEC.BAT which loads my PowerMenu which
> takes over from there, this is the "cleanest" way of resolving the issue that 
> I have found.

>>But yes, FreeCOM has various bugs and needs to be cleaned up and >fixed
 >>(eventually), but so far nobody has stepped up to do it.


> Yeah, we need to prioritize that for 2.0.

>  





> On Mon, Jun 6, 2016 at 4:31 AM, Rugxulo <rugx...@gmail.com> wrote:

> Hi,
>  
>  On Sat, Jun 4, 2016 at 4:34 AM, Don Flowers <donr...@gmail.com> wrote:
 >> UPDATE:
 >> So after three or four loads of shell.exe per session, the strings error 
 >> showed up again (Freecom 0.84)
>  
>  Even when using "/MSG /P"? So what is the implication, that there's a
>  memory leak in FreeCOM somewhere? I wouldn't be too surprised.
>  
 >> and Freecom 0.80 has some issues (2GB max shown on HD, OGN not recognized)
>  
>  Testing an old release for comparison? Why not test 0.82pl3 from SF.net?
>  
> 
> https://sourceforge.net/projects/freedos/files/FreeCOM/082pl3%20%28use%20xmsswap%20for%20386%2B%20PC%29/
>  
>  But yes, FreeCOM has various bugs and needs to be cleaned up and fixed
>  (eventually), but so far nobody has stepped up to do it.
>  
 >> I discovered one other alternative that seems to be working - I set a
 >> %config% variable (SET WPSHELL=C:\DP23\SHELL.EXE),
>  
>  You mean "SET" within FDCONFIG.SYS??
>  
 >> then %WPSHELL% /C;
 >> following that I execute a batch file with the same command and the shell
 >> loads as it should and on exit all my path variables are intact with no
 >> strings error messages.
>  
>  So "all my path variables are intact" means there is probably a memory
>  corruption issue somewhere??
>  
>  
 >> On Mon, May 23, 2016 at 5:21 PM, Rugxulo <rugx...@gmail.com> wrote:
 >>>
 >>> On Mon, May 23, 2016 at 4:18 PM, Don Flowers <donr...@gmail.com> wrote:
 >>> >
 >>> > So /MSG seems to work, more testing needed to be sure, What does this
 >>> > switch
 >>> > do, (besides help me of course)?
 >>>
 >>> http://help.fdos.org/en/hhstndrd/base/command.htm
 >>>
 >>> "/MSG        Stores all error messages in memory (requires /P as well)."
>  
> 
> --
>  What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>  patterns at an interface-level. Reveals which users, apps, and protocols are
>  consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>  J-Flow, sFlow and other flows. Make informed decisions using capacity
>  planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>  
> ___
>  Freedos-user mailing list
>  Freedos-user@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/freedos-user
>  




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command / shell conflict

[Tom Ehlert]

Don,

could you (or anybody else) prepare a virtual disk/floppy where
this bug can be reproduced?

If so, I'll give it a shot, as this seems to be the first
reproducable memory corruption bug in freecom.

Tom


am 6. Juni 2016 um 12:42 schrieben Sie:

>>So "all my path variables are intact" means there is probably a memory
>>corruption issue somewhere??

>  Since this happens on every PC (7 total) that is unlikely; and 
> this does not happen with the regular DOSes. 

> I am now using a menu (PowerMenu by Brown Bag Software)  with the
> %WPSHELL%/C command and  our current FreeCOM which is working well. 

>>You mean "SET" within FDCONFIG.SYS??
>  
> I have a MENU selection in FDCONFIG.SYS pointing to an IF
> "%config%" option in AUTOEXEC.BAT which loads my PowerMenu which
> takes over from there, this is the "cleanest" way of resolving the issue that 
> I have found.

>>But yes, FreeCOM has various bugs and needs to be cleaned up and >fixed
 >>(eventually), but so far nobody has stepped up to do it.


> Yeah, we need to prioritize that for 2.0.

>  





> On Mon, Jun 6, 2016 at 4:31 AM, Rugxulo <rugx...@gmail.com> wrote:

> Hi,
>  
>  On Sat, Jun 4, 2016 at 4:34 AM, Don Flowers <donr...@gmail.com> wrote:
 >> UPDATE:
 >> So after three or four loads of shell.exe per session, the strings error 
 >> showed up again (Freecom 0.84)
>  
>  Even when using "/MSG /P"? So what is the implication, that there's a
>  memory leak in FreeCOM somewhere? I wouldn't be too surprised.
>  
 >> and Freecom 0.80 has some issues (2GB max shown on HD, OGN not recognized)
>  
>  Testing an old release for comparison? Why not test 0.82pl3 from SF.net?
>  
> 
> https://sourceforge.net/projects/freedos/files/FreeCOM/082pl3%20%28use%20xmsswap%20for%20386%2B%20PC%29/
>  
>  But yes, FreeCOM has various bugs and needs to be cleaned up and fixed
>  (eventually), but so far nobody has stepped up to do it.
>  
 >> I discovered one other alternative that seems to be working - I set a
 >> %config% variable (SET WPSHELL=C:\DP23\SHELL.EXE),
>  
>  You mean "SET" within FDCONFIG.SYS??
>  
 >> then %WPSHELL% /C;
 >> following that I execute a batch file with the same command and the shell
 >> loads as it should and on exit all my path variables are intact with no
 >> strings error messages.
>  
>  So "all my path variables are intact" means there is probably a memory
>  corruption issue somewhere??
>  
>  
 >> On Mon, May 23, 2016 at 5:21 PM, Rugxulo <rugx...@gmail.com> wrote:
 >>>
 >>> On Mon, May 23, 2016 at 4:18 PM, Don Flowers <donr...@gmail.com> wrote:
 >>> >
 >>> > So /MSG seems to work, more testing needed to be sure, What does this
 >>> > switch
 >>> > do, (besides help me of course)?
 >>>
 >>> http://help.fdos.org/en/hhstndrd/base/command.htm
 >>>
 >>> "/MSG        Stores all error messages in memory (requires /P as well)."
>  
> 
> --
>  What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>  patterns at an interface-level. Reveals which users, apps, and protocols are
>  consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>  J-Flow, sFlow and other flows. Make informed decisions using capacity
>  planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>  
> ___
>  Freedos-user mailing list
>  Freedos-user@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/freedos-user
>  




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command / shell conflict

[Tom Ehlert]

Hallo Herr dosgeek57,

> I am a user of DataPerfect and the WordPerfect shell. The command is
> shell.exe. When I load by the shell I get a command.com strings error, my
> path is wiped out and I have to reboot. The shell is necessary to run
> macros, so not using it is not an option. I tried loadfix and that works the
> first time if Jemmex and jemm386 are not loaded, but hangs on the second
> try. Any suggestions are welcome.

start by posting (pointers to) the files necessary to reproduce your problem:

config.sys, autoexec.bat, shell.exe




> --
> View this message in context:
> http://freedos.10956.n7.nabble.com/command-shell-conflict-tp25034.html
> Sent from the FreeDOS - User mailing list archive at Nabble.com.

> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] JimDOS 1.0

[Tom Ehlert]

>> an operating system without CDROM and network drivers doesn't sound
>> very useful to me, even if everything has the correct license. YMMV.

> I think that the key is to perceive FreeDOS as a replacement to MSDOS,
> nothing else (that is, "BASE").

after 10+ years advertising that FreeDOS is better then MSDOS because
UDMA, LFN, ...

> The legalese on these things can be a
> bit confusing,
the distributor is obviously confused

> so I believe that the extreme caution that FreeDOS
> applies in this area is legitimate.

it is not.

LFNDOS is older then FreeDOS, and comes with a license
'open source. I don't care what you do wit it'

CRYNWR drivers are older then linux. same licensing.

UDMA is one of the drivers that actually made a huge difference on
older motherboards.

to stop delivering these packages suddenly after more then 10 years is
more about this open source religion (Stallmanitis) then anything
about legalese.



Tom


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.2 Package LSM Data Verification

[Tom Ehlert]

> CRYNWR - Unknown License, Dropped.

> GCDROM - Listed as GPL, No Sources, Based on XCDROM, Removed.

GCDROM sources are available.


> UIDE - Free for non-commercial, Removed.
> UMBPCI - Listed as free, No sources, Dropped.
> XCDROM - Removed.



an operating system without CDROM and network drivers doesn't sound
very useful to me, even if everything has the correct license. YMMV.

Tom


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] INTERLINK

[Tom Ehlert]

> The patched version of ITERLNK leads to problems if I still have a line
> version=3.31

version=3.31 is lying about location and size of a couple DOS
datastructures. don't do this, or expect trouble.

use /low or a new kernel to run interlnk.

tom


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] INTERLINK

[Tom Ehlert]

> Something else that should work if you don't want to modify it, add
> /low option which will also bypass the problematic code.
>  Tom's workaround will be in svn kernel soon, but I need to do some
> more testing as I'm still getting crashes, but haven't determined if
> its because of memory managers, virtual box, or another kernel issue
> with interlnk.  (It crashes later in booting, but only if I load
> interlnk, though it's fine if I add low to interlnk which seems odd
> as functionally should behave same with applied patch.)

I had only tested this with

  softice
  himem
  interlnk

what is your crashing configuration?




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] INTERLINK

[Tom Ehlert]

Bret,

> Eric/Tom:

> I used to use INTERxxx a lot many years ago using the special
> parallel cables designed for that purpose (I think I still have a
> couple of those cables in my "spare cable box").  Parallel is MUCH
> faster than serial (null modem) cables.
I also used it *A LOT*. in times when there were no network cards a
commodity. (the times they are a changing ...)

> I believe Eric is correct when he says INTERxxx is sector-based
> rather than file-based as Tom states.  I do know that the client
> (INTERLNK) must be capable of "understanding" the file system of the
> server (INTERSVR).  For example, if the client is MS-DOS 6.2 (which
> doesn't understand FAT32) and the server is MS-DOS 7.x (which does
> understand FAT32) and you're trying to access a FAT32 disk on the
> server, it doesn't work.  I know this for sure because I've tried
> it.  If INTERxxx was file-based, it wouldn't matter which version of
> FAT was on either computer (and could even work on non-FAT drives
> the server had mounted, like CD's and network drives).

you are right, my memory was plain wrong on this.

and - while debugging the crashing problem - I also saw that it
installs itself as handler for INT 25/26 'DOS DISK READ/WRITE'

Tom


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] INTERLINK

[Tom Ehlert]

>> Just want to know if FreeDOS can run interlink.exe and intersrv.exe
>> If FreeDOS is compatible with interlink, then what steps should follow?

interlink/intersrv are part of msdos. this should work in theorie,
but you are probably the first to test this on FreeDOS.


> As far as I remember, those provide sector based connection
wrong. it provides a file based service, and makes remote drives available
as drive letters.

> of FAT
> partitions through a serial or printer port cable: As long as your
> sector size is 512 bytes, that should probably work. Note that you
> only have those tools if you already own MS DOS anyway and that the
> tools only support FAT16 and maybe FAT12, but not FAT32.
interlink/intersrv doesn't care about fat12/16/32


Tom


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UltraDMA warning corrected

[Tom Ehlert]

> I am concerned by this statement from Jack's email: "Take a look at
> the sources for Microsoft HIMEM or EMM386, as I have…" This is the
> first I was aware that Jack had reviewed any source code from
> Microsoft.

Microsoft made the source for HIMEM.SYS available to programmers in
1988.

"February 7, 1989

Copyright (c) 1988, Microsoft Corporation, Lotus Development
Corporation, Intel Corporation, and AST Research, Inc. Refer to the 
document "eXtended Memory Specification (XMS), ver 2.0" for HIMEM.SYS
copyright and warranty information.
...
Some programmers may want to obtain the full XMS distribution disk,
which contains the source code to HIMEM.SYS, a C interface to the
XMM, a test of test programs, and documentation. In the domestic
United States, to obtain the latest official XMS release disk, call
Microsoft customer service at (800)426-9400 and ask for a copy of the
XMS Specification and it's supplemental diskette."

yes, it's copyrighted and shouldn't be copied. (btw: the source for
himem.asm has no copright mentioned).


but most low level programmers that were active in ~1990 (looong before
FreeDOS) had already looked at this (including me).
and I feel in no way tainted by this.

FreeDOS HIMEM.EXE is in no way influenced by my reading of HIMEM.ASM
in ~1990.

note: source for EMM386 was never published, but leaked to the public
in ~2003. Jack probably talks about this EMM386.


> When Microsoft released the source code to an earlier version of
> MS-DOS (March 2014)
source for MSDOS 1.1 and 2.0 is completely useless for FreeDOS
design and implementation. and has no HIMEM anyway.

BASE >> XMGR
> http://www.freedos.org/software/?prog=xmgr
> * providing XMSv3

> So we will now need to remove XMGR from the FreeDOS distribution.

I don't think so. I took a look at XMGR.ASM. XMGR.ASM is so obviously
coded by Jack (judging by coding style) that the claim of a copyright violation
would be ridiculous.

Tom




--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] picoTCP: a modern, open-source TCP/IP stack for DOS

[Tom Ehlert]

Hello Mateusz,


a) you forgot to publish the source for picotcpl.lib and
picodosl.lib


b) the only provided example program PING.EXE is HUGE (120K/63K when
compressed) when compared to mTCP ping.exe  (40K/28K compressed)

what exactly is the advantage of 'pico'TCP?


Tom

am 19. November 2015 um 20:00 schrieben Sie:

> Hello group,

> I write this message to share a little news about what I was doing in my
> spare time these last two months: porting picoTCP to DOS.

> picoTCP is a modern, dual-stack, open-source TCP/IP stack. It has been
> created by the good people at Intelligent Systems (Altran), primarily as
> a stack designed for embedded computing (hence hardware with very 
> limited horse power). It is backed by a well established corporation and
> it's actively maintained.

> I played with the stack for some times now, and ended up building an 
> entire DOS compatibility layer around it. A few patches were required to
> the stack, a few days of development, many hours of debugging - but here
> it is - the first public release of picoTCP for DOS!

> http://picotcp4dos.sourceforge.net

> The project contains three major parts:

> - ipcfg: a little tool that allows to configure networking on your DOS
> machine (IP, DNS, etc). No, it's not a text file - I wanted to avoid the
> complexity of parsing a text file, and opted for a binary configuration
> file that is manipulated via ipcfg. It's much more flexible that a text
> config file, while being much easier/faster to load at runtime.

> - ping: no need to explain, I guess... my ping tool for DOS, based on 
> picoTCP - crucial when it comes to testing your networking

> - an OpenWatcom library package (openwatcom, large memory model) - this
> is for the fellow developers that would like to use the DOS version of
> picoTCP inside their network-enabled, 16-bit DOS programs. I integrated
> a packet driver schim, a DOS-compatible timer, as well as the whole IP
> configuration logic, so it is now a simple (2 functions!) public API 
> that allows to load picoTCP, use it, and unload it.


> *** Short how-to ***

> 1. Download picotcp4dos and unzip it on your drive
> 2. Set the location where the config file will be stored, for example:
> SET PICOTCP=C:\PICOTCP.DAT
> 3. Bind picoTCP to the interrupt vector of your packet driver, example:
> ipcfg int 60
> 4. Configure your IP settings using ipcfg, or use DHCP (ipcfg dhcp)

> enjoy!

> Mateusz


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




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

Re: [Freedos-user] How to make the R-Alt key act like L-Alt?

[Tom Ehlert]

Hallo Herr John Hupp,

am 16. Juli 2015 um 01:48 schrieben Sie:

 For a US layout keyboard and the default BIOS keyboard driver: I brought
 this issue up a long time ago and learned that by design R-Alt is a dead
 key and does not duplicate the functionality of L-Alt.

 I have always found it to be awkward, slow and displeasing to invent 
 some other finger usage to do an Alt-File or Alt-X, which are very 
 common key combinations.

 Today I have been studying xkeyb and keyb, trying to find a way to get
 what I wanted, but I have come up dry so far.

 With xkeyb, recent versions now support an extended scancode for R-Alt
 (E56), but L-Alt is 56, and the [Shifts] section of its US.KEY supports
 association of only one scancode with ALT, and by default that scancode
 is 56.  By contrast, [Shifts] has a Shift1 and Shift2 association, 
 thereby enabling both L-Shift and R-Shift to be identified as Shift keys.

 With keyb, documentation notes that one might edit a KEY file and use KC
 with that to compile a custom keyboard layout (KL) file to load, and I
 am now trying to plow through the KC doc files, but it's pretty dense 
 reading.

 Can anyone detail or at least outline a solution?

outline, without *any* warranties:

L-ALT sends scancode 0x38
R-ALT sends scancode 0xe0 0x38

the keyboard handler should :

   if scancode 0x38 is detected, clear 'extended' status
   in BIOS


locate MKEYB to modify (castrate)


replace
   int cdecl NAME(cint15_handler)(uchar scancode)
   {
   ...
   }

with


int cdecl NAME(cint15_handler)(uchar scancode)
{

debug_scancode = scancode;  /* very nice for debugging   */
/* hit ESC - and we are gone */

if (scancode == 0x38)
   {
   *(char far*)MK_FP(0x40, 0x96) =  ~0x02;
   }

return scancode;
}

compile and test

good luck ;)


Tom


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Rugxulo IS A FRAUD!!!

[Tom Ehlert]

I recommend to ignore this thread.

Tom


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Doom unstable with LBACACHE or RDISK

[Tom Ehlert]

Hallo Herr Eric Auer,

am 27. Juni 2015 um 19:18 schrieben Sie:


 Hi Mateusz,

 After some investigations, I pin-pointed the problem to this:
 
 If I load any of these TSRs: LBACACHE, RDISK, then Doom either freezes 
 at start, or make the computer reboot.

 If I have to guess: RDISK, LBACACHE and DOOM may all cause
 the A20 to toggle
wrong. in normal circumstances A20 is always enabled.

A20 is disabled when programs are started, and is disabled with the
next INT21 interrupt (assuming the kernel is loaded high).

and no program has any reason to disable it ever again.



 as a side effect of doing protected mode
 stuff (even if it is only accessing XMS) and USB emulation
 of PS/2 and keyboard controllers, or injection of events
 to the actual controllers, in BIOSes may have bad stability
 as well. You could try other A20 methods or configure your
 EMS and/or XMS drivers differently, maybe even towards A20
 being locked to the modern state. Or you could try some
 other DOS extender than the one which is default for DOOM.

 The latter can also help if things are generally less stable
 due to issues with UMB, XMS 2 versus 3 or having large RAM
 amounts in the first place. For example DOS32A as a modern
 replacement of DOS4GW :-)

 Cheers, Eric

 PS: FreeCOM and kernel also affect A20 by using XMS swap
 and the high memory area (HMA).
wrong, too.

 You can try a non-XMS-swap
 version of FreeCOM and/or tell the kernel to use no HMA.

Tom


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors 
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Getting any CD player to work

[Tom Ehlert]

 On 6/8/2015 7:27 AM, Dale E Sterner wrote:
 For printers its usually easy to find the control commands but
 for cd units I've never seen them made available to the public.
 Is there a command list published anywhere for cds.

 Yes, it's called ATAPI and there exist a lot of different documents for
 the different classes of ATAPI devices. The only non-ATAPI CD-ROM drives
 that I am aware of are/were those of some early Creative 
 soundcard/CD-ROM drive combos. Those used their own subset of ATAPI 
 commands, hence a more standard CD-ROM driver won't work, as well had 
 their own digital audio connector that made those CD-ROM drives only 
 work with their bundled sound cards and vice versa...

 The catch with the documentation however is that this is stuff that you
 have to buy from t13.org, the committee that defined those standards...

googling 'ATAPI specification' turned up www.bswd.com/sff8020i.pdf at
position 2.

there are MANY other links containing the ATAPI spec.

even you old time DOS guys should start to use a search engine instead
of asking such (easy answered) questions on mailing lists.

Tom


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

Re: [Freedos-user] FreeDOS wishlist

[Tom Ehlert]

 My reason for wanting to use Windows 3.1 in  FreeDOS is for some
 very specific apps (yes among them are a couple of bible programs)
 and just having access to some utilities such as Winimage Winzip,
 etc. That said, since 1993 I have always had Compaq DOS/Windows 3.1
 on at least one of my PCs so, I can always fall back to that - just a bit 
 inconvenient.

whatever your reason is: forget it.

this would be a lot of work, and the developers find it more then
'a bit inconvenient' to put much effort in things that they aren't
interested in.

Tom




 On Mon, May 18, 2015 at 8:32 PM, Rugxulo rugx...@gmail.com wrote:

 Hi,
  
  On Mon, May 18, 2015 at 4:42 AM, Tom Ehlert t...@drivesnapshot.de wrote:
 
  Ability to run Windows 3.1 in 386 enhanced mode.
 
  has been discussed multiple times. conclusion: forget it
  
  Okay, but let's be clear here:
  
  1). It's proprietary, so it's not redistributable.
  2). It's old, so most people don't have (nor want) it.
  3). It used undocumented MS-specific data, so it's fairly hard to be 
 compatible.
  4). It's harder (maybe impossible) to run on even semi-modern machines
  due to its own bugs and design limits.
  
  However, that doesn't mean it's totally not worth supporting. In fact,
  I could be wrong (never cared much personally, thus never tested, I
  prefer real DOS, not Win16 GUI apps), but I think DOSBox claims to
  work with Win 3.x (or maybe even Win95). I know for a fact that DR-DOS
  7.03 fully works, but I'm not sure about OpenDOS or EDR-DOS.
  (Obviously those have different licenses, but I know it's not [always]
  totally illegal to reverse engineer or clean-room, esp. when dealing
  with explicit compatibility problems like this.)
  
  Regarding DOS apps themselves, the only real reason to use Win 3.1
  would be for something like multitasking (or maybe some obscure
  drivers??). In that case, it's probably easier to instead just use
  DOSEMU under Linux.
  
  So, summary: it's hard to support but not impossible, but the simple
  answer is to look elsewhere at pre-existing solutions (or similar).
  

 
 --
  One dashboard for servers and applications across Physical-Virtual-Cloud
  Widest out-of-the-box monitoring support with 50+ applications
  Performance metrics, stats and reports that give you Actionable Insights
  Deep dive visibility with transaction tracing using APM Insight.
  http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
  ___
  Freedos-user mailing list
  Freedos-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-user
  




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS wishlist

[Tom Ehlert]

 Ability to run Windows 3.1 in 386 enhanced mode.
has been discussed multiple times. conclusion: forget it

Tom


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

[Tom Ehlert]

 Now the new multi-TB hard drives have 4096-byte physical sectors,
 at least some of them try to act as if sector size were 512 bytes.

virtually ALL disks act as having 512 byte sectors, even if they have
internally 4096 byte ('advanced format').

search for '4K native' drives, and you will see that they are rare.

there's a good reason for this: only Windows 8 can boot from 4K
sectors, not Win7. and making hardware incompatible to 80% of all
existing computers is usually not such a smart idea.
see also 
http://www.heise.de/ct/ausgabe/2014-18-Test-Ungemach-durch-Festplatten-mit-4K-Sektoren-2283687.html

only recently 4kn drives became available
 Seagate Enterprise Capacity 3.5 HDD 4Kn 6TB, SATA 6Gb/s (ST6000NM0004)
 Toshiba MG04ACA500A



 So any modern OS needs to support at least 4096-byte sectors.
it certainly doesn't hurt, but this is not urgent

 There really needs to be GPT support with hard drives that would have 
 4096-byte sectors.
wrong. GPT is needed for drives with more then 4G sectors, which is
disk size 2TB for 512 sector size, and 16 TB for 4K sectorsize.

as a side note: a good portion of modern USB enclosures *simulates*
sectorsize 4K, so big disks ( 2 TB) can be handled without GPT
(read 'Windows XP')


 Next step up from 4096 bytes could be 8k, 16k ...
this will most likely never happen. the gain from moving 512 byte - 4K is
roughly 10% in disksize, and may be worth the trouble. the gain for going from 
4K
to 16K would be much less, and almost certainly not worth the trouble.

Tom


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Loading UIDE with devload

[Tom Ehlert]

 Is it safe to load UIDE in FDAUTO.BAT with DEVLOAD.COM, instead
 of loading it in FDCONFIG.SYS as recommended in the
 instructions?

yes, this is save.

Tom


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Shaw's Nightmare

[Tom Ehlert]

 I've released alphas and beta versions of the game.
 http://www.mediafire.com/download/36t9ql7z19x14i8/SN0_1.ZIP: tech demo.
 http://www.mediafire.com/download/ddem9tk51xdaidu/SN0_3.ZIP: alpha 0.3
 http://www.mediafire.com/download/u7hdsdtevhv4omt/SN0_6.ZIP: alpha 0.6
 http://www.mediafire.com/download/k88mk8zv58ztgs3/SNBETA.ZIP: Beta 0.91

this is NOT a mailing list of your subscribers

releasing ALPHA whatever to a public mailing list is considered spam

Do not contact us about this. If you do you will be Fusion Cannoned. :)

:

Tom



--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Quickview ver 2.60

[Tom Ehlert]

 DOS might have problems with SATA drive. DOS reads from the harddrive a
 lot.
 Since SATA is serial (just one bit at a time) The data ransfer rate might
 be too slow for DOS to live with. I know I can't get it to run on a SD card
 because one bit at a time is just too slow.


back in the good old times, when DOS was popular, PATA disk drives used PIO
for transfer, which is limited to (less then) 8 MB/sec.

currently, SATA hard disks transfer up to 120 MB/sec and SATA SSDs
transfer ~500 MB/sec.

this should be fast enough even for DOS.

 You won't know until you try it.
I don't have the faintest idea what you are doing wrong, but you are doing
it the wrong anyway.

Tom



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Com1: corruption from PS2 mouse

[Tom Ehlert]

 The serial port is opened in FreeBasic with :
 Open Com COM1:38400,n,8,1,cs0,ds0,cd0,rs For Random As #CP

FreeBasic doesn't support FIFO, and most likely no IRQ.
try

 Open Com COM1:600,n,8,1,cs0,ds0,cd0,rs For Random As #CP

and see if that changes your problem.

Tom


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Com1: corruption from PS2 mouse

[Tom Ehlert]

 FreeBasic doesn't support FIFO, and most likely no IRQ.

 try

  Open Com COM1:600,n,8,1,cs0,ds0,cd0,rs For Random As #CP

 and see if that changes your problem.

sorry, not true.
FreeBasic seems to use IRQ, but not FIFO.

anyway, try
  Open Com COM1:600,n,8,1,cs0,ds0,cd0,rs For Random As #CP

Tom







--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Com1: corruption from PS2 mouse

[Tom Ehlert]

 More detail:
 The rs232 port Com1: is connected via a Null modem cable to an Adam 232 to
 485 converter.
 In the Bios I have Com2 to 3 disabled.

 An IRQ clash is possible if Cutemouse uses IRQ4 from Com1. 
 My next step is to try different mouse drivers, unless I get more
 suggestions.

there can't be an interrupt conflict: in DOS, there is no interrupt
chaining. if the interrupts would be in conflict, you would not
receive any characters at all.

 In fact it even corrupts without movement as a result of being polled.
you didn't specify: what is 'corrupt' ?

a) characters as received on the other end?
b) input messed?
c) input characters dopped?

if c): are you using the FIFO? do you see the overrun error bit set?
   (most likely caused by the USB BIOS which disables interrupts
   longer then your baudrate allows. use the FIFO!)

Tom


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] current information on networking with a laptop?

[Tom Ehlert]

Hallo Herr Thomas Mueller,

am 6. Oktober 2014 um 08:21 schrieben Sie:

 from Eric Auer:

 As you mention in another mail that this is about wireless network:
 I am not aware of any new drivers for DOS for wireless network USB
 sticks, extension cards or similar. However, you could connect your
 laptop with a short network cable to a small wireless hub or similar.

 Then you have to carry around the hub, but at least you do not have
 to have a long network cable from your laptop to your fixed network.
 DOS drivers for networking via network cable are much easier to find.

 Regards, Eric

 Wired Ethernet came long before wireless network, when DOS was much more in 
 use than now.

 But what about the newer Etherrnet chips for which there is no packet driver?

 Motherboard is likely to support PXE, might that offer a way to
 boot FreeDOS with networking capability on a modern Ethernet chip?

If, and only if your computer has been booted using PXE
then you can access the network using the universal NDIS driver
UNDI.DOS and DIS_PKT.DOS for the packet interface


 Tom
Tom



--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] VirtualBox and FTP

[Tom Ehlert]

Hi,

 I don't want to brag too much, but M2WAT shows the absolute brilliance
 of separating the DHCP process from the programs.  ;-0 The mTCP programs
 do not know or care about DHCP; they behave the same whether they have a
 static IP address or a DHCP obtained one.  M2WAT helps the WATTCP 
 programs behave the same way; they can run as though they are on a fixed
 address and only M2WAT knows the difference.

any good reason mTCP and DHCP can't update/use WATTCP.directly ?

imho there should be a *single* network configuration file, used by
*all* network stuff on the machine.

changing mTCP to understand WATTCP.CFG is trivial. (WATTCP.CFG has
been around for ages, and mTCP is under active development, so mTCP
should learn to understand WATTCP.CFG)

 For FreeDOS the installer can place M2WAT wherever it makes the most sense.

there is no good reason to add, document, or even discuss another
program (even if it is open source) with little reason to exist in the
first place

Tom


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] VirtualBox and FTP

[Tom Ehlert]

 We use undipd driver:

 http://www.shikadi.net/network/files/undi2pd/undipd.com

this is great - if and only if booted from PXE.

Tom

 It is widely tested on the newest hardware: notebooks, desktops and servers.


 28.08.2014, 23:14, Rugxulo rugx...@gmail.com:
 Hi,

 On Mon, Aug 25, 2014 at 10:59 PM, Mateusz Viste mate...@viste.fr wrote:
  Might be that the DHCP implementation of VirtualBox is incompatible with
  the DHCP client embedded in Watt32... A PCAP capture might show more,
  although not sure if there is any point, since watt32 probably won't be
  updated/fixed any time soon.

 I'm not really in the loop, but I don't think this is quite true. It's
 not nearly as dire as it seems, though I admit that DOS overall is
 always low on volunteers.

 Here's the new webpage for Watt-32:

 http://www.watt-32.net/

 The latest DJGPP (binary) build of it is here (otherwise you also have
 to manually rebuild something for correct error numbers with 2.04, I
 forget):

 http://na.mirror.garr.it/mirrors/djgpp/beta/v2tk/wat3222br3.zip

 And there were some posts (on news://comp.os.msdos.djgpp) a few months
 ago from the author saying he still supports it. Of course, most of
 his focus these days is Windows (MinGW, etc). But you could probably
 email him directly if really desperate.

 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user




Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG ?

[Tom Ehlert]

 This is not really about FDNPKG, but more about how packages are
 structured. Indeed, I tend to avoid putting to much stuff into 
 %FREEDOS%\BIN, and only put there stuff that is supposed to be part of 
 the FreeDOS core (ie BASE, that is similar functionality than what 
 MSDOS was providing).

 Yes I think this a good idea. About the PATH: What about creating
 an external batchfile like C:\PKGS.BAT, that is automatically called
 by AUTOEXEC.BAT? FDNPKG could update the PATH statement according to
 each package. The content, for example:

 PATH=%PATH%;C:\FDOS\DRIVERS\CRYNWR
 PATH=%PATH%;C:\FDOS\PROGS\DOSZIP

 and so on.

PATH is limited to 256 characters.
I see problems at the horizon when installing 76 packages.

for this reason, drivers that are used exclusively in AUTOEXEC and
CONFIG should never go into environment and other stuff
that is often used (ZIP,...) should go into a *single* BIN so that
there remains some space in PATH


 As you see above, I would put DOSZIP in PROGS instead of C:\.
 What's the use of these categories, if we do not use them?
what's the point of these categories anyway ?




 Now the question is where to put any 3rd party apps that are still 
 supposed to be callable from anywhere in the directories tree? One 
 option could be to create another BIN-like directory for these
exactly.

 No, I think creating another BIN directory like /usr/bin in
 GNU/Linux, where we'd put all third-party executables, would
 complicate things. The next step would be to put configuration files
 in /ETC. No I think it would be wise, to stay with the DOS way and
 keep each program and its configuration files in one dedicated directory.
this was *never* the DOS way.


Tom


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

Re: [Freedos-user] FDNPKG: where to put 'system-wide' applications

[Tom Ehlert]

 'Which means Accept what the package manager does by default.  I
 mostly concur, but an advanced user might have reasons for wanting
 things elsewhere.  It's nice it the package manager gives them an
 option to do so and specify where, but if it needs AUTOEXEC.BAT
 modified for things to work as expected, that's the user's job.

 I bet many people here know that an easy way to cheat %PATH% with the
 FreeDOS COMMAND.COM is to use an alias [0].  Teaching FDNPKG that
 might be useful.

unfortunately this works only for FreeCOM. this doesn't help users
of XYZ Commander, 4DOS, ...

a better way to achieve the same effect would be a directory on the
PATH with batches that redirect to the proper location.

ZIP.BAT
   shift
   c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9


otoh I don't see that ZIP should get it's own directory.


Tom


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

Re: [Freedos-user] FDNPKG: where to put 'system-wide' applications

[Tom Ehlert]

Hi Mateusz,


 On 08/15/2014 12:29 PM, Tom Ehlert wrote:
 a better way to achieve the same effect would be a directory on the
 PATH with batches that redirect to the proper location.

 ZIP.BAT
 shift
 c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9

 Exactly what I was saying, yes.
exactly. I saw your letter too late;)

 For now, that's my favorite solution
 (unless anyone comes up with a better one that I missed). I'm not sure
 why the 'shift' thing would be needed, though?
my fault.

it should have been

  c:\USR\BIN\ZIP %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
 ^^
and you can pass an additional parameter for

   ZIP dest.zip -r -1 -q -x *.tmp -x *.obj -x *.lst

and you see the limit of this approach. maybe

 shift
 set ARG1= %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 set ARG2= %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 shift
 c:\USR\BIN\ZIP %arg1% %arg2% %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
 set arg1=
 set arg2=


 otoh I don't see that ZIP should get it's own directory.

 well, one could imagine putting the entire info-zip stuff into a 
 dedicated directory,

in good old DOS times, programs (utilities) were single executables. no need to
install, package, create separate directories, ...
most likely info-zip is not an DOS program ;)

 along with any possible documentation, etc.
noone will read documentation anyway


Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


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

Re: [Freedos-user] legacy ATA support

[Tom Ehlert]

 So, even though I can't access the hard drive in Freecdos,
you can access the harddrive from FreeDOS
 the firmware update should work?
I don't have the faintest idea if the firmware update will work, but
YES





 On Thursday, July 17, 2014 7:57 PM, tomehlert t...@tomehlert.de wrote:

 As I mentioned earlier, Freedos requires a ATA legacy mode in BIOS, which I 
 don't have.
 wrong.

 Found this in the archives
 http://sourceforge.net/p/freedos/mailman/message/26625851/

  UIDE/UIDEJR can run AHCI drives on mainboards that have a legacy or 
 native IDE
  setting for AHCI controllers, i.e. the drives can be addressed
 using standard SATA/IDE I-O logic.

 right.  UIDE doesn't work on AHCI controllers - and isn´t required for
 FreeDOS.
 FreeDOS is perfectly happy without UIDE.
 (UIDE might even get in the way of updating your HD firmware.)

 AS SAID BEFORE
 search for RUFUS (RUFUS_v1.2)
 install to USB key

 add your WD files
 boot from USB key


 your  'update  HD  Firmware'  Software should take care about anything
 else (even only to tell you 'this software requires windows')

 Tom






  On Thursday, July 17, 2014 1:01 PM, Bill Haught wlhaughtpr...@att.net 
wrote:
  


 Mine is a Western Digital WD10EALX. 
  The file R313263.exe extracts
 to C:\dell\drivers\R313263.  The readme.txt in the directory is as follows:


 THE INFORMATION, FIRMWARE AND  TOOLS, AND ALL ASSOCIATED UPDATES
 AND MODIFICATIONS (THE “INFORMATION”), CONTAINED HEREIN IS PROVIDED
 ON AN “AS-IS” BASIS AND WD ASSUMES NO LIABILITY WHATSOEVER WITH
 RESPECT TO SUCH INFORMATION UNDER ANY CONTRACT, NEGLIGENCE, STRICT
 LIABILITY OR OTHER LEGAL OR EQUITABLE THEORY, EVEN IF WD HAS BEEN
 ADVISED ON THE POSSIBILITY OF SUCH DAMAGES.  
  
 WD EXPRESSLY DISCLAIMS ALL EXPRESS AND IMPLIED WARRANTIES IN
 CONNECTION WITH THE INFORMATION CONTAINED HEREIN, INCLUDING
 WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
  AND
 INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.





 Installation  

 1. Extract .zip file to a known path
 2. Copy WD.bat and WD4082.exe to root directory of a bootable USB key.
 3. Boot from USB key and ensure drive path includes WD.bat and WD4082.exe.
 4. Type WD and hit Enter.
 5. Firmware update will provide messaging indicating successful update.

 Note: Update checks current firmware version and will not run on identical 
 version.



 --
 Want fast and easy access to all
  the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on  Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds

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


  



 Mit freundlichen Grüßen/Kind regards
 Tom Ehlert
 +49-241-79886









Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] legacy ATA support

[Tom Ehlert]

 The readme says bootable USB key  I assume they mean a DOS one.
 Especially due to licensing issues making one that boots Windows is a *REAL* 
 project.l

search for RUFUS (RUFUS_v1.2)
install to USB key

add your WD files
boot from USB key

Tom





  On Thursday, July 17, 2014 1:01 PM, Bill Haught wlhaughtpr...@att.net 
 wrote:
   


 Mine is a Western Digital WD10EALX.  The file R313263.exe extracts
 to C:\dell\drivers\R313263.  The readme.txt in the directory is as follows:


 THE INFORMATION, FIRMWARE AND  TOOLS, AND ALL ASSOCIATED UPDATES
 AND MODIFICATIONS (THE “INFORMATION”), CONTAINED HEREIN IS PROVIDED
 ON AN “AS-IS” BASIS AND WD ASSUMES NO LIABILITY WHATSOEVER WITH
 RESPECT TO SUCH INFORMATION UNDER ANY CONTRACT, NEGLIGENCE, STRICT
 LIABILITY OR OTHER LEGAL OR EQUITABLE THEORY, EVEN IF WD HAS BEEN
 ADVISED ON THE POSSIBILITY OF SUCH DAMAGES.  
  
 WD EXPRESSLY DISCLAIMS ALL EXPRESS AND IMPLIED WARRANTIES IN
 CONNECTION WITH THE INFORMATION CONTAINED HEREIN, INCLUDING
 WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.





 Installation  

 1. Extract .zip file to a known path
 2. Copy WD.bat and WD4082.exe to root directory of a bootable USB key.
 3. Boot from USB key and ensure drive path includes WD.bat and WD4082.exe.
 4. Type WD and hit Enter.
 5. Firmware update will provide messaging indicating successful update.

 Note: Update checks current firmware version and will not run on identical 
 version.



 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on  Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds

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


   



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMODE - translation from Pascal to C - solved

[Tom Ehlert]

Hallo Herr Zbigniew,

am 29. Juni 2014 um 02:35 schrieben Sie:

 2014-06-29 1:13 GMT+02:00, Rugxulo rugx...@gmail.com:

 Turbo Pascal has a smartlinker while Turbo C does not.
Turbo C linker is about as smart as Turbo Pascal.

 Indeed I noticed even earlier, that OBJ is of decent size (just a
 little more than 4 KB), and it must be a linker, which glues some
 additional library to final EXE. Most probably because I had to
 include dos.h (int86 function in use).

Most probably because you use printf().

Just compile the infamous

   main() {
  printf( hello world\n);
   }

and look at the map and .exe size. You'll see that this is fairly large.
reason:

printf() has a lot of non-trivial formatting options (including
%d, %5d, %*d, %5.5d,%-5d, %-05d, ..., float, ), and is fairly large
even if implemented efficiently.

in addition printf() writes to *stream* stdout, and usually pulls in
malloc() and friends, fwrite() and friends, and possibly even some
more stuff.

that's the reason why MORE, CHOICE, and some more FreeDOS programs use
PRF.C and TALLOC.C for a much smaller footprint compared to using
standard printf()

Tom


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMODE - translation from Pascal to C - solved

[Tom Ehlert]

 Most probably because you use printf().

 It seems, not too much I can do about this using Turbo C:

 1. Compilation of Hello, world! containing printf gave around 370
 bytes for OBJ, and 8.3k for EXE.
 2. The same when replaced printf with puts gave 6.4k for EXE.

puts() is essentially

puts (char *s)
{
   fwrite(s, strlen(s), 1, stdout);
}

so this still uses the stream IO functions, including malloc().
start by generating (and reading and understanding) the map file.



 Yes, the difference is noticeable - still it's not as big, as one could 
 expect.

 Probably Watcom compiler is able to produce smaller binary, but I
 didn't try it yet.

 Who knows, maybe for Turbo C the best solution for this would be to
 code one's own simplified puts directly in assembly.

there is zero need for assembly here; for beginners:

my_puts (char *s)
{
   write(1, s, strlen(s));
}

will make your exe significant smaller. look at the source of MORE or CHOICE for
some more tricks.

Tom


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Keyboard issue

[Tom Ehlert]

Hi,

you might have stated your keyboard driver first ...

but as you later state that the problem occurs with MKEYB as well,
here's my educated guess what happens:

the UP, DOWN, LEFT, RIGHT keys in the cursor block are similar to the
UP, DOWN, LEFT, RIGHT in the numeric key pad as they send similar
scancodes, but send an additional 'E0' scancode

now it seems this additional scancode is lost, and instead of
   'cursor block UP'  E0 48
only
   'numeric key pad UP'  48
is received (and processed).

since this has not been reported by anybody else so far, and only
if your machines are slow, and only sometimes:

something in your machines blocks interrupts for too long, and keys
get lost - most likely some TSR or driver, ...

please try running ONLY  HIMEM and MKEYB (or the other keyboard
driver), and see if the problem vanishes.

add more software until the problem reappears

Tom



am 9. Mai 2014 um 00:19 schrieben Sie:

 Hi,

 A couple of years ago I noticed that, in some computers, when
 the Up, Down, Left or Right keys were held pressed for several
 seconds, sometimes they acted as numeric keypad keys, i.e.,
 instead of just moving the cursor in these directions, they
 actually *wrote* the characters 8, 2, 4 or 6 respectively.

 These are *not* the numeric keypad keys, but the four-key
 cluster between the alpha and the numeric keypads.

 Let me state the whole thing once more, to avoid
 misunderstanding.

 The keys involved are not the numeric keypad keys. However,
 the effect is *as if* we were using the numeric keypad arrow
 keys with the NumLock feature off, and these keys, when held
 pressed, would act most of the time as per NumLock off (move
 the cursor), but sometimes -- say, one in 30 iterations --
 would act as if NumLock was on (write digits 2, 4, 6, 8).

 This is of course serious, as you may inadvertently write a
 digit in your text when you merely wanted to move the cursor.

 This usually happened in old computers (early Pentiums) donated
 for use in my Health Center volunteer work. At the time I
 thought it was some hardware fault because the machines were old
 and presumably worn out.

 Actually I used this as a test to evaluate if the machines were
 reliable. I saw this happen in several computers, and still have
 one of those. All tests were done with pure FreeDOS.

 One trick that apparently eliminates the problem completely is
 keeping NumLock off. (This may sound odd, because NumLock is
 supposed to change the behaviour of the numeric keypad keys,
 whereas we are talking about the other arrow keys here.)

 Because this is a keyboard issue, I (rather vaguely) remember
 trying MKEYB.EXE by Tom Ehlert instead of the standard FreeDOS
 KEYB.EXE, but the problem remained.

 Today, however, for the first time, the same problem happened
 with my own computer -- a machine I have been using intensively
 for over a year, and which so far has been completely reliable.
 An old text editor was running which requires reducing processor
 speed because of the Borland runtime 200 bug. I use Eric's FDAPM
 to reduce the speed. The problem was exactly the same as
 described above, and it also disappeared when the NumLock
 feature is off. It also disappeared when the processor was
 returned to its full speed (1 GHz).

 So perhaps it is not a hardware fault of old computers, but some
 other issue. As I never had this happen with MS-DOS which I used
 from 1995 to 2007, I thought it might be a FreeDOS issue.

 On a side note, when I started running the Health Center
 database in a network 2 years ago, with all machines running
 FreeDOS, a problem arose which *also* involved keeping the Up,
 Down, Left or Right keys pressed for a few seconds in the client
 machines. The effect was that the whole network crashed.

 I mention the network problem just because it was also triggered
 by keeping the same keys pressed. I discussed the issue in our
 list, and several people responded. The solution was to run
 MS-DOS in the server. Clients continued to run FreeDOS, and the
 problem never came up again. It seemed that the problem was
 related to running FreeDOS in a network.

 In today's issue, there is no network involved. This is a
 standalone machine I use at home as my main computer, and it has
 been very reliable so far. I also run Puppy Linux and Seamonkey
 or Nightly in it to browse the web. So apparently it is not a
 hardware problem.

 Has anyone experienced anything like that? Any idea what it
 might be?

 Regards,

 Marcos



 --
 Marcos Fávero Florence de Barros
 Campinas, Brazil



 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce

Re: [Freedos-user] Keyboard issue

[Tom Ehlert]

 You can download my SCANTEST program
good idea;
   MKEYB BR /T
does something similar


 (it's included with the USB  drivers)
that gives us the idea to ask:
is this a PS/2 or USB keyboard ?

 Just as another troubleshooting item, does it happen even when you
 don't have a special keyboard driver loaded (like MKEYB)?  That is,
 does it happen with just the default (BIOS) keyboard driver?

in fact, when running MKEYB, your system should behave (for these
keys) almost exactly like 'no driver loaded', as MKEYB looks at these
keys, and decides *very quickly* that it is not interested in handling
these keys and passes control back to the BIOS.

so I would guess that when this effect happens with MKEYB, it will
happen with the default BIOS keyboard as well.


Tom


--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] defrag program issue

[Tom Ehlert]

 When I run the defrag program on my dos machine, It does not allow me to
 do a full defrag.  The options are limited (grayed out).
 On that machine, I am running freedos and for a command processor, 
 4dos.  FAT32 was created by a windows o/s before I bought it.  I have 
 since removed window (xp?).

the defrag program doesn't work on FAT32.

Tom


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] recovering a file? (fwd)

[Tom Ehlert]

Dear Mr. Lewellen,


 Well let me state publicly again that private communications are unwelcome
 unless I have granted you permission.  Told you that before, then simply
 kept ignoring your private efforts...feel sure you will not make that 
 mistake again.

you are wasting our valuable time. please go away to
www.wpuniverse.com, survpc list, or wherever you feel comfortable.
but go.

Tom




 I have just posted  a comparative  question at the wp for dos forum at
 wordperfect universe.
 www.wpuniverse.com
 Where I am a member.
 Equally working the discussion through the  survpc list where I have been
 a member for decades.
 Unless someone knows the answer to my spinwrite question, those lists may
 be more helpful than here.  Others  using Norton  utilities v 8.0 not 
 withstanding of course.



 On Sun, 10 Nov 2013, Eric Auer wrote:


 Hi Karen,

 Why are you writing me privately for a list discussion?

 Because I had asked several times without getting an
 answer, so I assumed you might want to keep those
 details off-list.

 Not sure why these would be plain text either,  they are wordperfect 6.0,
 actually, or why it impacts my use of Norton utilities 8.0 edition of 
 unerase.

 Wordperfect files according to the file tool start
 with the byte sequence ff 57 50 53 c4 05, in other
 words the byte ff, then the text WPC, then the two
 bytes c4 05. This information can help you to find
 the start of a deleted wordperfect file even when
 undelete cannot find the deleted directory entry of
 the file any more: Disk editors typically have some
 function to search the raw disk for contents. Also,
 you know that the sequence must be at the start of
 a cluster to be a match. Note that this is about
 current WordPerfect versions: You have to check on
 your own computer if files made by your version do
 start the same. According to some notes from 2001,
 the textual part of WordPerfect files is visible if
 you look at the file with a text editor, mixed with
 binary markup data. In other words, you should be
 able to recognize whether a certain cluster can be
 part of your to-be-recovered file. Of course all of
 this is quite tedious, so you typically try how far
 you can get with automated tools first...

 let's focus on what I am asking, since  we may get to the goal this way.
 plain text lol.

 Sure. Keep us updated about your progress. If you
 can avoid writing to your disk for a while, the
 best way is to work slowly and carefully, maybe
 waiting until you are in position to get a disk
 image. Once you have a disk image stored in some
 foolproof way, you can start working on the real
 disk again. Because then you can work on recovery
 of the two files at any later moment, using that
 image file and no longer have to worry about work
 with the real disk causing further damage.

 Regards, Eric



 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] cmcp compress copy utility

[Tom Ehlert]

 i made a dos version of this, version 1.0.3.2 , i still have to
 test it out but it getting late linux version seems work okay though.
 it used rle encoder to compress the file and is only effective on
 data that repeats alot, it is in the git repository

Features 'Rle compression'. wow.

doesn't sound useful.

Tom


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] (no subject)

[Tom Ehlert]

Hi Mateusz,

 is there a place you can download all of freedos in one big piece,
 but including all the up-to-date everything?

 As Bojan already pointed out, such place already exists. It's here:

  
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/

this would be seriously absolutely mega fantastic. a single place where all 
this junk
is not only collected, but even sorted. what a modern concept.


unfortunately there is
  no *direct* pointer from freedos.org to this place
  some 50% contain no source (GPL violation)
 (before you ask, I checked only kernel, more, deltree, edlin,
 comp)
  it's not updated :(


 it would surely be convenient.
I agree with that.

Tom


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] 7zip in pure dos?

[Tom Ehlert]

 The problem with tar.whatever files is you must first uncompress the
 tar file, then extract what you want (and possibly then remove the
 uncompressed tar file.) 

 Not really. If you use tar for decompression (and not 7za) it will
 automatically pipe the output of tar to appropriate decompression
 program.
when compressing, *nobody* compresses first, then tar

the very idea of 7zip is to tar first (internally), then compress.


 DJGPP ports of GNU tar should have this option too, but I
 think this will work much better under native Linux (actually any
 modern Unix with a recent version of GNU or BSD tar).

this is a DOS mailing list. piping works different in DOS.


 Just type 'tar -xf archive.tar.xz' and you're ok. Of course, you will
 need to have gzip, bzip2 or xz installed (Should be installed by
 default in puppy. DOS ports are available from DJGGP file repository).

 Bojan.

Tom


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 I may sound harsh, but being accused of ignorance by
 more ignorant is the only word of excuse I will utter.
  
 this 'more' makes me think that you should prove your competence
 first
  
 I agree. The above quoted phrase was a late minute, unfortunate 
 addition to my mail, that was meant jokingly - but now on reading it 
 again I can see it does not reflect my true purpose, which has been to
 put an end to respective sarcasm and ire. Sincerely ! That more
 was meant to be no less, as in, ok, we're all ignorants, let's
 live with the fact and do our best to learn from one another. Oh, well...

 I retire the phrase and beg your pardon. Then again :
 Let's forget /name calling/ ? If you agree, I'm your man

apologies accepted.



 Concerning the subject - locating the main env immediately above
 the small 3 K ? block of FreeCom's PSP,
  I honestly cannot discern
 whether you are seriously in want of explanations or only asking
 in jest. It is not complicated, at least from an ASM programmer's
 perspective where you can organise your modules at will.

 Or were you questioning the feasibility from the perspective of 
 or a complex modular 'C' language program ? 
 Then the detailed how is beyond my limited competence,
  I /suppose/ it might be harder, possibly requiring compiler-dependent
 variations and /some/ amount of 'glue' coded in ASM.

the bizarre design decision by a confused programmer was made because
a single 'load as high as possible' takes care of all the trouble.
  (there's enough necessary trouble left to swap command in/out of XMS...)
I call this 'intelligent design', and so far there were no adverse
effects reported.

sure your particular problem could be solved by freecom, but nobody
will spend time on this.

it can be solved as well or better by a small external utility; just have
the first line in autoexec.bat be ENVLOW.EXE.
and moving program code around is probbaly easier in ASM then in C

even better: you can do it yourself without learning C ;)

  not rocket science.
memory juggling in freecom was advanced engineering; in kernel.sys it
*was* rocket science.

Tom



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 Bertho ???,

 You may call me Czerno, Herr Ehlert
your email signature reads Bertho Grandpied y31415926...@yahoo.fr
that translates to Bob Bigfoot, right ?

 You can't escape having to explain what adverse effects you were evoking, 
 now anyway.

 command.com is a 'normal' program. just allocating DOS memory will
 give you an environment at ~1800:0. not such a good idea.

 You are joking, Herr Ehlert, richtig ?
 Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing...
 No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS.
 MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/.
 And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you.

I recommend to apply your 'allocate low' change to FreeCOM yourself.
you will see what happens.


 Of course the kernel is in HMA, which may be what your reply eluded !
no.

 And EVEN if for some reason HMA was not available or not given to
 the DOS kernel, what makes you deem an environment at ~1800:0  not such a 
 good idea ?
you would end up with
3   K COMMAND.COM, (resident part)
100 K FREE (remainders of freecom before resizing)
1   K   command.com environment (at ~1800:0)

 I this all your deep reason for forcing the master ENV up at 9 ?
 In which way other than your respectable personal preference is it better?


 This is highly ridiculous. At least provide a choice. Leave it to 
 power /users/ to determine for themselves what memory layout is 
 best in /their/ situation.

 Ah, but - sorry, I was forgetting - you /don't care/ much about your users.
your are making things up - again.

you asked
   How many users do you have ?
I answered
  I have no idea - and don't care.

 How do you say arrogance in German, Herr /Doktor/ Ehlert ?
Arroganz.

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 you would end up with
    3   K COMMAND.COM, (resident part)
    100 K FREE         (remainders of freecom before resizing)
    1   K   command.com environment (at ~1800:0)

 How lame ! Of course, your Freecom shall have to play a minimum game of
 releasing its own initialisation code and data, resizing and
 possibly moving things along. Basic DOS system coding skills, not rocket 
 science.

 This is/the/ official shell we are talking of, not some half baked
 throwable transient proggy, it deserves having a minimum of /intelligent
 design/ applied :=)

it looks like a real experienced programmer (you) has to show us
confused youngsters how it should be done!

 There are even other enhancements that could be made in the same domain,
 an easy one is to give back the /initial/ environment (if any) received by
 your Command from its caller (or from Sysinit). It is of no use after the
 Master ENV is built. Freeing it would give FreeDOS an edge over MS 
 Command. But the important is the above.
I'm deep impressed. we have a black belt grandmaster on visit. unfortunately too
busy to work, but we are so happy to receive good advice ;)


 You (or was it Eric) repeated
 that FreeCOM had to follow MS-Command,
it was dennis

 but in this respect it doesn't
 even start to try, I am /sorry/ to observe.


 How do you say arrogance in German, Herr /Doktor/ Ehlert ?
 Arroganz.

 Itself ! I may sound harsh, but being accused of ignorance by 
 more ignorant is the only word of excuse I will utter.
this 'more' makes me think that you should prove your competence first

 Let's forget /name calling/ ? If you agree, I'm your man

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

Hi,

 Should OTOH you (and the FreeDOS project at large) wish to offer the
 free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll
 contact you for arranging the mirroring. It's a simple, robust and
 tiny DOS device driver coded in ASM, a few hundred bytes altogether.
it probably should be merged into the kernel, or actually used as a
blue print to fix the bug (?) in the current kernel that prevents the
XBDA move.

 On the other hand, if FreeCOM hasn't been revised since 2001,
nobody said that.

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

[Tom Ehlert]

 Thanks. It would work indeed because - as I was checking a few minutes
 before reading your mail - FreeCOM does maintain the master environment
 pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
 to use the contents of that 'slot', not some copy it made, whenever
 it needs to access the ENV.

that's how 'edit the parent/master environment' utilities work(ed),
it's 'documented undocumented' behaviour, and FreeCOM behaves and has
to behave) the same way.
 At least a search (using debug!) did not
 find the environment segment, as data, inside FreeCOM's live memory.

 Of course it could be keeping the live ENV's segment in 
 registers, but since that is C it's dubious registers are used for 
 long time storage (contrary to what ASM code does profusely, at least mine).

if the master environment would be simply
'data' with some internal variable pointing to it, the master
environment would be obviously swapped out (or located at :)

but of course you knew that

tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 I'm surprised you have to question this!
after ~12 years without anybody complaining, I'm surprised about you
 complaining.

 How many users do you have ?
I have no idea - and don't care.

 Of these, how many understands this level of detail, /and/ in addition, will 
 care ?
answering this question would imply that /you/ understand the problem.
you don't.

 Methinks you were p.ssed off by my remarks, but there is nothing
 personal to them. Who is , or are, the 'appointed maintainer(s)' for
 FreeCOM ? Are you one of them ?
'appointment' would imply structure, leadership, organisation, ...
none of this is currently happening.

I just wrote the code to put the environment where it is (in 2001),
that's all. and it's placed where it is for a *very* good reason.
just think a bit about it


 the FreeDOS kernel relocates the XBDA.

 Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by 
 default.
this is either a bug, or your XBDA behaves somewhat different. an
unrelated story.

 *then* config.sys processing happens; possibly some driver maps a000-
 b7ff as conventional memory

 *then* comes command.com, and maps it's environment as high as
 possible. if b7ff is available, it will load it's environment there.
if  ef00 is available, it's loaded there.

 Why these latter limits would be thus hard-coded is beyond me.
b7ff is shorter then 'the highest location in conventional memory'

it was easier to do it the way it is, and so far nobody
complained.

 HA ! Sincerity itself, at last! Now this I /can/ understand, and even
 sympathise with :=)  Not in line with what Dennis wrote, though...
there are always people with more time and energy to write then knowledge to
write about :(

 that's a pretty good design decision.

 Only for so long as no one disputes it :=)... FreeCOM can't claim 
 MS-Command.com compatibility until time it has an option, and 
 I would suggest, the /default/, to allocate the master env block from 
 the bottom, instead of the top of conventional mem.

 Besides, I hardly see how it was easier, your word, for FreeCOM to do
 it in the current way. I'd rather suspect whoever made the decision,
*I*
 back when, was confused,
*no*



 similar to how DM Cunney remained somehow
 apparently confused to this day.
;)



 Casually peeking at Freecom source, branch MAIN, init.c v 1.31,

 Freecom's  rev 1.31 (Excerpt, from Sourceforge CVS, w/ line numbers) 
 [code]
 437   env_resizeCtrl |= ENV_USEUMB | ENV_ALLOWMOVE | ENV_LASTFIT;
 438   if(forceLow)
 439   env_resizeCtrl = ~ENV_USEUMB;
 440   if(newEnvSize  16  newEnvSize  32767)
 441 env_setsize(0, newEnvSize);
 [/code]

 et caetera, etc...

 I'm not an expert in C, not even close to a novice...
good find.

 With this duly noted, it appears it won't be hard for you Freecom
 code contributors / revewers (is this not you, Tom E.?) to edit the above
 module and possibly a handful of dependencies so that FreeCOM eventually
 will request the environment block using Firstfit instead of Lastfit
 strategy, at least when allocating from low memory. I don't care as much
 if it uses lastfit when the request is effectively UMBs only, although
 I'm not sure what is to be gained by using 'lastfit' even in upper memory.

 Hoping someone will take the challenge,


left as an exercise to the reader. suffice it to say: you wouldn't like the
adverse effects.






Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

Bertho ???,

 Casually peeking at Freecom source, branch MAIN, init.c v 1.31,
 ...
 I'm not sure what is to be gained by using 'lastfit' even in upper memory.
 ...
 Hoping someone will take the challenge,

 left as an exercise to the reader. suffice it to say: you wouldn't like the 
 adverse effects.

 Is there a FreeCOM 'blueprint' or design document for FreeCOM 
 other than the code comments ?
nothing except 'look at how MS command behaves'

 You can't escape having to explain what adverse effects you were evoking, 
 now anyway.


command.com is a 'normal' program. just allocating DOS memory will
give you an environment at ~1800:0. not such a good idea.
usually ~9f00:0 is a much better place.
and juggling memory around (beyond what is already done) was so far
never necessary  (and still isn't)

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 I've seemed to notice Command.com locates its master environment
 block at the top of conventional memory
 Is this behaviour user-controllable with some switch while loading
 FreeCOM ?

 what would be the purpose to change this ? whee would you
 like to have it ?

 Or otherwise, depending on the global FDConfig ? I could
 not find a way to change this - which is not a good design decision

 why is this not a good design decision ?

 I'm surprised you have to question this!
after ~12 years without anybody complaining, I'm surprised about you
complaining.

 Tis bad because the block
 in question exceedingly ill-placed, a user who is able, one way or
 another, to have usable RAM mapped above the 640 k so-called limit
 into the video memory' segments, up to 736 k (B7FFF), will be
 forced to use the added memory as UMBs instead of an extension of
 *contiguous* so-called conventional mem. Of course the default
 placement of an XBDA (in case there is one, that is, almost always
 nowadays) deserves the same blame but either the kernel or some
 utility will routinely relocate it down during Config.sys
 processing.
the FreeDOS kernel relocates the XBDA.

*then* config.sys processing happens; possibly some driver maps a000-b7ff as
conventional memory

*then* comes command.com, and maps it's environment as high as
possible. if b7ff is available, it will load it's environment there.

if  ef00 is available, it's loaded there.

it looks like you have a particular strange setup thaqt you are
disturbed by command's environment. maybe you are mapping memory
in/out dynamically ?


 The why has been explained. In addition, under /some but not all/
 BIOSes, it seems the presence of a DOS MCB-covered zone under the
 'video' area may perturb conventional memory reporting by the API of
 int 15/E820. Not confirmed.
don't make things up


 Want more ? OK, additionally, some
 (admittedly very rude, maybe very old) DOS programs will neglect to
 check where the memory 'above' them ends, and use any and all BIOS
 int 12 mem without reservation.
sure. execute such programs, and you deserve no better. CtrlAltDelete
will clean up ;)

 for that reason the end of the
 'transient program area' should as far as possible coincide with the
 end of conventional (int 12) memory.

 To where : by default, or absent DOS-managed UMBs, put it on top of
 the main FreeDCOM code (this is how MS does it).
it was easier to do it the way it is, and so far nobody complained. that's
a pretty good design decision.

 Optionally relocate to an available UMB.
already done (in 2001).

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

 That's funny, because I thought that the master environment was
 controlled by the kernel.sys? 
obviously not as it's size is controlled by '/E:512'

 Maybe they can add a switch that
 forces the environment be loaded in upper ram instead of conventional? 

'they' could do nearly everything
at the time the environment was put to ~9f00:0 there simply didn't
exist upper memory in FreeDOS  (and having a switch to move ~512 byte
to upper memory is not s exiting ;)

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com (Freecom) main environment location

[Tom Ehlert]

Hi Bertho,


 I've seemed to notice Command.com locates its master environment
 block at the top of conventional memory, just under the video (and
 under a BIOS defined extended bios data aka EBDA, if any). 

 Is this behaviour user-controllable with some switch while loading
 FreeCOM ?
what would be the purpose to change this ? whee would you like to have
it ?

 Or otherwise, depending on the global FDConfig ? I could
 not find a way to change this - which is not a good design decision
why is this not a good design decision ?
where would you put it and why ?


 overall IMHO, at least not if it can't be overridden  :-(

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] hexed 1.2e released

[Tom Ehlert]

 I fixed some compile time errors and uploaded new version (1.2e) of Hexed
 to my site. This is a DOS and Linux console hex viewer/editor.

 http://digitalatoll.com/pub/DMSOFT/hexed-src-1.2e.zip

 The sourceforge project is at

 http://sourceforge.net/projects/doshexed

'Also, if you find this program of use then please consider contributing to
the source code and or sending a donation of atleast $5.00 to Chris Evans.
You can use the PayPal donate button on the digitalatoll.com.'

you must be kidding

Tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Makehtml v0.0.1

[Tom Ehlert]

 GPL, so patches welcome! :-)

 Patch what?  This code is so tragically flawed and devoid of purpose
 that there is nothing worth patching.

 In case it wasn't obvious, 0.0.1 implies that the program is far from
 finalized, perfected, mature, or even release quality. Ever heard of
 write one to throw away?

write one to throw away is what the author should have done, rather
then throw it at the FreeDOS user list

he might come back when it does something useful, not with some 0.0.1

Tom



--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

Dear Louis,

a few points

a) the FreeDOS project isn't very interested in a BC5 compiled
kernel because BC5 isn't freely available/open source;
I also doubt the output of BC5 will be significant better then the OW
output.
feel free to experiment, but don't expect us to be excited ;)

 So, something in the make files/build files is skipping building a concrete
 GLOBAL for ReturnAnyDosVersionExpected for BC5.  There's a MAIN define
 checked but the build process doesn't seem to get defined anywhere. :/

b) when trying to port the kernel to a new compiler, you should be
able to fix such issues yourself. generate assembler output, see what
is wrong. you will need this as the FreeDOS uses the
 'interesting memory model (TM)'

 Need to do more digging.
c) no need to write 'need more digging' type of mails. use your
twitter account for that.

Tom

 On Tue, May 14, 2013 at 9:10 PM, Louis Santillan lpsan...@gmail.com wrote:

 BC5 in my hands in 5 days for $35 shipped from Canada.


 On Thu, May 9, 2013 at 5:58 AM, Louis Santillan lpsan...@gmail.comwrote:

 So I bought a shrink wrapped copy of BC5 off ebay today.  Should be in my
 hands in 7-10 days.  :D


 On Tue, May 7, 2013 at 10:45 AM, Louis Santillan lpsan...@gmail.comwrote:

 On Mon, May 6, 2013 at 5:46 AM, Tom Ehlert t...@drivesnapshot.de wrote:


  Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.
  Read (
  ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and
 sections
  2.3.x  3.5.  Enlightening and disappointing.  There does not seem to
 be a
  way to get 32-bit instructions out of wcc as Tom had mentioned.  3.5
  recommends
 Watcom is open source; feel free to add 32 bit instructions to the 16
 bit compiler


 I think recompiling with BC 5.0.2/4.5.2 would be a better option at this
 point.  I'd love to have the time to do this. :/


   The recommended options for generating the fastest 16-bit Intel
 code are:
  Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
  Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
  486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
  386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
  286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
  186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
  8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87

  -ot of -onatx  -zp8 contradict the original makefile's code -os 
 -zp1
  (optimize execution time vs. executable size  align on byte vs.
 8-byte,
  respectively).  Also, the -fp*'s opts don't apply and wcc barfs on
 -oi+.

 we *want* -os  (optimize for size); size matters. both size on disk and
 size in memory are (somewhat) important. speed does *not* matter as
 there is virtually no time spend *inside* the kernel.

 to experiment, run some benchmark (like compiling a big project), on
 an optimized kernel vs. not optimized kernel vs. borland kernel.
 measure times. think.

 we *need* -zp1 as DOS structures have specific byte offsets.


 Thanks for that tip about zp1.

 As for benchmarks (implied by the Regression Tests), that is on the
 FreeDOS 1.1-1.2 Road Map Action Items anyways.  I'd like to help with 
 that.

 I think I'm going to peruse Simtel and try to find OS benchmarks before
 I start writing stuff that simply uses UTILS/RUNTIME.  For Regression
 Testing, I'd suggest using something like TAP (
 http://en.wikipedia.org/wiki/Test_Anything_Protocol).  I might even be
 able to contribute some code here.  Otherwise, we can brainstorm some
 benchmarks and tests

 FAT12 vs FAT16 vs FAT32,
 File Reads (Small 1K, Medium 1MB, Large 16MB, Huge2GB),
 File Writes
 File Creates
 File Deletes
 RAMDISK vs FDD vs HDD,
 File Copies (Same RAMDISK, RAMDISK-HDD, HDD-RAMDISK, RAMDISK-RAMDISK,
 Same HDD, HDD-HDD)
 With  Without Caching
 Cache Sizes
 With  Without Share
 Process Starts
 Boot Times
 Kernel Compilation Times







Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

 I don't think wcc.exe was ever meant to output 32-bit code. Granted,
 as mentioned previously, it will do some things (movsx), but
 apparently it doesn't use the extended 32-bit registers.


 That's the most disappointing part.   As expensive as Watcom was, I was
 expecting it do this kind of thing, and do it well.

watcom was primarily a compiler for DOS protected mode (32-bit)
programs.

Tom


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

 Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.  Read (
 ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
 2.3.x  3.5.  Enlightening and disappointing.  There does not seem to be a
 way to get 32-bit instructions out of wcc as Tom had mentioned.  3.5
 recommends
Watcom is open source; feel free to add 32 bit instructions to the 16
bit compiler




 The recommended options for generating the fastest 16-bit Intel code are:
 Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
 Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
 486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
 386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
 286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
 186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
 8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87

 -ot of -onatx  -zp8 contradict the original makefile's code -os  -zp1
 (optimize execution time vs. executable size  align on byte vs. 8-byte,
 respectively).  Also, the -fp*'s opts don't apply and wcc barfs on -oi+.

we *want* -os  (optimize for size); size matters. both size on disk and
size in memory are (somewhat) important. speed does *not* matter as
there is virtually no time spend *inside* the kernel.

to experiment, run some benchmark (like compiling a big project), on
an optimized kernel vs. not optimized kernel vs. borland kernel.
measure times. think.

we *need* -zp1 as DOS structures have specific byte offsets.

tom


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Tom Ehlert]

Hallo Herr Louis Santillan,


 https://sites.google.com/site/lpsantil/Home/386DIS.ZIP
 https://sites.google.com/site/lpsantil/Home/686DIS.ZIP
 https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP
 https://sites.google.com/site/lpsantil/Home/kernels.zip

the differenz is an empty memdisk.lst (for whatever reason)
everything else is *identical*

I'm not impressed

Tom


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] where?

[Tom Ehlert]

 Exactly *where* is the string of characters for the path variable stored?
in the environment which is pointed to by the PSP
http://en.wikipedia.org/wiki/Program_Segment_Prefix

 For that matter, where are stdin/out/and err?
that's like asking 'where is monday'

tom


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New standard FreeDOS text editor - what it should be (voting)?

[Tom Ehlert]

 - An editor should be small enough to run on a 128K machine.
FreeDOS will not run on a 128K machine.

 - Calculator?  How many people do not have a physical calculator or cell
 phone laying around nearby?
you are right. but wtf will I use a 128K machine for if I have a
iPhone around ?

 - An editor should be smart enough to page in parts of the file as it
 needs to from disk.  This enables editing of files that are larger than
 the memory size.

 - An editor should have journalling to help recover the lost work if
 the machine crashes while editing.  This is normally done by recording
 the keystrokes to a separate temporary file and flushing them to disk 
 periodically.  In the event of a crash the journal file can be replayed
 to restore most of the edits, and hopefully not cause another crash 
 because of a bug in the editor.
yep. and run on a 128K machine ?

 - Undo support.

 - The ability to convert tabs to whitespace and vice-versa.

 - A pop-up on-screen ruler.

 - Regular expression support for searching through text.

 - A hexadecimal display mode.

yep. and run on a 128K machine ?

 And I'm sure that other people have many other good ideas ...

and ability to play tetris while printing ;)

Tom


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New standard FreeDOS text editor - what it should be (voting)?

[Tom Ehlert]

 On 1/29/2013 11:09 AM, Tom Ehlert wrote:
 - An editor should be small enough to run on a 128K machine.
 FreeDOS will not run on a 128K machine.

 Ok.  Then make it 256.  You get the idea.

 I haven't looked into the source code, but is FreeDOS really that much
 of a memory hog where it will not boot and run in 128K?
just as an exercise: have you tried to run MSDOS 6.22 (where we are
mostly comparable to) on a 128K XP machine ?

the kernel itself is - after init - ~64 K. no XMS around, so this
stays 64 K. how do you start 64K+ Freecom in 64K- left and do more
then
   @ECHO Hello World ?


 That seems absurd.
your hope to run a 20 year old 'modern' DOS on a 35 years old machine
is absurd.
it's like complaining the Ford T4 had no climate control

 We can debate how useful a 128K machine is, but DOS can't
 possibly be using all of that memory.

 - Calculator?  How many people do not have a physical calculator or cell
 phone laying around nearby?
 you are right. but wtf will I use a 128K machine for if I have a
 iPhone around ?

 Because some people are interested in old hardware ?  What kind of 
 question is that?
if you have a 128K machine, you also have a MSDOS 1.0 operating
system for it. go use this.

 Why is anybody messing with FreeDOS in the first place?
some use it to do something *useful*

 DAED and (the advanced version of Dewar's Visual EDitor) has this
 feature.  It ran well in a 128K machine.
great. no need to write yet another journaling editor

 I understand your skepticism.  But running in a 128K machine is really
 not such a stretch.  (Unless FreeDOS really is a memory hog. I'll have
 to go see what it's using.)
I'd be surprised if MSDOS 6.22 does significant different

FreeDOS Kernel and COMMAND have been optimized to use XMS; 128K PC
machines were never a target.

Tom


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New standard FreeDOS text editor - what it should be (voting)?

[Tom Ehlert]

 Get up on the wrong side of the bed today?  Why so defensive?

 PC/MS DOS 5.x and 6.x will run in 256K with usable memory to spare.
 PC/MS DOS 3.x will run in 128K with usable memory to spare.
FreeDOS will inherently use ~60K more then MSDOS as command.com swaps
only to XMS or not at all.

 If FreeDOS
 is designed/optimized for a bigger footprint then that's fair, but there
 is nothing wrong with asking or trying to push the limits.
it was always assumed that XMS is plenty (  128K) available.

BTW: when I started with Freedos some time in 2001, I remember 420 K
free with just kernel and FreeCOM loaded. this leaves the kernel and
freecom using 220 K.

as most optimizations were 'use XMS to reduce low memory footprint'
this is mostly still true today.


 ...  I'd also reserve the use of wtf for situations that deserve it.
 Like, when a tree falls on your car.
point taken :)

Tom


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user