[Freedos-user] FreeDOS 1.1 SATA Support

[Ercan Ersoy]

Hello. I care SATA support on FreeDOS 1.1 CD. I researched AUTOEXEC.BAT and 
CONFIG.SYS on FreeDOS 1.1 CD on boot floppy disk image (FDBOOT.IMG) that is 
booting via Syslinux. I applied  commands those are I found on  FDBOOT.IMG on 
my other FreeDOS system. But I can't give support SATA on my system.

Best regards.
Ercan Ersoy


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

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Sat, Jul 2, 2016 at 2:19 PM, Abe Mishler  wrote:
>
> I'm interested in learning how games like DOOM (requires 3MB available)
> were able to work. I know I know, read the source code.

AFAIK, Doom was originally compiled with Watcom using a DOS extender
(DOS4G Professional). So it's 386 pmode code.

All the open source ports (since late 1997?) started with the
so-called Linux sources (thus no DOS soundcard support), so pretty
much all of the newer DOS-based ports used DJGPP v2 (DPMI) and Allegro
(sound, gfx). This was before OpenWatcom was officially released
(2003).

See here:ftp://ftp.idsoftware.com/idstuff/source/doomsrc.txt

> I'm getting there. I'm also reading "MS-DOS Beyond 640K" by James Forney.
> Interesting to note that Id says not to use memory managers or disk caching
> programs with Doom.

Even back in the DOS days, I don't think anyone was naive enough to
expect everyone to (always) run without any memory managers. DOS
extenders usually went out of their way to support multiple
environments (raw, EMS/VCPI, XMS, DPMI). Certainly running under
Windows wasn't always forbidden, and that won't let you disable
everything.

Yes, some DOS games needed a fairly clean setup, but most of them (by
design) could handle themselves gracefully in multiple environments.
E.g. Quake (DJGPP-based) was explicitly debugged and tested so that it
could run under Win95 with (I think?) only 16 MB of RAM.

> Doom and other games must do their own memory management which makes sense
> for performance.

Doom may allocate everything up front and privately manage it all
itself, but that's all. It's not overriding the OS (or APIs).

And yes, that was probably faster for 1993, back when the best you had
was a fast 386 or slow 486. Although technically the Intel Pentium
(586) first came out in 1993, but it wasn't common. Even when Quake
came out in 1996 (and was heavily optimized for Intel's pipelined 587
FPU), the Pentium wasn't universal.

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Great tip!!! I'll have to try that!

> On Jul 2, 2016, at 6:30 PM, Ulrich Hansen  wrote:
> 
> Hi Abe,
> 
>> Am 01.07.2016 um 14:59 schrieb Abe Mishler :
>> 
>> except linux can 
>> mount raw images for native file sharing 
> 
> Today I found out: If I choose „VHD“ as type for the virtual harddisk in 
> VirtualBox, I am able to mount the VirtualBox image in Windows too. 
> 
> See: https://www.lazybrowndog.net/freedos/files/vhd.png
> 
> Now I just open „Computer Management“ in Windows, right-click on "Disk 
> Management" and choose "Attach VHD“.
> See this description here: 
> http://www.online-tech-tips.com/computer-tips/create-mount-vhd-windows/
> 
> (You can only attach local VHDs, not those on a network share.)
> 
> And for the record: For OS X there is a free program by Paragon, which does 
> the same:
> 
> https://www.paragon-software.com/home/vd-mounter-mac-free/
> 
> So another thing VirtualBox can do as good as qemu.
> 
> Ulrich
> 
> 
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

Hi Abe,

> Am 01.07.2016 um 14:59 schrieb Abe Mishler :
> 
> except linux can 
> mount raw images for native file sharing 

Today I found out: If I choose „VHD“ as type for the virtual harddisk in 
VirtualBox, I am able to mount the VirtualBox image in Windows too. 

See: https://www.lazybrowndog.net/freedos/files/vhd.png 


Now I just open „Computer Management“ in Windows, right-click on "Disk 
Management" and choose "Attach VHD“.
See this description here: 
http://www.online-tech-tips.com/computer-tips/create-mount-vhd-windows/ 


(You can only attach local VHDs, not those on a network share.)

And for the record: For OS X there is a free program by Paragon, which does the 
same:

https://www.paragon-software.com/home/vd-mounter-mac-free/ 


So another thing VirtualBox can do as good as qemu.

Ulrich


--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

> On Jul 1, 2016, at 4:17 PM, Rugxulo  wrote:
> 
> Hi,
> 
>> On Tue, Jun 28, 2016 at 10:08 AM, Eric Auer  wrote:
>> 
>> I think that even 597 kB of low DOS memory is plenty for old DOS programs.
> 
> "597 kb should be enough for anyone." -- Eric Auer, 2016:-)
> 
> In Abe's recent screenshot, he shows that he's now getting (thanks to
> Ulrich) "628 kb" free. This is actually "643,488" bytes! That's
> plenty! (It's easy to forget that "kb" is not equal to 1000.)
> 
> Seriously, I can't speak for all apps, but it's rare to need (much
> more, if any) greater than 500 kb. Needing 600 kb is almost unheard of
> (right??). At least, I only vaguely remember one demo (submerge??)
> that needed over 600,000 bytes free. And even that was probably badly
> designed. Some games require more than 500 kb, but that too is of
> questionable design. Most well-behaved apps (yeah, I know that's not
> saying much) don't really need that much.
> 
> My own VBox setup "only" gets 596 kb (610,544) free. That's HimemX
> only (and FreeCOM XMS_Swap, of course; and yes, packet driver can vary
> a lot in size, too). I can't remember exactly, but my native FreeDOS
> install is also similar, and I see no huge problems. Though it's
> impossible to test everything, of course.
> 
> Can anyone provide real-world usage examples of needing 600,000 bytes
> or more free?? (Besides obvious things like user data or combining
> several TSRs.) Do any popular apps from yesteryear need that much?
> 
I don't have any real-world data for apps, but  I'm interested in learning how 
games like DOOM (requires 3MB available) were able to work. I know I know, read 
the source code. I'm getting there. I'm also reading "MS-DOS Beyond 640K" by 
James Forney. Interesting to note that Id says not to use memory managers or 
disk caching programs with Doom. Doom and other games must do their own memory 
management which makes sense for performance.

http://www.classicdoom.com/doominfo.htm

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi again, quick reply,

On Fri, Jul 1, 2016 at 3:17 PM, Rugxulo  wrote:
>
> On Tue, Jun 28, 2016 at 10:08 AM, Eric Auer  wrote:
>>
>> I think that even 597 kB of low DOS memory is plenty for old DOS programs.

Just FYI, in an email to Mateusz a year ago, I told him this:

"
BARE_DOS (under 8086tinyplus/winapi) "mem /c" shows me 466784 bytes
(456 kb) free. "call /s mem /c"
shows me 570112 (557 kb) free. Yes, that's using KSSF and FreeCOM
0.82pl3 by default.
"

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Tue, Jun 28, 2016 at 10:08 AM, Eric Auer  wrote:
>
> I think that even 597 kB of low DOS memory is plenty for old DOS programs.

"597 kb should be enough for anyone." -- Eric Auer, 2016:-)

In Abe's recent screenshot, he shows that he's now getting (thanks to
Ulrich) "628 kb" free. This is actually "643,488" bytes! That's
plenty! (It's easy to forget that "kb" is not equal to 1000.)

Seriously, I can't speak for all apps, but it's rare to need (much
more, if any) greater than 500 kb. Needing 600 kb is almost unheard of
(right??). At least, I only vaguely remember one demo (submerge??)
that needed over 600,000 bytes free. And even that was probably badly
designed. Some games require more than 500 kb, but that too is of
questionable design. Most well-behaved apps (yeah, I know that's not
saying much) don't really need that much.

My own VBox setup "only" gets 596 kb (610,544) free. That's HimemX
only (and FreeCOM XMS_Swap, of course; and yes, packet driver can vary
a lot in size, too). I can't remember exactly, but my native FreeDOS
install is also similar, and I see no huge problems. Though it's
impossible to test everything, of course.

Can anyone provide real-world usage examples of needing 600,000 bytes
or more free?? (Besides obvious things like user data or combining
several TSRs.) Do any popular apps from yesteryear need that much?

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 01.07.2016 um 14:59 schrieb Abe Mishler :
> 
>> 
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=B000-B7FF I=C800-EFFF
>> NOVME NOINVLPG
>> 
> That works like a charm! Do those regions work for you?

Yes. I tested it on a FreeDOS 1.1 guest on my Mac. 

And, as I don’t have Windows machine anymore, I started a Windows 10 VirtualBox 
guest, and inside of it I used VirtualBox for Windows and tested it there with 
a FreeDOS 1.1 guest. Normally JEMMEX crashes there, but not this time.

> Could you provide an explanation regarding those regions?

Actually they discussed it in the VirtualBox forum:

https://forums.virtualbox.org/viewtopic.php?f=4&t=77078&sid=4702e57e2da69b00248e9a82eeffbe98
 


Seems some people at Oracle are still interested in DOS.

> I will now revisit my decision to use QEMU on linux... except linux can 
> mount raw images for native file sharing without having to FTP into 
> FreeDOS (which I got working).

Yes, this is nice. On OS X you can just double-click the image to mount it.

Just a quick review about qemu and networking: 

Networking with qemu is difficult. Per default it uses NAT, but only for TCP. 
So I can’t ping the outside world. WGET works. I managed to transfer files with 
FileZilla to mTCP ftpsrv. (Which is a miracle as all other clients won’t even 
do a directory listing.)

For bridged networking I’d have to install a TUN/TAP software on the host. 
Complicated.

I start qemu with:

qemu-system-i386 -hda freedos.img -boot c -m 32 -netdev 
user,id=usernet,net=192.168.3.0/24,dhcpstart=192.168.3.101 -device 
pcnet,netdev=usernet -redir tcp:2121::21

With „-device pcnet“ qemu supports the AMD PCFastIII (pcnet) network card, so 
the packet driver in FreeDOS 1.1 (PCNTPK) can be used. 

> Thanks a lot for re-opening my can of worms!!! :-p

Brr. :-)

Good luck!!

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Hi Ulrich!

On 7/1/2016 3:35 AM, Ulrich Hansen wrote:
>
>> Am 01.07.2016 um 01:51 schrieb Abe Mishler > >:
>>
>>  I have been learning a lot about JEMMEX as compared to the other
>> drivers lately.
>
> Hi Abe,
>
> If you don’t mind, it would be great if you could try one last thing
> with VirtualBox and JEMMEX:
>
> Please try to start JEMMEX with this line in FDCONFIG.SYS:
>
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=B000-B7FF I=C800-EFFF
> NOVME NOINVLPG
>
That works like a charm! Do those regions work for you?

Could you provide an explanation regarding those regions?

I will now revisit my decision to use QEMU on linux... except linux can 
mount raw images for native file sharing without having to FTP into 
FreeDOS (which I got working).

Thanks a lot for re-opening my can of worms!!! :-p

Seriously though, after all of my learning, I think I had decided 
yesterday to walk away from JEMMEX ... (circling back around) in which 
case VirtualBox works just fine... decisions, decisions... grrr.

http://tinypic.com/r/30hq7gi/9

Extended (XMS), Total=32,704K, Used=6,005K, Free=26,699K
Total Expanded (EMS) = 8,576K
Free Expanded (EMS) = 8,192K
Largest executable program size = 628K
Largest free upper memory block = 137K

Thanks!

> Important are both includes I=B000-B7FF I=C800-EFFF.
> Does this change anything for you? Does it still crash?
>
> Thanks!
>
>
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
>

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 01.07.2016 um 01:51 schrieb Abe Mishler :
> 
>  I have been learning a lot about JEMMEX as compared to the other drivers 
> lately. 

Hi Abe,

If you don’t mind, it would be great if you could try one last thing with 
VirtualBox and JEMMEX:

Please try to start JEMMEX with this line in FDCONFIG.SYS:

1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=B000-B7FF I=C800-EFFF NOVME 
NOINVLPG

Important are both includes I=B000-B7FF I=C800-EFFF. 
Does this change anything for you? Does it still crash?

Thanks!


--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi again,

On Fri, Jul 1, 2016 at 12:34 AM, Rugxulo  wrote:
>
> But I agree, in theory, that JEMMEX shouldn't be preferred or
> suggested without a good reason. But that's not my decision for FD 1.2
> (and I forget offhand what Jerome uses, I haven't downloaded any
> recent prereleases, too preoccupied with other bagatela).

Just so Jerome doesn't tear me a new one (not really, he's nice), I
quickly downloaded FDI-FLOPPY.zip (dated June 27):

It simply loads HimemX (XMSv3, 386+) and nothing else.

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Thu, Jun 30, 2016 at 6:51 PM, Abe Mishler  wrote:
>
>> On Jun 30, 2016, at 6:19 PM, Rugxulo  wrote:
>>
>> If JEMMEX is your only problem, then you have no problems.
>
> This idea has appeared before in this thread and it is a relief to hear it 
> echoed.
> Perhaps a disclaimer like this is warranted in the Wiki install guide for new 
> users
> like myself. (I had very limited exposure to DOS when it was mainstream so 
> the idea
> of so many different memory modes has been overwhelming to learn suddenly.)

I didn't have a PC back then, but AFAIK 

The IBM PC used an 8088 in 1981. The max memory supported was 640 kb
(low / conventional), but even that was usually overly idealistic. I
think?? you typically got 400 kb free back in those days (if you could
even afford the full 640 kb at all). The original IBM PC didn't even
have a hard drive, and it shipped with like two 160 kb floppy drives.
I think 64 kb of RAM was the initial amount (similar to CP/M, I
suppose).

Only later did 500 kb RAM free become the norm and even required, e.g.
MS-DOS 5 bragged about freeing up "45 kb at least".

Of course, originally it was optional things like (hardware) EMS that
(partially) brought more RAM. That was presumably more common with
8086-ish machines than newer ones. With the 286, although it took a
while to standardize, the preferred approach was either "raw", XMSv2,
or DPMI (which really sat atop one of the others). Even DPMI didn't
appear until 1989/1990 with Windows 3.0.

The 286 was, what, 1982? Obviously the 386 was (first) introduced in
1986 by Intel. But the IBM PC didn't get the 286 until (I don't even
know) XT? Nope, Wikipedia says "XT 286" was 1986. Nope, Wikipedia also
says "The 80286 was employed for the IBM PC/AT, introduced in 1984".
But it took a *long* time for megabytes of RAM to become common. It
was just too expensive. (My 1994-era 486 Sx/25 only had 4 MB.)

Long story short, the differing memory APIs were due to different
hardware. So hardware "expanded" (EMS) needed one API while the 286
(max 16 MB RAM)'s "extended" (XMS) memory needed another one. And
Windows 3.0 (1990) invented yet another one (DPMI) that was "better"
than VCPI (and more widely supported, although most DPMI servers ended
up being 386+ anyways).

> If a consensus can be reached, I would humbly submit the idea of swapping 
> options 1 and 2 in the next release to give less emphasis to JEMMEX.

Even Blackthorne (game, which is now freeware BTW) required EMS, and
that was what, 1990s?? (Wikipedia says 1994.) So we can't totally say
that nobody should or can use EMS (e.g. EMM386). But yeah, I agree,
JEMMEX as default isn't really all it's cracked up to be (due to
various rare quirks, among other reasons).

> As a new user, I naively thought that JEMMEX was the best/preferred option 
> based on its ranking which may be intended.

In theory, if everything was perfectly bug-free, then sure, having
both XMS and software-emulated EMS (via V86 mode) + VCPI and using
UMBs (leading to more conventional memory free) is perfectly ideal.
(DPMI is usually loaded on demand via separate TSR.)

Obviously, in hindsight, you don't really need a billion APIs for the
same family of hardware. But that's the point, FreeDOS tries to
support 8086, 286, and 386 memory schemes (but no AMD64, obviously).

> But under the example of VBox, it doesn't hold up. I think I have learned now 
> that even though JEMMEX claims
> to do the same thing as option 2 in less memory by combining driver logic, 
> option 2 really works better even if
> there is a slightly larger overhead.

The more differing environments, the more testing you have to do to
support them all. It can add up, leaving obscure bugs.

> Option 2 certainly gives me more expanded memory (EMS).

Not sure why, offhand.

> At least this seems to be the case in VBox. However, JEMMEX behaves just fine 
> running under QEMU.
> So go figure. Perhaps the Wiki should push people towards QEMU on Linux 
> rather than VBox on Windows.

No, because most people don't need JEMMEX and/or EMS, and VBox
(sometimes) has other advantages. It's not worth giving up the whole
environment due to one or two accidental incompatibilities.

But I agree, in theory, that JEMMEX shouldn't be preferred or
suggested without a good reason. But that's not my decision for FD 1.2
(and I forget offhand what Jerome uses, I haven't downloaded any
recent prereleases, too preoccupied with other bagatela).

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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/listi

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Hi,

> On Jun 30, 2016, at 6:19 PM, Rugxulo  wrote:
> 
> Hi,
> 
>> On Thu, Jun 30, 2016 at 6:17 AM, Abe Mishler  wrote:
>> 
>>> On 6/29/2016 1:03 PM, Rugxulo wrote:
>> 
>> On the page that you sent regarding QEMU Binaries for Windows, it says:
>> "QEMU for Windows is experimental software and might contain even
>> serious bugs, so use the binaries at your own risk."
> 
> It's just a standard disclaimer, don't read too much into it. It works
> fine for me (FreeDOS). While I haven't exhaustively tested gigabytes
> of software, everything I tried seems to work fairly well, no huge
> obvious deficiencies. So don't worry.
> 
> The only real problem would be if it had major bugs and they refused
> to hear bug reports or even consider fixing them. AFAIK, that's not
> true. But indeed, I do think they prefer Linux more.
> 
> Nevertheless, several other OSes bundle Windows binaries of QEMU with
> some of their releases (e.g. ReactOS, AROS), so it must also work well
> for them too. So don't overreact, it works! But no software is 100%
> perfect, hence some people feel the need to explicitly disclaim legal
> liability, etc.
> 
>> Since QEMU is more mature on linux right now, I installed Xubuntu 16.04
>> LTS inside VirtualBox (5.0.24 now) and then QEMU inside of that.
> 
> I don't think it's a billion times more mature there. QEMU is a very
> complicated suite of software, for many many different architectures.
> Certainly it's almost strange / funny / pointless to install QEMU
> inside another OS inside VBox!
Yes, the levels of virtualization were getting ridiculous! Funny how it sped 
things up on a Win8.1 host though!!! I guess the farther away from Windows you 
get... well you fill in the rest. Ha!
> 
> VBox works well too. If you have problems with JEMMEX, then don't run
> that. Again, you really don't need it at all. Don't kid yourself, VBox
> is well-tested (overall), just not as much for DOS. So FreeDOS still
> (mostly) works fine there.
Great to hear! I have been learning a lot about JEMMEX as compared to the other 
drivers lately. You guys have been a terrific help!

> 
>> FreeDOS is much peppier inside of this configuration. I will probably get
>> another HD for a native Xubuntu install and skip the VBox on Win 8.1
>> layer altogether.
> 
> Setup a bootable USB jump drive instead, it's probably cheaper and
> easier. Okay, so technically I don't know of all the ways to make one
> (DistroWatch Weekly mentioned a few ways several months ago), but IIRC
> the latest Ubuntu actually recommends RUFUS (which is also well-known
> for supporting FreeDOS)!
> 
> A while back I had setup a Ubuntu 14.04 jump drive (with persistence),
> but it's fairly slow, so that may be a concern for you. But I don't
> think it has to be that way, I just don't have the time or energy to
> try billions of configurations.
I have decided (I think!) to involve the use of another HD (SSD) to get as much 
speed as possible.

> 
> antiX 13 was very good and lightning fast, and 16 was just released,
> so maybe you should try that instead, it's based upon Debian.
I'll have to look into that. Thanks!

> 
>> Side note: Since VBox was updated to 5.0.24 during this thread I decided
>> to try a new installation of FreeDOS with it but had the same problem.
> 
> If JEMMEX is your only problem, then you have no problems.
This idea has appeared before in this thread and it is a relief to hear it 
echoed. Perhaps a disclaimer like this is warranted in the Wiki install guide 
for new users like myself. (I had very limited exposure to DOS when it was 
mainstream so the idea of so many different memory modes has been overwhelming 
to learn suddenly.)

If a consensus can be reached, I would humbly submit the idea of swapping 
options 1 and 2 in the next release to give less emphasis to JEMMEX. As a new 
user, I naively thought that JEMMEX was the best/preferred option based on its 
ranking which may be intended. But under the example of VBox, it doesn't hold 
up. I think I have learned now that even though JEMMEX claims to do the same 
thing as option 2 in less memory by combining driver logic, option 2 really 
works better even if there is a slightly larger overhead. Option 2 certainly 
gives me more expanded memory (EMS). At least this seems to be the case in 
VBox. However, JEMMEX behaves just fine running under QEMU. So go figure. 
Perhaps the Wiki should push people towards QEMU on Linux rather than VBox on 
Windows.

Please correct me if I'm wrong or have missed something important.

Ok, back to you guys :)

> 
>>> But nothing beats running natively (on real hardware).
>> You're right about that. As Ulrich mentioned earlier, he uses screencast
>> software to capture what he's doing. I'm interested in doing the same so
>> I think FreeDOS in QEMU on linux is the way to go (for me, at this time).
> 
> Who knows, eventually there might be an official Flatpak (or Snappy?)
> package that works across all the major distros. I think that will
> ease deploymen

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Thu, Jun 30, 2016 at 6:17 AM, Abe Mishler  wrote:
>
>> On 6/29/2016 1:03 PM, Rugxulo wrote:
>
> On the page that you sent regarding QEMU Binaries for Windows, it says:
> "QEMU for Windows is experimental software and might contain even
> serious bugs, so use the binaries at your own risk."

It's just a standard disclaimer, don't read too much into it. It works
fine for me (FreeDOS). While I haven't exhaustively tested gigabytes
of software, everything I tried seems to work fairly well, no huge
obvious deficiencies. So don't worry.

The only real problem would be if it had major bugs and they refused
to hear bug reports or even consider fixing them. AFAIK, that's not
true. But indeed, I do think they prefer Linux more.

Nevertheless, several other OSes bundle Windows binaries of QEMU with
some of their releases (e.g. ReactOS, AROS), so it must also work well
for them too. So don't overreact, it works! But no software is 100%
perfect, hence some people feel the need to explicitly disclaim legal
liability, etc.

> Since QEMU is more mature on linux right now, I installed Xubuntu 16.04
> LTS inside VirtualBox (5.0.24 now) and then QEMU inside of that.

I don't think it's a billion times more mature there. QEMU is a very
complicated suite of software, for many many different architectures.
Certainly it's almost strange / funny / pointless to install QEMU
inside another OS inside VBox!

VBox works well too. If you have problems with JEMMEX, then don't run
that. Again, you really don't need it at all. Don't kid yourself, VBox
is well-tested (overall), just not as much for DOS. So FreeDOS still
(mostly) works fine there.

> FreeDOS is much peppier inside of this configuration. I will probably get
> another HD for a native Xubuntu install and skip the VBox on Win 8.1
> layer altogether.

Setup a bootable USB jump drive instead, it's probably cheaper and
easier. Okay, so technically I don't know of all the ways to make one
(DistroWatch Weekly mentioned a few ways several months ago), but IIRC
the latest Ubuntu actually recommends RUFUS (which is also well-known
for supporting FreeDOS)!

A while back I had setup a Ubuntu 14.04 jump drive (with persistence),
but it's fairly slow, so that may be a concern for you. But I don't
think it has to be that way, I just don't have the time or energy to
try billions of configurations.

antiX 13 was very good and lightning fast, and 16 was just released,
so maybe you should try that instead, it's based upon Debian.

> Side note: Since VBox was updated to 5.0.24 during this thread I decided
> to try a new installation of FreeDOS with it but had the same problem.

If JEMMEX is your only problem, then you have no problems.

>> But nothing beats running natively (on real hardware).
>>
> You're right about that. As Ulrich mentioned earlier, he uses screencast
> software to capture what he's doing. I'm interested in doing the same so
> I think FreeDOS in QEMU on linux is the way to go (for me, at this time).

Who knows, eventually there might be an official Flatpak (or Snappy?)
package that works across all the major distros. I think that will
ease deployment (instead of having billions of separate incompatible
versions).

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi, to bring in some thoughts from off-list...

JEMMEX has a built-in HIMEM which apparently is known to have
problems when memory useable for XMS is discontinuous, which
happens quite often on modern (virtual) hardware.

The UMBPCI author tries hard to keep supporting modern chipsets
which can be interesting if you do not need EMS. As mentioned,
EMS is less popular than XMS anyway.

To stay on the safe side, people should use HIMEMX + JEMM386
or other combinations instead of JEMMEX. Also, they should be
able to understand the conflict potential of UMB and prepare
to manually add X=... areas based on their personal insights.

Having UMB areas conflicting with other things can cause hidden
instabilities: The actual crash may be delayed until you touch
the hardware or BIOS feature which resides in the conflict area
while at the same time having relevant DOS data in the conflict
UMB area at the same place.

I would like to avoid discussions about specific drivers beyond
the core "only use JEMMEX if you know what you are doing, make
HIMEMX and JEMM386 the preferred option" recommendation and a
warm mention of UMBPCI for those who have supported chipsets.

Peace guys :-) Eric



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> I think FreeDOS in QEMU on linux is the way to go (for me, at this time).

Inspired by this thread I also looked into qemu (even installed it on my Mac).

Just in case you missed it: 
There’s a great tutorial about running FreeDOS 1.1 in qemu.
Part three is all about networking. :-)

The author is Patrick G. Horneker.

http://pclosmag.com/html/issues/201206/page08.html 

http://pclosmag.com/html/Issues/201207/page11.html 

http://pclosmag.com/html/issues/201208/page11.html 

http://pclosmag.com/html/Issues/201210/page11.html 



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Hi Rugxulo et al.,

On 6/29/2016 1:03 PM, Rugxulo wrote:
> Hi,
>
> On Wed, Jun 29, 2016 at 10:05 AM, Abe Mishler  wrote:
>>
>> On 6/28/2016 7:55 PM, Rugxulo wrote:
>>>
>>> I would recommend you (also) test under QEMU if you're that worried or
>>> want (potentially) better stability.
>>>
>> QEMU, while about 10x slower (on Win 8.1 amd64 host), ran perfectly.
>> Thank you for the suggestion. Perhaps there are some optimizations that
>> I don't know about...
>
> Not sure about improving speed, esp. on Windows. There used to be
> kqemu for older versions (0.9.0?), but that's been discontinued.
>
On the page that you sent regarding QEMU Binaries for Windows, it says:
"QEMU for Windows is experimental software and might contain even 
serious bugs, so use the binaries at your own risk."

Since QEMU is more mature on linux right now, I installed Xubuntu 16.04 
LTS inside VirtualBox (5.0.24 now) and then QEMU inside of that. FreeDOS 
is much peppier inside of this configuration. I will probably get 
another HD for a native Xubuntu install and skip the VBox on Win 8.1 
layer altogether.

Side note: Since VBox was updated to 5.0.24 during this thread I decided 
to try a new installation of FreeDOS with it but had the same problem.

> Anyways, VBox itself is allegedly partially based upon QEMU, but it's

Yes, the VBox developer FAQ makes that claim:
https://www.virtualbox.org/wiki/Developer_FAQ

> not true that QEMU is always slower. At least one thing I was running
> was faster under QEMU (+ Linux) than VBox (+ Win7), even without VT-X.
> But that could be because of many different reasons. Using VT-X (which
> for QEMU means using KVM variant instead) obviously increases speed
> even further.
>
> But nothing beats running natively (on real hardware).
>
You're right about that. As Ulrich mentioned earlier, he uses screencast 
software to capture what he's doing. I'm interested in doing the same so 
I think FreeDOS in QEMU on linux is the way to go (for me, at this time).

Thanks to everyone for joining the discussion and sharing your knowledge 
with me. I learned a lot and consider my problem resolved. On to the next...

Best,
Abe

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Wed, Jun 29, 2016 at 10:05 AM, Abe Mishler  wrote:
>
> On 6/28/2016 7:55 PM, Rugxulo wrote:
>>
>> I would recommend you (also) test under QEMU if you're that worried or
>> want (potentially) better stability.
>>
> QEMU, while about 10x slower (on Win 8.1 amd64 host), ran perfectly.
> Thank you for the suggestion. Perhaps there are some optimizations that
> I don't know about...

Not sure about improving speed, esp. on Windows. There used to be
kqemu for older versions (0.9.0?), but that's been discontinued.

Anyways, VBox itself is allegedly partially based upon QEMU, but it's
not true that QEMU is always slower. At least one thing I was running
was faster under QEMU (+ Linux) than VBox (+ Win7), even without VT-X.
But that could be because of many different reasons. Using VT-X (which
for QEMU means using KVM variant instead) obviously increases speed
even further.

But nothing beats running natively (on real hardware).

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

On 6/28/2016 7:55 PM, Rugxulo wrote:
> Hi,
>
> On Tue, Jun 28, 2016 at 3:55 PM, Abe Mishler  wrote:
>>
>> Strange, right? And not just on one computer, but three separate ones; each
>> running different hardware and software (host OS). Although I would expect
>> that the underlying differences are abstracted away by VirtualBox.
>
> It's not really that strange. EMS is rarely used nowadays, and DOS (in
> all its billions of setups) isn't highly tested by emulators. Their
> focus is on other, more popular, guests.
>
> It's impossible (or maybe unprofitable) to test every emulator under
> the sun (dozens!), plus having to work around all the bugs and missing
> features. Some OSes present bigger problems than others (OS/2,
> OpenBSD), even requiring VT-X compatible hardware.
>
> I would recommend you (also) test under QEMU if you're that worried or
> want (potentially) better stability. At least Windows (32-bit or
> 64-bit) binaries are easily available below (not to mention that QEMU
> runs on various other host OSes too, e.g. Linux):
>
> http://qemu.weilnetz.de/
>
QEMU, while about 10x slower (on Win 8.1 amd64 host), ran perfectly. 
Thank you for the suggestion. Perhaps there are some optimizations that 
I don't know about...

> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
>

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 29.06.2016 um 13:08 schrieb Don Flowers :
> 
> The only drivers that work for this is Ulrich's FreeDOS 1.0 drivers Himem.exe 
> and "EMM386.EXE NOEMS"

Before someone gets it wrong: The drivers were written by Tom Ehlert, Michael 
Devore and other fine people. Thanks!



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Don Flowers]

I use Novell  Personal Netware for networking with a dedicated server plus
each of 4 other machines acting in SERVER/CLIENT mode

The only drivers that work for this is Ulrich's FreeDOS 1.0 drivers
Himem.exe and "EMM386.EXE NOEMS" (no other switch is necessary). I load DOS
HIGH, UMB.

This gives me between 689 & 717 conventional and 44-46 UMB depending on the
machine. CTMOUSE doesn't like some of my programs so I use a  Logitech
Mouse driver which utilizes high memory on its own. After PNW gets loaded,
I end up with 444-456 conventional with 4k left in UMB plus a reserve EMS
which gets managed by PNW and it own DPMS driver.

On Wed, Jun 29, 2016 at 6:09 AM, Ulrich Hansen  wrote:

> Am 28.06.2016 um 22:55 schrieb Abe Mishler :
>
> >> is pretty unstable, at least for me.
> > It seems like you should be excluding a different region of memory. From
> your screenshot: E300-EDFF.
>
> The packet driver works, but FDAPM is still crashing when I exclude
> E300-EDFF.
>
> >> But the default line didn’t work for you at all. Hmm.
> > Strange, right? And not just on one computer, but three separate ones;
> each running different hardware and software (host OS). Although I would
> expect that the underlying differences are abstracted away by VirtualBox.
>
> I created the VirtualBox „FreeDOS 1.1.net" image in February. Immediately
> five people complained (very politely) about crashes. No boot menu option
> worked that included JEMMEX or JEMM386.
>
> As temporary fix, I replaced JEMMEX with the obsolete HIMEM.EXE and
> EMM386.EXE from FreeDOS 1.0. There has been no complaint since. (The
> "FreeDOS 1.1net" VirtualBox image has been downloaded 815 times in 2016).
>
>
> > Am 29.06.2016 um 00:24 schrieb Eric Auer :
> >
> > To explain the different memory types:
>
> Thank you! Clears things up and refreshes the memory. This should be part
> of the FreeDOS wiki. Reminds me of the time, when I was reading the MS-DOS
> 5.0 manual in 1992. Got my first computer the day before and intended to
> read the manual first. So I sat on a river bench and read about optimizing
> the use of UMBs. :-)
>
> > UMB - provided by EMM386 - lets you load various drivers
> >  high, can also be provided by UMBPCI or other hardware
> >  drivers, can cause stability issues in conflict cases
>
> This is the reason I want some EMM. For DOS networking I need to load
> drivers, especially for MS Client.
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

Am 28.06.2016 um 22:55 schrieb Abe Mishler :

>> is pretty unstable, at least for me.
> It seems like you should be excluding a different region of memory. From your 
> screenshot: E300-EDFF.

The packet driver works, but FDAPM is still crashing when I exclude E300-EDFF.  

>> But the default line didn’t work for you at all. Hmm.
> Strange, right? And not just on one computer, but three separate ones; each 
> running different hardware and software (host OS). Although I would expect 
> that the underlying differences are abstracted away by VirtualBox.

I created the VirtualBox „FreeDOS 1.1.net" image in February. Immediately five 
people complained (very politely) about crashes. No boot menu option worked 
that included JEMMEX or JEMM386.

As temporary fix, I replaced JEMMEX with the obsolete HIMEM.EXE and EMM386.EXE 
from FreeDOS 1.0. There has been no complaint since. (The "FreeDOS 1.1net" 
VirtualBox image has been downloaded 815 times in 2016). 


> Am 29.06.2016 um 00:24 schrieb Eric Auer :
> 
> To explain the different memory types:

Thank you! Clears things up and refreshes the memory. This should be part of 
the FreeDOS wiki. Reminds me of the time, when I was reading the MS-DOS 5.0 
manual in 1992. Got my first computer the day before and intended to read the 
manual first. So I sat on a river bench and read about optimizing the use of 
UMBs. :-)

> UMB - provided by EMM386 - lets you load various drivers
>  high, can also be provided by UMBPCI or other hardware
>  drivers, can cause stability issues in conflict cases

This is the reason I want some EMM. For DOS networking I need to load drivers, 
especially for MS Client.
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Tue, Jun 28, 2016 at 3:55 PM, Abe Mishler  wrote:
>
> Strange, right? And not just on one computer, but three separate ones; each
> running different hardware and software (host OS). Although I would expect
> that the underlying differences are abstracted away by VirtualBox.

It's not really that strange. EMS is rarely used nowadays, and DOS (in
all its billions of setups) isn't highly tested by emulators. Their
focus is on other, more popular, guests.

It's impossible (or maybe unprofitable) to test every emulator under
the sun (dozens!), plus having to work around all the bugs and missing
features. Some OSes present bigger problems than others (OS/2,
OpenBSD), even requiring VT-X compatible hardware.

I would recommend you (also) test under QEMU if you're that worried or
want (potentially) better stability. At least Windows (32-bit or
64-bit) binaries are easily available below (not to mention that QEMU
runs on various other host OSes too, e.g. Linux):

http://qemu.weilnetz.de/

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi Uli and Abe,

indeed it seems like it is not trivial to find the right
excluded areas for UMB to have stability. Having no page
frame is okay - EMS 4 aware software can still use EMS,
only EMS 3 software will miss a frame.

Normally it is enough to have 550k conventional free.

To explain the different memory types:

low DOS memory - the usual 640 kB that you always use,
  where you want to have at least 500 something free.

HMA - provided by HIMEM - lets mainly DOS kernel load high

XMS - provided by HIMEM - lets various DOS programs enjoy
  extra megabytes (ramdisk, dos extenders, caches etc.)

UMB - provided by EMM386 - lets you load various drivers
  high, can also be provided by UMBPCI or other hardware
  drivers, can cause stability issues in conflict cases

EMS - provided by EMM386 or old special hardware - lets
  old DOS programs enjoy some extra memory for page swap
  and extra data storage, not often needed by modern apps

VCPI - provided by EMM386 - lets DOS extenders share the
  protected mode with EMM386, so if you do not load EMM386
  in the first place, you will not need VCPI either. The
  special GEMMIS feature is similar, but for Windows 3.

DPMI - provided by Windows and some DOS extenders - lets
  programs which use DOS extenders share protected mode,
  popular for modern games. Often, games come with their
  own DPMI driver to be able to run outside of Windows,
  using XMS or raw memory in that case.

Raw memory - if you use protected mode "by hand", you can
  of course use all those megabytes outside the first DOS
  megabyte-and-a-bit, too. But using XMS or DPMI often is
  more convenient.

What does this tell you for normal users? You should load
HIMEM for HMA and XMS. If you need space to load drivers
high, you should also use EMM386. The rest will be magic
DOS extender use of whatever suitable memory you have and
only in rare cases you would actually need EMS :-)

Note that HIMEMX and XMGR are like HIMEM and JEMM386 is
like EMM386, while JEMMEX is like both HIMEM and EMM386
combined into a single driver, with some pros and cons.

Regards, Eric



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Guys,

> On Jun 28, 2016, at 3:39 PM, Ulrich Hansen  wrote:
> 
> 
>> Am 28.06.2016 um 21:19 schrieb Ulrich Hansen :
>> 
>> The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
>> JEMMEX options. At least for me. :-)
>> 
>> PCNTPK INT=0x60
> 
> Okay, and FDAPM crashes too. I need to load it into conventional memory as 
> well.
You are running a more advanced FreeDOS configuration than me at the moment. 
Mine is still a vanilla install. Nothing extra.
> 
> All in all it seems your configuration 
> 
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
> 
> 
> is pretty unstable, at least for me.
> 
It seems like you should be excluding a different region of memory. From your 
screenshot: E300-EDFF.

> But the default line didn’t work for you at all. Hmm.
Strange, right? And not just on one computer, but three separate ones; each 
running different hardware and software (host OS). Although I would expect that 
the underlying differences are abstracted away by VirtualBox.

> 
> 
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Tue, Jun 28, 2016 at 12:56 PM, Abe Mishler  wrote:
>
> It's apparent that a well written book might help me come up
> to speed on all of these memory modes and managers.

I'm not an expert, but the simple answer is you don't need all of
them. Pure XMS (and optional DPMI) should suffice for most uses. Don't
overcomplicate it. Don't worry about every feature under the sun
unless an app you want to run direly needs it (unlikely). EMS is quite
old and rare, and even without EMM386, the amount of conventional
memory free should be "good enough" for most existing programs, so you
probably don't need UMBs at all. (But see UMBPCI. Or EMS Magic, which
reuses conventional memory, which is sometimes better for
compatibility.) Besides, you can "JEMM386 LOAD" (and "UNLOAD") later
if you (temporarily) need EMS for something (but not for UMBs).

Somebody, when preparing FD 1.1, was perhaps overzealous for features
when trying to support JEMMEX. But, for the record, VBox is not
necessarily bug-free or a primary target (remember that DOS is meant
for actual native booting, or at least was before UEFI). So yes,
presumably EMM386 (et al.) work better on "real" native hardware than
emulators. That can't be avoided, but perhaps it's not wise to
recommend (or even include) overcomplicated JEMMEX config lines in
future FD versions. (This has been discussed before, so you're not the
first one to notice this hanging VBox + JEMMEX behavior.)

P.S. Emulators are still (usually) run on top of advanced host OSes.
So I'm not sure certain low-level DOS things are directly useful there
(software cache, screen saver, ultra DMA). So I wouldn't worry about
those either.

> My interest is in programming anyways (I'm new to DOS but not programming).
> Any suggestions?

The officially recommended compilers / languages are C (OpenWatcom)
and assembler (NASM). But the DJGPP tree is quite nice too (and
includes barely-related offshoots like Free Pascal, FreeBASIC, and
more). None of these need EMS or UMBs.

So it's unlikely you'll be interested in EMS at all. Stick to real
mode (640 kb) or DPMI (2 GB).

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 28.06.2016 um 21:19 schrieb Ulrich Hansen :
> 
> The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
> JEMMEX options. At least for me. :-)
> 
> PCNTPK INT=0x60

Okay, and FDAPM crashes too. I need to load it into conventional memory as well.

All in all it seems your configuration 

> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG


is pretty unstable, at least for me.

But the default line didn’t work for you at all. Hmm.


--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 28.06.2016 um 20:41 schrieb Ulrich Hansen :
> 
> If I look closely, I find that PCNTPK crashes at boot. So I have no network. 
> No wonder all the memory is free.
> https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory2.png 
> 
> 
> So your solution won’t work for all VirtualBox users…
> I have Version 5.0.14 r105127 running in OS X 10.10.5.

Okay. I also tried it with the new version 5.0.22 but everything’s the same. 
BUT:

The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
JEMMEX options. At least for me. :-)

PCNTPK INT=0x60


--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

Hi Abe (and hi Eric!)

> Am 28.06.2016 um 16:42 schrieb Abe Mishler :
> 
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
> 
> Boot option 1 (http://tinypic.com/r/zm1boj/9 ):
> Total memory Free: 26,699K
> Total Expanded (EMS): 8,576K
> Free Expanded (EMS): 8,192K
> Largest executable program size: 597K
> Largest free upper memory block: 2K


With the FreeDOS 1.1 default line

1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG

I get less free conventional memory:

Boot option 1 
(https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory.png 
)
Total memory Free: 26,682K
Total Expanded (EMS): 8,576K
Free Expanded (EMS): 8,192K
Largest executable program size: 579K
Largest free upper memory block: 2K

If I try your configuration in my FreeDOS 1.1 VirtualBox image I get even 601K 
executable program size BUT:
If I look closely, I find that PCNTPK crashes at boot. So I have no network. No 
wonder all the memory is free.
https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory2.png 


So your solution won’t work for all VirtualBox users…
I have Version 5.0.14 r105127 running in OS X 10.10.5.


PS: I use a screencast software to record boot messages in VBox - otherwise 
they move to quickly to read them.

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

On 6/28/2016 11:08 AM, Eric Auer wrote:
>
> Hi Abe,
>
>> Based on Eric's suggestion of using more cautious settings,
>> I found the JEMMEX doc page
>> (http://help.fdos.org/en/hhstndrd/base/jemmex.htm)
>
> The documentation is also included in your installation on disk.
>
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
>
> You could also try X=TEST Without I=TEST, but excluding C900 to DFFF
> seems to be an even more cautious choice for your specific system.
>
Doing that results in an additional message before crashing so it looks 
like I will have to stick with the specific exclusion.

The additional message:
Warning: no suitable page frame found, EMS functions limited.

>> Boot option 1 no longer crashes, but it doesn't appear to be an
>> improvement over boot option 2...
>
> Option 2 loads SHARE and uses HIMEMX together with JEMM386 instead
> of JEMMEX which combines "HIMEM" and "EMM386" into a single driver.
> Option 2 also moves the PCNTPK network packet driver to UMB, which
> is why you have slightly more "largest executable program size" in
> option 2 compared to option 1 in spite of option 2 loading SHARE.
>
> You can try using LH for PCNTPK, but if you do not use internet in
> DOS, you could simply comment out the whole line that loads PCNTPK.
>
> If you only use EMS-aware software which is EMS 4.0 compatible,
> you can disable EMS 3.2 compatible page frames with some option
> for JEMMEX and JEMM386: That way, you get 64 kB extra space for
> UMB use, so it will be easier to LH things and gain low space.
>
> I think today EMM386 is more often used for UMB and less often
> for EMS. If you only use UMB but do not need EMS at all, you
> can also disable EMS 3.2 compatible page frames, of course :-)
>
>> Boot option 1 (http://tinypic.com/r/zm1boj/9): [JEMMEX]
>> Total memory Free: 26,699K
>> Total Expanded (EMS): 8,576K
>> Free Expanded (EMS): 8,192K
>> Largest executable program size: 597K
>> Largest free upper memory block: 2K
>
>> Boot option 2 (http://tinypic.com/r/2zzjl77/9): [HIMEMX+JEMM386]
>> Total memory Free: 26,669K
>> Total Expanded (EMS): 31M
>
> Interesting that JEMM386 defaults to offer more EMS than JEMMEX.
>
>> Free Expanded (EMS): 25M
>
> Odd, what happened to the other 6 MB of EMS?
>
I was wondering that myself...

>> Largest executable program size: 610K
>
> This is because that option loads SHARE & network drivers high.
>
>> Largest free upper memory block: 4K
>
> This is interesting: In spite of loading more things into UMB,
> you have more UMB left. That MIGHT mean that option 2 does not
> have the X=C900-DFFF option but still is lucky enough to avoid
> a crash? It could already be unstable, though. Maybe it would
> still crash as soon as you use the network in DOS.
>
Right, I didn't block that region in option 2. I used networking with 
option 2 to install the VBOX-FIX COM patch earlier. I didn't experience 
a crash. Perhaps I was "lucky". What's interesting is that there is no 
delay loading the UIDE driver so maybe Oracle has fixed the bus scan 
problem with VirtualBox rendering the patch unnecessary. Perhaps someone 
else can duplicate these results and confirm.

> ALSO, the option 2 takes the "dangerous" step of explicitly
> including the monochrome graphics card text memory area as
> UMB memory (I=B000-B7FF). This means that attempts to use a
> program which uses monochrome video modes may cause crashes.
> It could also be the real reason why more UMB is free there.
>
I was going to use option 2 even after all of this, but I will remain 
with option 1 now that it works; especially since you have indicated 
twice now that option 2 might be unstable. Thanks for that insight.

> I think that even 597 kB of low DOS memory is plenty for old
> DOS programs. New DOS programs use a DOS extender anyway, so
> they will be able to use your EMS and XMS, which are several
> megabytes. You can use other MEM command line options to see
> more details. Check the output of "MEM /?" to learn more :-)
>
> Regards, Eric
>
> PS: Do you use a special MOUSE or the usual CTMOUSE driver?
>
I have not installed a mouse driver or configured the mouse in any way. 
My AUTOEXEC.BAT has the standard "MOUSE" command in it.

> PPS: I see 1.1 uses XMGR in option 3 and 4DOS in option 4,
> not sure if those are included in the 1.2 distro any more.
>
For the record it looks like 4DOS is also in option 3, but thanks for 
the info. It's apparent that a well written book might help me come up 
to speed on all of these memory modes and managers. My interest is in 
programming anyways (I'm new to DOS but not programming). Any suggestions?
>
Thanks,
Abe

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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 informat

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi Abe,

> Based on Eric's suggestion of using more cautious settings,
> I found the JEMMEX doc page
> (http://help.fdos.org/en/hhstndrd/base/jemmex.htm)

The documentation is also included in your installation on disk.

> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG

You could also try X=TEST Without I=TEST, but excluding C900 to DFFF
seems to be an even more cautious choice for your specific system.

> Boot option 1 no longer crashes, but it doesn't appear to be an 
> improvement over boot option 2...

Option 2 loads SHARE and uses HIMEMX together with JEMM386 instead
of JEMMEX which combines "HIMEM" and "EMM386" into a single driver.
Option 2 also moves the PCNTPK network packet driver to UMB, which
is why you have slightly more "largest executable program size" in
option 2 compared to option 1 in spite of option 2 loading SHARE.

You can try using LH for PCNTPK, but if you do not use internet in
DOS, you could simply comment out the whole line that loads PCNTPK.

If you only use EMS-aware software which is EMS 4.0 compatible,
you can disable EMS 3.2 compatible page frames with some option
for JEMMEX and JEMM386: That way, you get 64 kB extra space for
UMB use, so it will be easier to LH things and gain low space.

I think today EMM386 is more often used for UMB and less often
for EMS. If you only use UMB but do not need EMS at all, you
can also disable EMS 3.2 compatible page frames, of course :-)

> Boot option 1 (http://tinypic.com/r/zm1boj/9): [JEMMEX]
> Total memory Free: 26,699K
> Total Expanded (EMS): 8,576K
> Free Expanded (EMS): 8,192K
> Largest executable program size: 597K
> Largest free upper memory block: 2K

> Boot option 2 (http://tinypic.com/r/2zzjl77/9): [HIMEMX+JEMM386]
> Total memory Free: 26,669K
> Total Expanded (EMS): 31M

Interesting that JEMM386 defaults to offer more EMS than JEMMEX.

> Free Expanded (EMS): 25M

Odd, what happened to the other 6 MB of EMS?

> Largest executable program size: 610K

This is because that option loads SHARE & network drivers high.

> Largest free upper memory block: 4K

This is interesting: In spite of loading more things into UMB,
you have more UMB left. That MIGHT mean that option 2 does not
have the X=C900-DFFF option but still is lucky enough to avoid
a crash? It could already be unstable, though. Maybe it would
still crash as soon as you use the network in DOS.

ALSO, the option 2 takes the "dangerous" step of explicitly
including the monochrome graphics card text memory area as
UMB memory (I=B000-B7FF). This means that attempts to use a
program which uses monochrome video modes may cause crashes.
It could also be the real reason why more UMB is free there.

I think that even 597 kB of low DOS memory is plenty for old
DOS programs. New DOS programs use a DOS extender anyway, so
they will be able to use your EMS and XMS, which are several
megabytes. You can use other MEM command line options to see
more details. Check the output of "MEM /?" to learn more :-)

Regards, Eric

PS: Do you use a special MOUSE or the usual CTMOUSE driver?

PPS: I see 1.1 uses XMGR in option 3 and 4DOS in option 4,
not sure if those are included in the 1.2 distro any more.



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Hi Ulrich,

Thanks for the link. I compared the 2 files and didn't find anything of 
significance. Your change:

IF "%config%"=="2" PCNTPK INT=0x60
IF NOT "%config%"=="2" LH PCNTPK INT=0x60

seems smart, however.

Based on Eric's suggestion of using more cautious settings, I found the 
JEMMEX doc page
(http://help.fdos.org/en/hhstndrd/base/jemmex.htm)

and learned how to change the JEMMEX options. I excluded the region of 
memory that might already be in use (indicated in the original error 
message):
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG

Boot option 1 no longer crashes, but it doesn't appear to be an 
improvement over boot option 2. Here is what I am getting from C:\mem 
after boot:

Boot option 1 (http://tinypic.com/r/zm1boj/9):
Total memory Free: 26,699K
Total Expanded (EMS): 8,576K
Free Expanded (EMS): 8,192K
Largest executable program size: 597K
Largest free upper memory block: 2K

Boot option 2 (http://tinypic.com/r/2zzjl77/9):
Total memory Free: 26,669K
Total Expanded (EMS): 31M
Free Expanded (EMS): 25M
Largest executable program size: 610K
Largest free upper memory block: 4K

I don't have much experience with the way DOS memory works. What do you 
think of these results? Anything else I should be looking at?

Thanks,
Abe

On 6/27/2016 8:23 PM, Ulrich Hansen wrote:
> Hi Abe,
>
> if you like, take a look at:
>
> https://www.lazybrowndog.net/freedos/virtualbox
>
> There are three VirtualBox images of FreeDOS 1.1.
>
> I put quite some effort in them to make them work. I remember the crash
> you are talking about, but, sorry, I don’t remember how I fixed it
> (wasn’t it something about not loading high something?? Very sorry.
> Maybe you compare the AUTOEXEC.BAT and FDCONFIG.SYS of the FreeDOS 1.1
> VirtualBox image?
>
> -
> AUTOEXEC.BAT
>
> @echo off
> SET LANG=EN
> SET MTCPCFG=C:\FDOS\MTCP.CFG
> SET WATTCP.CFG=C:\FDOS
> SET PATH=%dosdir%\BIN;C:\DOSZIP
> SET NLSPATH=%dosdir%\NLS
> SET HELPPATH=%dosdir%\HELP
> SET TEMP=%dosdir%\TEMP
> SET TMP=%TEMP%
> SET BLASTER=A220 I5 D1 H5 P330
> SET DIRCMD=/P /OGN /4
> SET COPYCMD=/-Y
> if "%config%"=="4" goto end
> SHSUCDX /QQ /D3
> LH SHSUCDHD /QQ /F:FDBOOTCD.ISO
> LH FDAPM APMDOS
> IF "%config%"=="2" LH SHARE
> LH DOSLFN
> REM NLSFUNC C:\FDOS\BIN\COUNTRY.SYS
> REM DISPLAY CON=(EGA),858,2)
> REM MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX)
> REM KEYB US,858,C:\FDOS\bin\keyboard.sys
> REM KEYB GR,,keyboard.sys /NOHI
> REM CHCP 858
> IF "%config%"=="2" PCNTPK INT=0x60
> IF NOT "%config%"=="2" LH PCNTPK INT=0x60
> DHCP
> REM M2WAT.COM  transfers the mTCP configuration to
> WATTCP.CFG.
> REM Disable it, if you want to use a custom WATTCP.CFG.
> C:\FDOS\M2WAT.COM 
> MOUSE
> DEVLOAD /H /Q %dosdir%\BIN\UIDE.SYS /H /D:FDCD0001 /S5
> SHSUCDX /QQ /~ /D:?SHSU-CDR,D /D:?SHSU-CDH,D /D:?FDCD0001,D
> /D:?FDCD0002,D /D:?FDCD0003,D
> MEM /C /N
> IF NOT "%config%"=="4" SHSUCDX /D
> GOTO END
> :END
> SET AUTOFILE=%0
> SET CFGFILE=C:\FDCONFIG.SYS
> alias reboot=fdapm warmboot
> alias reset=fdisk /reboot
> alias halt=fdapm poweroff
> alias shutdown=fdapm poweroff
> alias cfg=edit %cfgfile%
> alias auto=edit %0
> echo Done processing startup files %cfgfile% and %0
> echo Type HELP to get support on commands and navigation
> echo.
> echo Welcome to the FreeDOS 1.1 operating system (http://www.freedos.org)
>
>
> -
> FDCONFIG.SYS
>
> !COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
> !SET DOSDIR=C:\FDOS
> !LASTDRIVE=Z
> !BUFFERS=20
> !FILES=40
> !MENUCOLOR=7,0
> MENUDEFAULT=1,5
> MENU 1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free
> MENU 2 - Load FreeDOS with EMM386 (Expanded Memory) and SHARE loaded
> MENU 3 - Load FreeDOS including XMGR XMS-memory driver
> MENU 4 - Load FreeDOS without drivers
> 123?DOS=HIGH
> 12?DOS=UMB
> 12?DOSDATA=UMB
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
> 3?DEVICE=C:\FDOS\BIN\XMGR.SYS
> 3?SHELL=C:\FDOS\bin\4dos.com  C:\FDOS\bin /E:1024
> /P:C:\AUTOEXEC.BAT
> 4?SHELL=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN /E:1024
> /P=C:\AUTOEXEC.BAT
> 12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN
> /E:1024 /P=C:\AUTOEXEC.BAT
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
> 

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

Hi Abe,

if you like, take a look at:

https://www.lazybrowndog.net/freedos/virtualbox 


There are three VirtualBox images of FreeDOS 1.1. 

I put quite some effort in them to make them work. I remember the crash you are 
talking about, but, sorry, I don’t remember how I fixed it (wasn’t it something 
about not loading high something?? Very sorry. Maybe you compare the 
AUTOEXEC.BAT and FDCONFIG.SYS of the FreeDOS 1.1 VirtualBox image?

-
AUTOEXEC.BAT

@echo off
SET LANG=EN
SET MTCPCFG=C:\FDOS\MTCP.CFG
SET WATTCP.CFG=C:\FDOS
SET PATH=%dosdir%\BIN;C:\DOSZIP
SET NLSPATH=%dosdir%\NLS
SET HELPPATH=%dosdir%\HELP
SET TEMP=%dosdir%\TEMP
SET TMP=%TEMP%
SET BLASTER=A220 I5 D1 H5 P330
SET DIRCMD=/P /OGN /4
SET COPYCMD=/-Y
if "%config%"=="4" goto end
SHSUCDX /QQ /D3
LH SHSUCDHD /QQ /F:FDBOOTCD.ISO
LH FDAPM APMDOS
IF "%config%"=="2" LH SHARE
LH DOSLFN
REM NLSFUNC C:\FDOS\BIN\COUNTRY.SYS
REM DISPLAY CON=(EGA),858,2)
REM MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX)
REM KEYB US,858,C:\FDOS\bin\keyboard.sys
REM KEYB GR,,keyboard.sys /NOHI
REM CHCP 858
IF "%config%"=="2" PCNTPK INT=0x60
IF NOT "%config%"=="2" LH PCNTPK INT=0x60
DHCP
REM M2WAT.COM  transfers the mTCP configuration to 
WATTCP.CFG.
REM Disable it, if you want to use a custom WATTCP.CFG.
C:\FDOS\M2WAT.COM 
MOUSE
DEVLOAD /H /Q %dosdir%\BIN\UIDE.SYS /H /D:FDCD0001 /S5
SHSUCDX /QQ /~ /D:?SHSU-CDR,D /D:?SHSU-CDH,D /D:?FDCD0001,D /D:?FDCD0002,D 
/D:?FDCD0003,D
MEM /C /N
IF NOT "%config%"=="4" SHSUCDX /D
GOTO END
:END
SET AUTOFILE=%0
SET CFGFILE=C:\FDCONFIG.SYS
alias reboot=fdapm warmboot
alias reset=fdisk /reboot
alias halt=fdapm poweroff
alias shutdown=fdapm poweroff
alias cfg=edit %cfgfile%
alias auto=edit %0
echo Done processing startup files %cfgfile% and %0
echo Type HELP to get support on commands and navigation
echo.
echo Welcome to the FreeDOS 1.1 operating system (http://www.freedos.org 
)


-
FDCONFIG.SYS

!COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS 
!SET DOSDIR=C:\FDOS
!LASTDRIVE=Z
!BUFFERS=20 
!FILES=40
!MENUCOLOR=7,0
MENUDEFAULT=1,5
MENU 1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free
MENU 2 - Load FreeDOS with EMM386 (Expanded Memory) and SHARE loaded
MENU 3 - Load FreeDOS including XMGR XMS-memory driver
MENU 4 - Load FreeDOS without drivers 
123?DOS=HIGH
12?DOS=UMB
12?DOSDATA=UMB
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE 
2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
3?DEVICE=C:\FDOS\BIN\XMGR.SYS 
3?SHELL=C:\FDOS\bin\4dos.com  C:\FDOS\bin /E:1024 
/P:C:\AUTOEXEC.BAT  
4?SHELL=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN /E:1024 
/P=C:\AUTOEXEC.BAT 
12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN /E:1024 
/P=C:\AUTOEXEC.BAT --
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Eric,

Thanks for your time and attention. See my responses inline.

On 6/27/2016 3:05 PM, Eric Auer wrote:
>
> Hi Abe,
>
>> upon bootup and selecting option 1, I get the following message:
>>
>> JemmEx v5.75 [05/21/11]
>> System memory found at c900-dfff, region might be in use
>> JemmEx loaded
>> Kernel: allocated 46 Diskbuffers = 24472 Bytes in HMA
>>
>> after which nothing ever happens. It hangs permanently.
>
> This means that JEMMEX (EMM386) tried to allocate UMB but
> predicted troubles. Soon after that, DOS does indeed hang.
> I suggest to select a boot option without JEMMEX instead.
>
I understood JEMMEX to be the preferred option. Yes, the other boot 
options all work.

> Alternatively, you could change the JEMMEX options in your
> config.sys to more cautious settings regarding UMB areas.
> Then you get at least some UMB and thus more free DOS RAM.
>
Can you point me in the direction of a good resource where I could learn 
about adjusting the JEMMEX options/settings?

Why are the JEMMEX defaults not set to work with a 
fresh install? Or does it work for most people, and my 3 computers just 
happen to all not work?

>> I don't believe this is related to the UIDE driver...
>
> It is possible that the same memory area where JEMMEX tries
> to allocate UMB is also in use for disk, network or UMB I/O
> buffers of your virtual hardware... So it is possible that a
> crash is more likely with UIDE (more modern disk I/O) but a
> better solution compared to avoiding UIDE would be to select
> more cautious JEMMEX options regarding that memory region.
>
Perhaps I should allocate more than 32MB of RAM to avoid this collision? 
I will try that too.

>> Boot options 2,3,4 all work without issue.
>
> What are the names of boot options 1, 2, 3 and 4 respectively?
>
They are the stock options found in the C:\FDCONFIG.SYS file:

1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free
2 - Load FreeDOS with EMM386 (Expanded Memory) and SHARE loaded
3 - Load FreeDOS including XMGR XMS-memory driver
4 - Load FreeDOS without drivers

I have not altered C:\FDCONFIG.SYS.

> Regards, Eric
>
Thanks again
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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
>

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi Abe,

> upon bootup and selecting option 1, I get the following message:
> 
> JemmEx v5.75 [05/21/11]
> System memory found at c900-dfff, region might be in use
> JemmEx loaded
> Kernel: allocated 46 Diskbuffers = 24472 Bytes in HMA
> 
> after which nothing ever happens. It hangs permanently.

This means that JEMMEX (EMM386) tried to allocate UMB but
predicted troubles. Soon after that, DOS does indeed hang.
I suggest to select a boot option without JEMMEX instead.

Alternatively, you could change the JEMMEX options in your
config.sys to more cautious settings regarding UMB areas.
Then you get at least some UMB and thus more free DOS RAM.

> I don't believe this is related to the UIDE driver...

It is possible that the same memory area where JEMMEX tries
to allocate UMB is also in use for disk, network or UMB I/O
buffers of your virtual hardware... So it is possible that a
crash is more likely with UIDE (more modern disk I/O) but a
better solution compared to avoiding UIDE would be to select
more cautious JEMMEX options regarding that memory region.

> Boot options 2,3,4 all work without issue.

What are the names of boot options 1, 2, 3 and 4 respectively?

Regards, Eric



--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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

[Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Dear List,

I've attempted to install FreeDOS 1.1 using VirtualBox 5.0.22 on 3 
different machines with 3 different operating systems: (Macbook Pro 
(10.11.5), Windows 8.1 Home, and Windows 10 Pro). On each system, upon 
bootup and selecting option 1, I get the following message:

JemmEx v5.75 [05/21/11]
System memory found at c900-dfff, region might be in use
JemmEx loaded
Kernel: allocated 46 Diskbuffers = 24472 Bytes in HMA

after which nothing ever happens. It hangs permanently. I don't believe 
this is related to the UIDE driver as suggested in the installation Wiki 
pages because of where it freezes. Regardless, I installed the VBOX-FIX 
COM patch on the Windows 10 Pro setup and it didn't solve the problem.

Boot options 2,3,4 all work without issue.

Has anyone else run into this? Your help in understanding (& fixing!) 
this is greatly appreciated.

Thanks,
Abe

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] FreeDOS 1.1 Bootable USB Image

[Rugxulo]

Hi,

On Thu, Jun 11, 2015 at 1:00 PM, Christian Imhorst
 wrote:
>
> I am still a fan of a FD 1.1 bootable USB image. By this time I use
> Qemu to build one, too. It is much easier to make the image bootable
> with Qemu than with Grub4DOS or Syslinux.

QEMU is pretty great but a bit fractured.

The newest I can (successfully) compile on my old Lucid Puppy Linux is
2.1.3. I'm still using 2.2.0 on my laptop and desktop under Windows
(from http://qemu.weilnetz.de ). IIRC, his newer 2.3.0 build for
Windows (accidentally??) broke "pcnet", so I don't use that one.
(Reported a bug but haven't heard back.) My Ubuntu 14.04.2 (Trusty
Tahr) jump drive only has 2.0.0, but it works, even (optionally) KVM
on my main desktop.

> Today I wear an USB stick together with my key ring with a bootable
> FD 1.1 image. I have created this image with Qemu and use some stuff
> like FDNPKG, the latest MPXPLAY and ideas from METADOS for my FreeDOS
> to go.

Mpxplay doesn't reliably work on most of my machines. Though I'm no
multimedia fiend, so I don't majorly care.

FDNPKG is a great idea, but we need more package(r)s. Well, I did try
to install something from there yesterday (under QEMU to RAM disk),
but it seemed to expect "c:\games" hardcoded. (Maybe I'm wrong?) Meh.

MetaDOS 0.1 is still on iBiblio, but it's extremely weak. I've been
heavily working on a much-improved 0.2, which is much more useful (to
me). It's almost finished (though I've been saying that for weeks).
The 0.1 release was just a very rough proof of concept. I don't know
if anyone else will appreciate it, though, but hey I tried.

I've tested this newer 0.2 on both floppy and USB (basically atop the
minimal RUFUS install) on my old P4 (RTSPKT) and (preferred) under
aforementioned emulators.

> And if I need new things on this image I boot FreeDOS on the
> stick with Qemu. In this way I can use Internet to load new stuff over
> FDNPKG on the stick. Another possibility is to put the stick into the
> USB port of my Linux computer just to copy stuff on this stick with a
> terminal or a file manager. And to use FreeDOS to go I can easily boot
> the stick with a computer.

I automated a ton of stuff in the new release. Most of it is grabbed
via either FTP or Wget (which itself is grabbed via FTP, initially, if
needed!).

It doesn't rely on FDNPKG at all. Granted, I like FDNPKG, but you have
to package things a very specific way first, and that's very tedious.

> For the near future I like to build a FD 1.1 emulator like the ready
> to use Raspberry Pi emulator package for Windows:
>
> http://sourceforge.net/projects/rpiqemuwindows/
>
> So that you can easy run FD 1.1 with Qemu on Windows by executing a
> run.bat. For Linux users like me I would put a run.sh into the ZIP
> file, too, but Qemu executables just for the Windows users. :-)

I did make a "run-qemu.bat" in this new release (although I also
heavily test under VBox, which works with VT-X on my main desktop). If
you want, I'll email it to you, but it's nothing hugely remarkable.
BTW, like I said, I mainly test 2.2.0 on Windows, but I still have
0.13.50 (and even 0.9.0 on my laptop), so they all work reasonably
okay. I don't personally want the hassle of recompiling QEMU myself,
though, or lugging around full sources, so I haven't. I just assume
everyone can find it on their own.

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

Re: [Freedos-user] FreeDOS 1.1 Bootable USB Image

[Christian Imhorst]

Hi Rugxulo,

I am still a fan of a FD 1.1 bootable USB image. By this time I use
Qemu to build one, too. It is much easier to make the image bootable
with Qemu than with Grub4DOS or Syslinux. 

Today I wear an USB stick together with my key ring with a bootable
FD 1.1 image. I have created this image with Qemu and use some stuff
like FDNPKG, the latest MPXPLAY and ideas from METADOS for my FreeDOS
to go. And if I need new things on this image I boot FreeDOS on the
stick with Qemu. In this way I can use Internet to load new stuff over
FDNPKG on the stick. Another possibility is to put the stick into the
USB port of my Linux computer just to copy stuff on this stick with a
terminal or a file manager. And to use FreeDOS to go I can easily boot
the stick with a computer.

For the near future I like to build a FD 1.1 emulator like the ready
to use Raspberry Pi emulator package for Windows:

http://sourceforge.net/projects/rpiqemuwindows/

So that you can easy run FD 1.1 with Qemu on Windows by executing a
run.bat. For Linux users like me I would put a run.sh into the ZIP
file, too, but Qemu executables just for the Windows users. :-)

Kind regards

Christian  







Am Wed, 10 Jun 2015 13:38:30 -0500
schrieb Rugxulo :

> Hi,
> 
> I somehow stumbled upon this blog/website which seems to host a FD 1.1
> bootable USB image (and tells steps on how to make/install it ... with
> screenshots!).
> 
> http://joelinoff.com/blog/?p=431
> 
> Maybe I missed it, but I'm not sure if any of us directly discussed
> this before, so I'm mentioning it here, in case anyone else finds it
> interesting.
> 
> I do vaguely remember Christian Imhorst discussing something similar a
> year or so ago. Lemme find the link 
> 
> "[Freedos-user] Is anyone installed FreeDOS from USB CD drive or other
> USB device?" (Sat, 23 Aug 2014)
> 
> https://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg15388.html
> 
> I heavily prefer RUFUS (which is "Windows only", IIRC), but it's still
> good to see an alternative.
> 
> P.S. Should this .ZIP be mirrored to iBiblio for us?
> 
> --
> ___
> 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

[Freedos-user] FreeDOS 1.1 Bootable USB Image

[Rugxulo]

Hi,

I somehow stumbled upon this blog/website which seems to host a FD 1.1
bootable USB image (and tells steps on how to make/install it ... with
screenshots!).

http://joelinoff.com/blog/?p=431

Maybe I missed it, but I'm not sure if any of us directly discussed
this before, so I'm mentioning it here, in case anyone else finds it
interesting.

I do vaguely remember Christian Imhorst discussing something similar a
year or so ago. Lemme find the link 

"[Freedos-user] Is anyone installed FreeDOS from USB CD drive or other
USB device?" (Sat, 23 Aug 2014)

https://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg15388.html

I heavily prefer RUFUS (which is "Windows only", IIRC), but it's still
good to see an alternative.

P.S. Should this .ZIP be mirrored to iBiblio for us?

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

Re: [Freedos-user] freedos 1.1 and xen

[Rugxulo]

Hi,

On Tue, Sep 30, 2014 at 7:22 PM, wch-t...@house-grp.net
 wrote:
>
> I have a host machine (Dom0) running OpenSUSE xen kernel version
> 3.11.10-21.1.

I applaud you for trying such an emulator with FreeDOS. Even I don't
have the energy to try every emulator under the sun anymore.

> I am using the xl tool stack to the extent I can. I have installed freedos as 
> a guest.
>
> I am encountering errors such as
>
> "Error reading from drive C: DOS area: write-protection violation attempted
> (A)bort, (I)gnore, (R)etry, (F)ail?"

Probably unrelated, but I sometimes get a critical error when doing
tab completion under FreeCOM (0.84-pre2 XMS_Swap) with DOSLFN enabled.
I don't know the details, but I vaguely assumed it was because there
is no physical A: drive on this PC. I think I even get it with DOSEMU.

Maybe I'm totally wrong, but I never knew really how to debug or
isolate it, so I just ignored it. I'm no kernel guru, so I have no
idea. Maybe it's actually a shell (FreeCOM) bug. Obviously plugging in
a USB floppy drive (which I have) could maybe prove it (if the error
goes away), but I've never been that interested these days. (Which is
saying a lot because I care more about floppies than 99% of people.)

I know that's not directly helpful, but that's my first (naive) guess,
though probably wrong.

> immediately after boot but a C prompt eventually comes up after a few "A"s.
>
> I have an MSDos 6.22  vm which runs without complaint.

It could just be that MS-DOS ignores it entirely, i.e. silently fails.
Though more likely, you're correct, it's probably a rare FreeDOS bug.

You could try a different FreeDOS kernel (e.g. 2036 or 2038) and/or a
different shell (0.82pl3 or 4DOS). If it's still a bug, at least
you've confirmed that it's not unique to what you have now.

http://sourceforge.net/projects/freedos/files/Kernel/
http://sourceforge.net/projects/freedos/files/FreeCOM/082pl3%20%28use%20xmsswap%20for%20386%2B%20PC%29/

BTW, some emulators are just buggy. Most people, even developers,
don't seem to test very well except with a limited number of modern
OSes, usually Windows or Linux. So it's not true that it couldn't be
Xen's fault.

> The xl configuration files are almost identical.  Here is the freedos config
> file:
>
> boot = "cd"
> disk = [ "file:/v/v.../freedos_1.1_n01-hda.raw,hda,w",
> "file:/v/../freedos_1.1_src.iso,hdc:cdrom,r" ]

I'm not much help here. I don't know what any of this means. While I
am on Linux now, it's an old PuppyLinux (Lucid, aka 10.04 or such), so
I don't probably have a good way to install or build latest Xen to
test.

Maybe someone else will chime in, so I'll put this link here:

http://www.xenproject.org/help/documentation.html

> This is the type of error I would see on a damaged floppy drive or one with
> the write protection slot covered, or on a failing/failed C drive; but
> freedos installed on this image file without any trouble (after I got the
> order of operations right).

So this error is on every boot, after AUTOEXEC has finished running?

> If images are permitted, I can send a screen shot of the display.

Dunno about images being allowed. Probably better to host them
elsewhere and link to them indirectly.

> Since
> 1) I am running as root (and therefore should not encounter any
> permissions problems) and
> 2) MSDos runs without trouble and
> 3) freedos installed and is obviously running
>
> I am assuming xen is OK and that my configuration file is OK, but could I
> have a timing issue?
>
> Is the CPU too fast? ( I-7 @ 2200GHz)I have seen some notes which mentioned
> throttling back a cpu.  I tried caping the CPU at 20% which did not seem to
> help.

Dunno. It's probably not a timing issue, but I think FreeCOM does try
to do something weird for the internal BEEP command. So who knows,
anything's possible.

> If someone has some idea as to the cause of and cure for this behavior, I
> would like them to share it with me.

I don't hold much hope for getting much sympathy upstream, but if
you're courageous enough, you could visit their IRC and ask someone
there.

http://xenproject.org/irc.html

--
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=154622311&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] freedos 1.1 and xen

[wch-t...@house-grp.net]

Hello,

I have a host machine (Dom0) running OpenSUSE xen kernel version 3.11.10-21.1.

I am using the xl tool stack to the extent I can.

I have installed freedos as a guest.

I am encountering errors such as

"Error reading from drive C: DOS area: write-protection violation attempted
(A)bort, (I)gnore, (R)etry, (F)ail?"

immediately after boot but a C prompt eventually comes up after a few "A"s.

I have an MSDos 6.22  vm which runs without complaint.

The xl configuration files are almost identical.  Here is the freedos config
file:

code

name = "freedos_1.1_n01"
uuid = "11071171-4e33-4182-8ff7-e1d3bbe80928"
#
maxmem = 512
memory = 512
vcpus = 1
#
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "destroy"
#
localtime = 0
keymap = "en-us"
builder = "hvm"
#device_model = "/usr/lib/xen/bin/qemu-system-i386"
#kernel = "/usr/lib/xen/boot/hvmloader"
boot = "cd"
disk = [ "file:/v/v.../freedos_1.1_n01-hda.raw,hda,w",
"file:/v/../freedos_1.1_src.iso,hdc:cdrom,r" ]
#
vif = [ "bridge=virbr0,ip=192..03,mac=00...e" ]
#

pae = 1
acpi = 1
apic = 1
#
#
vnc = 1
vncunused = 1
#
serial = "none"
parallel = "none"
soundhw = "sb16"
#
stdvga = 0
endcode


This is the type of error I would see on a damaged floppy drive or one with the
write protection slot covered, or on a failing/failed C drive; but freedos
installed on this image file without any trouble (after I got the order of
operations right).

If images are permitted, I can send a screen shot of the display.

Since
1) I am running as root (and therefore should not encounter any permissions
problems) and
2) MSDos runs without trouble and
3) freedos installed and is obviously running

I am assuming xen is OK and that my configuration file is OK, but could I have a
timing issue?

Is the CPU too fast? ( I-7 @ 2200GHz)I have seen some notes which mentioned
throttling back a cpu.  I tried caping the CPU at 20% which did not seem to
help.

If someone has some idea as to the cause of and cure for this behavior, I would
like them to share it with me.

TKA

Bill












--
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=154622311&iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 install

[Felix Miata]

On 2013-02-09 10:56 (GMT-0800) Ray Davison composed:

> A little background.  My first PC ran DOS 3.3 on a 28M HDD that I broke
> into three partitions, all primaries.  Since the extended came out every
> machine I have had has had a single primary - 2G or less, Fat 16 - with
> one or more installs of DOS and maybe Win9X.  The rest of the drive, and
> any other drives have been a single extended, which carried whatever GUI
> OSs I was running as well as apps and data.

> I just took a fresh HDD, created a 2G, primary at the front, and for the
> first time ever, that partition is FAT32.  I then created several fat32
> logicals.

> I ran the 1.1 CD.  When I got to the MBR selection at the end I selected
> the boot loader.  Boot yields "non system disk".

> Ran CD again.  Selected make floppy.  Nothing was written to the disk.

> Ran CD again.  Selected write FreeDOS to MBR.  Boot is OK.

> Should the boot loader and floppy selections be expected to work?

I haven't done FD installation in quite a while, so don't remember a lot. 
What I do remember is never being able to write a floppy until after booting 
the installed system. In thinking about it now I wonder if it's an A: vs. B: 
problem of some kind stemming from CD installation boot as A:?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

   Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 install

[dos386]

I usually don't use the installers, try to install manually:

- Copy KERNEL.SYS + FREECOM.COM + SYS.COM + WDE.COM
- Backup B.S. with WDE
- SYS C: /BOOTONLY




On 2/9/13, Ray Davison  wrote:
> A little background.  My first PC ran DOS 3.3 on a 28M HDD that I broke
> into three partitions, all primaries.  Since the extended came out every
> machine I have had has had a single primary - 2G or less, Fat 16 - with
> one or more installs of DOS and maybe Win9X.  The rest of the drive, and
> any other drives have been a single extended, which carried whatever GUI
> OSs I was running as well as apps and data.
>
> I just took a fresh HDD, created a 2G, primary at the front, and for the
> first time ever, that partition is FAT32.  I then created several fat32
> logicals.
>
> I ran the 1.1 CD.  When I got to the MBR selection at the end I selected
> the boot loader.  Boot yields "non system disk".
>
> Ran CD again.  Selected make floppy.  Nothing was written to the disk.
>
> Ran CD again.  Selected write FreeDOS to MBR.  Boot is OK.
>
> Should the boot loader and floppy selections be expected to work?
>
> TY
> Ray
>
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FreeDOS 1.1 install

[Ray Davison]

A little background.  My first PC ran DOS 3.3 on a 28M HDD that I broke 
into three partitions, all primaries.  Since the extended came out every 
machine I have had has had a single primary - 2G or less, Fat 16 - with 
one or more installs of DOS and maybe Win9X.  The rest of the drive, and 
any other drives have been a single extended, which carried whatever GUI 
OSs I was running as well as apps and data.

I just took a fresh HDD, created a 2G, primary at the front, and for the 
first time ever, that partition is FAT32.  I then created several fat32 
logicals.

I ran the 1.1 CD.  When I got to the MBR selection at the end I selected 
the boot loader.  Boot yields "non system disk".

Ran CD again.  Selected make floppy.  Nothing was written to the disk.

Ran CD again.  Selected write FreeDOS to MBR.  Boot is OK.

Should the boot loader and floppy selections be expected to work?

TY
Ray

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Ulrich Hansen]

Am 18.06.2012 um 22:15 schrieb Aitor Santamaría:
>  I suspect JEMM may make the DOS' memory allocation strategy functions less 
> robust than they are with other DOSes. 

For what it's worth: The problem doesn't occur with JEMMEX v5.61 and started to 
occur in JEMMEX v5.62 and all following versions.

v5.62 is just 8 bytes bigger than v5.61 so it should be possible to solve this.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Ulrich Hansen]

Am 18.06.2012 um 22:15 schrieb Aitor Santamaría:

> There were in the past conflicts with KEYB 2.00 and JEMM that were apparently 
> solved with KEYB 2.01.
> The NOHI option mostly controlls KEYB access to XMS, but reading this thread, 
> and knowing what I fixed 2.00 to 2.01, I suspect JEMM may make the DOS' 
> memory allocation strategy functions less robust than they are with other 
> DOSes. 
> In case it helps JEMM...

Thanks for looking into this. There is also a page in the FreeDOS wiki about 
the problem:
http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9

As I wrote, KEYB v2.01 and JEMMEX v5.75 are installed in a way in FreeDOS 1.1 
that leads to KEYB crashing at boot 
- if you choose option 1 from the boot menu and 
- manually changed AUTOEXEC.BAT to install a keyboard layout. 
Generally spoken this means people with a different keyboard than the US have a 
problem.

AFAIK there are two ways to work around this as user:

1. Solution: Change the following line in FDCONFIG.SYS
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
to read
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS I=TEST NOVME NOINVLPG
(remove X=TEST)

Or

2. Solution: Change the following line in AUTOEXEC.BAT (if you install f.i. the 
german keyboard layout)
KEYB GR,,keyboard.sys
to read
KEYB GR,,keyboard.sys /NOHI

Effects on free memory:
1st solution: 598,736 total 594,656 conv 4,080 upper
2nd solution: 590,560 total 590,208 conv 352 upper

So the first solution gives me more free memory while the second solution may 
result in a more robust system (more tested and excluded upper memory blocks). 

Of course from a user's perspective it would be best if either KEYB or JEMMEX 
could be fixed. According to your remarks it should be JEMMEX. I just tested 
the new JEMMEX v5.76 but there was no difference.

regards
Ulrich



> El viernes, 13 de enero de 2012, Ulrich Hansen  
> escribió:
> > Am 13.01.2012 um 18:54 schrieb Bernd Blaauw:
> >
> >> Op 13-1-2012 16:11, Ulrich Hansen schreef:
> >>>
> >>> Description: I have installed FreeDOS 1.1 with german language and 
> >>> keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load 
> >>> FreeDOS with JemmEx) keyb will crash with the error message:
> >>>
> >>> Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
> >>> Critical error: cannot allocate memory. DOS reported error: 8
> >>
> >> could you try adding "/NOHI" at your KEYB line please?
> >
> > Wow. This worked!
> >
> > In AUTOEXEC.BAT I have now a line:
> >
> > KEYB GR,,keyboard.sys /NOHI
> >
> > In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So 
> > the JemmEx line looks like this again:
> >
> > 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> >
> >> X=TEST is just a test for checking which UMB areas are (un)safe to use.
> >>
> >> Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that
> >> works. I've not been able to reproduce your case in VMWARE Workstation 8.
> >
> > X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched 
> > after installation) look like this:
> >
> > 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
> > 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
> >
> > So this is OK.
> >
> > I don't really understand why leaving out "X=TEST" in option 1 solved the 
> > problem too. Testing the UMBs should lead to a more stable behavior of 
> > JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to 
> > reproduce with any fresh FreeDOS installation on VirtualBox with the 
> > default settings (and choosing german keyboard layout).
> >
> > Anyway, starting KEYB with /NOHI seems to be the more elegant and logical 
> > solution.
> > Thanks!
> >
> > If this could be the default in FreeDOS, I think it would help other users. 
> > At least the german ones... ;-)
> >
> > regards
> > Ulrich
> >
> >
> >
> >
> >
> > --
> > RSA(R) Conference 2012
> > Mar 27 - Feb 2
> > Save $400 by Jan. 27
> > Register now!
> > http://p.sf.net/sfu/rsa-sfdev2dev2
> > ___
> > Freedos-user mailing list
> > Freedos-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-user
> > --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. 
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

---

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Aitor Santamaría]

Hi,

old thread ;)

There were in the past conflicts with KEYB 2.00 and JEMM that were
apparently solved with KEYB 2.01.
The NOHI option mostly controlls KEYB access to XMS, but reading this
thread, and knowing what I fixed 2.00 to 2.01, I suspect JEMM may make the
DOS' memory allocation strategy functions less robust than they are with
other DOSes.
In case it helps JEMM...

Aitor

El viernes, 13 de enero de 2012, Ulrich Hansen 
escribió:
> Am 13.01.2012 um 18:54 schrieb Bernd Blaauw:
>
>> Op 13-1-2012 16:11, Ulrich Hansen schreef:
>>>
>>> Description: I have installed FreeDOS 1.1 with german language and
keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load
FreeDOS with JemmEx) keyb will crash with the error message:
>>>
>>> Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
>>> Critical error: cannot allocate memory. DOS reported error: 8
>>
>> could you try adding "/NOHI" at your KEYB line please?
>
> Wow. This worked!
>
> In AUTOEXEC.BAT I have now a line:
>
> KEYB GR,,keyboard.sys /NOHI
>
> In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1.
So the JemmEx line looks like this again:
>
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
>
>> X=TEST is just a test for checking which UMB areas are (un)safe to use.
>>
>> Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that
>> works. I've not been able to reproduce your case in VMWARE Workstation 8.
>
> X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched
after installation) look like this:
>
> 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
>
> So this is OK.
>
> I don't really understand why leaving out "X=TEST" in option 1 solved the
problem too. Testing the UMBs should lead to a more stable behavior of
JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to
reproduce with any fresh FreeDOS installation on VirtualBox with the
default settings (and choosing german keyboard layout).
>
> Anyway, starting KEYB with /NOHI seems to be the more elegant and logical
solution.
> Thanks!
>
> If this could be the default in FreeDOS, I think it would help other
users. At least the german ones... ;-)
>
> regards
> Ulrich
>
>
>
>
>
>
--
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: About installation cd AND system backup???

[Rugxulo]

Hi,
   Just a little bit of non-expert info from me here,

On Tue, Jun 5, 2012 at 5:10 PM, Joe(theWordy)Philbrook  wrote:
>
> It would appear that on Jun 3, Eric Auer did say:
>
>> > 3) you wouldn't happen to know if using clonezilla's expert mode
>> >     to de-select cloning the "hidden data between MBR and 1st
>> >     partition" when making a clone of a working bootable {via
>> >     chainloader} freedos partition, would result in a clone that
>> >     wouldn't trash the existing MBR when it was...
>>
>> I do not understand the question.
>
> Perhaps more background information would make the question clearer...
>
> For some reason beyond my understanding, when I restored the
> partition image I'd made of the FreeDOS partition with
> clonezilla, two things happened which I don't understand.
>
> 1) Even though I had carefully selected the menu options to save
>   and restore "partition" images and decidedly did NOT select
>   "whole disk" images, the restore action overwrote my MBR???
>   I had to use a rescue disk to get my grub menu back...

Overwrote the MBR (at sector zero) completely?? Or just changed the
partition table (very likely)?

IIRC, the MBR is 512 bytes with both boot sector and partition table.
So you have to have a DOS (primary  FAT, active) in there somewhere.

GRUB won't fit in 512 bytes, not even close. It just stuffs something
in the MBR that loads stage 1.5 (or whatever) which is hidden
somewhere else (with various file system drivers??). And that is used
to find the appropriate (primary or extended) partitions, which have
their own boot sectors, I think.

On my desktop which triple-boots, I have BOOTMGR as main booter in the
MBR, and if I choose FreeDOS, it boots the FAT32 partition. If I
choose Win7, it jumps to the NTFS partition which uses Windows' own
NTLDR (or whatever it's called these days). If I choose Linux, it
loads GRUB in the ext3 partition, which then boots up PuppyLinux.

All of this is very arcane and complicated. I think this is why it is
often recommended to install certain OSes first before installing
others.

You can load and save the MBR via (DOS-based) bootmgr.com , so once
you get a working Linux setup with GRUB, it should be fairly easy to
setup for FreeDOS, esp. as BOOTMGR doesn't need any extra payloads (or
whatever) to load to further load (etc. etc.).

I know GRUB is supposed to handle all of this, but it's honestly kinda
cryptic and annoying. Maybe you could try something else like Gujin to
boot your Linux partition. It has a mini DOS-based version too, and it
should? autodetect things for you (though you may or may not need
vmlinuz [kernel] and initrd* [magic goop] on your FAT partition).

> 2) Even though it was a partition image, and not just a file copy, the
>   restored FreeDOS was unbootable.

It is possible to make it bootable, but something was probably
misconfigured or not saved correctly. It's a very arcane black art,
partitions and MBRs and boot sectors. I really do sympathize, it's
just frustrating and complicated.

Just don't give up, keep looking / reading / researching / fiddling.
Be careful and backup important stuff, but eventually you should get
it working (God willing!).

You may? find it easier to learn / play with some of this inside a
scratch setup in a VM (e.g. VirtualBox or QEMU) first, hence not
worrying about destroying anything important.

>   {I had already installed and configured several dos utilities and
>   games, so lacking a boot floppy from which I could have tried the
>   sys command, my solution was to mount the FreeDOS partition from
>   Linux and using mc I made a "file" copy of the partition's entire
>   filesystem.

No boot floppy itself or no (working) drive?? You could always use a
bootable CD, I suppose, e.g. PLoP Boot Loader.

BTW, as mentioned, the partition itself isn't all you need.

> Then I reinstalled a fresh copy of FreeDOS to get to
>   the bootloader selection choice where I could select writing the
>   FreeDOS code to the bootsector.

FreeDOS' sys.com should (I think?) only update the FAT partition and
not mess with the MBR. Not sure how carefully conservative FreeDOS
FDISK is, but you don't really need that except to create a FAT
partition "from scratch" (and honestly I might? suggest a different
tool instead).

Just don't muck with the MBR at all, if you don't need to. It's
ideally only there to basically coordinate between various multi-boot
systems. Like I said, it's basically useless for GRUB, all it does is
say, "Okay, now time to call GRUB to do the 'real work' !!" (And GRUB
has to fit somewhere, but I don't know the details where "by default"
or how much space it needs.)

> Then finally I rebooted Linux and
>   again used mc to copy the entire backed up FreeDOS file system
>   back to the mounted FreeDOS partition {overwriting all files}
>   which resulted in a working Freedos WITH the software I'd added
>   such as vim, less, and an mc like clone of nc, as well as some
>   toys, all in place

Re: [Freedos-user] FreeDOS 1.1: About installation cd AND system backup???

[Joe(theWordy)Philbrook]

It would appear that on Jun 3, Eric Auer did say:

> > 3) you wouldn't happen to know if using clonezilla's expert mode
> > to de-select cloning the "hidden data between MBR and 1st
> > partition" when making a clone of a working bootable {via
> > chainloader} freedos partition, would result in a clone that
> > wouldn't trash the existing MBR when it was...
> 
> I do not understand the question.

Perhaps more background information would make the question clearer...

For some reason beyond my understanding, when I restored the
partition image I'd made of the FreeDOS partition with
clonezilla, two things happened which I don't understand.

1) Even though I had carefully selected the menu options to save
   and restore "partition" images and decidedly did NOT select
   "whole disk" images, the restore action overwrote my MBR???
   I had to use a rescue disk to get my grub menu back...

2) Even though it was a partition image, and not just a file copy, the
   restored FreeDOS was unbootable.

   {I had already installed and configured several dos utilities and
   games, so lacking a boot floppy from which I could have tried the
   sys command, my solution was to mount the FreeDOS partition from
   Linux and using mc I made a "file" copy of the partition's entire
   filesystem. Then I reinstalled a fresh copy of FreeDOS to get to
   the bootloader selection choice where I could select writing the
   FreeDOS code to the bootsector. Then finally I rebooted Linux and
   again used mc to copy the entire backed up FreeDOS file system
   back to the mounted FreeDOS partition {overwriting all files}
   which resulted in a working Freedos WITH the software I'd added
   such as vim, less, and an mc like clone of nc, as well as some
   toys, all in place and working...} 

I was asking if anybody knew if clonezilla's expert mode option to deselect
the cloning of what it called "hidden data between MBR and 1st partition"
would in fact force it to omit recording whatever garbage it wrote to my
MBR???

Though I've also followed up on that elsewhere and it seems nobody has seen
clonzilla do that, so I'm thinking it may have only been a fluke. And I'm
thinking I'm going to have to resort to much empirical testing before I
begin to fully trust my back-up needs to clonezilla. 

> In the MBR, you may have a boot menu such as GRUB. Which
> may extend into the space between MBR and 1st partition.
> To boot DOS, you need anything (MBR directly, or a boot
> menu) to get you to the boot sector of the DOS partition
> which must be a PRIMARY partition (sda/hda/... numbers
> 1-4) and the boot sector of the DOS partition must contain
> the correct info about WHERE the partition is, as in
> distance from start-of-disk / MBR to the DOS partition
> itself (DOS sometimes calls this nr of hidden sectors).

Yeah, that's about what I thought. 

> Actually you could even boot DOS from a non-primary
> partition if you fixed the location information, as
> normally non-primary partitions use "relative" place
> values while booting needs "absolute" ones. Not sure
> which side effects you would get, though.

Now THAT does surprise me. And would be, no doubt, a little beyond my skill
level. Me thinks it would be easier to relocate one of my Linux to a
non-primary partition, (and edit any fstab and grub references that do not use
LABEL= or  those unreadable UUID= references instead of device names
to identify said device) to free up a primary partition for FreeDOS than to
pretend I had a clue how to rewrite the boot sector of a non-primary
partition to use absolute values... 

In any case, Thank you for responding to my request for info.

-- 
|   ~^~   ~^~
|   <*>   <*>   Joe (theWordy) Philbrook
|   ^J(tWdy)P
| \___/ <>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: About installation cd AND system backup???

[dmccunney]

On Sun, Jun 3, 2012 at 3:46 PM, Eric Auer  wrote:
> In the case of GRUB2 (?) it will then search the
> PC for bootable operating systems by looking at all
> boot records and present those as boot menu. Classic
> GRUB relied more on a configuration file for that, in
> GRUB2 it is more automatic...

Sort of.  Grub2 still uses a config file, in /boot/grub, and it's
possible to edit that file manually, though the file itself says not
to.  I did so here because the grub routines that searched for OSes
were double counting a Linux install, and showing two entries for it
in the boot menu.

But the routines that build a grub config for you changed
significantly, and there are changes to the config file format.  See
https://help.ubuntu.com/community/Grub2
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: About installation cd AND system backup???

[Eric Auer]

Hi!

> 1) When, at the end of the install, the installer asks what to do with
>the bootsector AKA "Volume Boot Record". Is it the same thing as when a
>linux installer allows me to install grub to the 1st superblock of the
>"/" partition??? {it seams to have the same effect}

Yes that is similar. In both cases, you need to boot
the partition (for example using a boot menu in the
MBR for the whole disk) and then the boot sector in
the DOS partition or the superblock in the Linux one
contain code to continue booting. However, GRUB often
is used as boot menu, not just to load Linux, so GRUB
is often configured as the to-be-booted-thing in your
MBR. In the case of GRUB2 (?) it will then search the
PC for bootable operating systems by looking at all
boot records and present those as boot menu. Classic
GRUB relied more on a configuration file for that, in
GRUB2 it is more automatic...

> 2) Is there a way to make that happen for a restored backup of a fully
>configured copy of freedos... I mean Like if I made a boot floppy and
>used it to do something like " A:> sys c: ", would that have the same
>effect??

There are two cases: You made a backup of all files,
so you failed to backup the boot sector, or you made
a diskimage, but restored it to another location, so
the boot sector needs fresh adjustments...

In both cases, you need something to fix your DOS boot
sector. You can boot DOS from CD, DVD, USB or diskette
and simply run "SYS C:" indeed. You can also use Linux
and run the "sys freedos linux" tool (sys-freedos.pl)
to make a bootsector for a partition or diskimage. In
the latter case, you may have to manually specify the
absolute location of the partition, as mkdosfs (Linux
tool to format FAT partitions) may fail to do so. If
your partition already was formatted by DOS / Windows
anyway, the offset should already be set... See also:

http://wiki.fdos.info/Installation/BootDiskCreateUSB

Note that you can use any FreeDOS boot floppy image
to make a bootable floppy or CD or DVD, the latter by
specifying the floppy image as the boot image in most
decent CD / DVD writing tools (e.g. k3b works fine).

I think FreeDOS provides a regular build for minimal
boot disks, but you can also use Rugxulo's RUFFIDEA
distro which contains most of FreeDOS 1.0 "base" and
some updates and small extra tools on very few disks.

> 3) you wouldn't happen to know if using clonezilla's expert mode to de-select
>cloning the "hidden data between MBR and 1st partition" when making a
>clone of a working bootable {via chainloader} freedos partition, would
>result in a clone that wouldn't trash the existing MBR when it was...

I do not understand the question. In the MBR, you may
have a boot menu such as GRUB. Which may extend into
the space between MBR and 1st partition. To boot DOS,
you need anything (MBR directly, or a boot menu) to
get you to the boot sector of the DOS partition which
must be a PRIMARY partition (sda/hda/... numbers 1-4)
and the boot sector of the DOS partition must contain
the correct info about WHERE the partition is, as in
distance from start-of-disk / MBR to the DOS partition
itself (DOS sometimes calls this nr of hidden sectors).

Actually you could even boot DOS from a non-primary
partition if you fixed the location information, as
normally non-primary partitions use "relative" place
values while booting needs "absolute" ones. Not sure
which side effects you would get, though.

Eric


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FreeDOS 1.1: About installation cd AND system backup???

[Joe(theWordy)Philbrook]

Hello, I recently installed the FreeDOS 1.1 cd to an old laptop with a 6
gig hd a minimal linux all configured to access my email and with all the
bookmarks I need to quickly find help {when/if} the next time I bork my
desktop... I decided I wanted to install dos in part because I found an old
stash of dos floppies and I wanted to see if I could get any of the games
working...

I had a few problems, and had to reinstall a few times. I was unable to
restore a working copy of freedos from a clonezilla image. (I've got it the
way I want it now. But I'd like to be able to back it up with some chance
of restoring it, if needed. So I've a few questions.

1) When, at the end of the install, the installer asks what to do with
   the bootsector AKA "Volume Boot Record". Is it the same thing as when a
   linux installer allows me to install grub to the 1st superblock of the
   "/" partition??? {it seams to have the same effect}

2) Is there a way to make that happen for a restored backup of a fully
   configured copy of freedos... I mean Like if I made a boot floppy and
   used it to do something like " A:> sys c: ", would that have the same
   effect??
   
   {If it would I'd be a lot more comfortable with using tar or even
mc to make a "boot floppy" supported file back up of it, than to repeat
the problem I had with clonezilla.}

3) you wouldn't happen to know if using clonezilla's expert mode to de-select
   cloning the "hidden data between MBR and 1st partition" when making a
   clone of a working bootable {via chainloader} freedos partition, would
   result in a clone that wouldn't trash the existing MBR when it was
   restored, but would still include whatever freedos specific code needed
   for freedos to boot when chainloaded from grub???

-- 
|  ~^~   ~^~
|Joe (theWordy) Philbrook
|  ^J(tWdy)P
|\___/ <>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bernd Blaauw]

Op 11-4-2012 21:33, Jack schreef:

> Send me a private E-Mail, and if XMGR can be modified so Syslinux and
> Isolinux do NOT "confuse" it, I will make such modifications in XMGR!

I'll try to figure out what's going on, however have much doubt that I'd 
be skilled enough to actually find a root cause.

A web view of the Syslinux files is available at:

[ 
http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=tree;h=refs/heads/master;hb=refs/heads/master
 
]

A 7MB zip-file of everything (contents uses long filenames!) :
http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.05.zip

Behaviour I'm noticing:
* one A20 method if loading FreeDOS directly (bootsector, no syslinux)
* another one if loading FreeDOS from Syslinux (chainload bootsector)
* a 3rd one if going from Syslinux to MEMDISK to FreeDOS.

JEMMEX's way might be the most compatible.


A testing floppy would have the following:
[1] FreeDOS bootsector pointing to MetaKern bootloader file
[2] MetaKern bootloader including FreeDOS and Syslinux bootsectors
[3] FreeDOS kernel/shell/xmgr/config.sys/autoexec.bat
[4] ldlinux.bin (Syslinux)
[5] freedos.bss (FreeDOS bootsector) pointing to KERNEL.SYS
[6] memdisk (syslinux ramdisk driver)
[7] fdboot.img (tiny floppy image containing above partially)


with 3 boot test methods:
* 1 --> 2 --> 3 (pretty simple).
* 1 --> 2 --> 4 --> 3 (reasonably OK).
* 1 --> 2 --> 4 --> 6 --> 7 --> 3 (complex).

Bernd


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Jack]

>>> ... With my own testing I found JEMMEX more compatible than XMGR
>>> or HIMEMX + JEMM386 in various cases, but on other systems it is
>>> different, as Mike mentioned ...
>>
>> To WHAT "incompatibilities" are you referring??
>
> The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around with,
> even before loading a DOS kernel.As your driver expects a sane
> BIOS setting and sane behaviour of the DOS kernel, it's slightly
> less tolerant/paranoid compared to JEMMEX.   This is all at boot-
> time (config.sys), not runtime (devload xmgr.sys) as no A20/HMA
> stuff is involved then due to DOS (kernel-)limitations.

I would like to know exactly WHAT kind of "insane" settings re: "A20"
can be done by Syslinux/Isolinux, which would in fact "confuse" XMGR!

Send me a private E-Mail, and if XMGR can be modified so Syslinux and
Isolinux do NOT "confuse" it, I will make such modifications in XMGR!


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bernd Blaauw]

Op 11-4-2012 21:10, Jack schreef:
>> ... With my own testing I found JEMMEX more compatible than XMGR or
>> HIMEMX + JEMM386 in various cases, but on other systems it's different,
>> as Mike mentioned ...
>
> To WHAT "incompatibilities" are you referring??

The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around with, 
even before loading a DOS kernel. As your driver expects a sane BIOS 
setting and sane behaviour of the DOS kernel, it's slightly less 
tolerant/paranoia compared to JEMMEX. This is all at boot-time 
(config.sys), not runtime (devload xmgr.sys) as no A20/HMA stuff is 
involved then due to DOS (kernel-)limitations.

Think I prepared a floppy image file sometime ago, but downloading that 
isn't very modem-friendly.

Basicly I just have to verify behaviour of different sets of drivers 
under various systems and emulators. It's a long-term todo item.


Bernd


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Jack]

> ... With my own testing I found JEMMEX more compatible than XMGR or
> HIMEMX + JEMM386 in various cases, but on other systems it's different,
> as Mike mentioned ...

To WHAT "incompatibilities" are you referring??

Be advised of the following --

1) JEMMEX/JEMM386 use "old" memory-test schemes, to remain compatible
with that never-updated 130K atrocity known as MS-DOS EMM386!   If
using the JEMM drivers, specific "I=-"/"X=-" lines
may be needed to avoid "new-style" areas of memory -- "I=Test" and
"X=Test" might not be enough.

2) "XMGR + JEMM386" or "HIMEMX + JEMM386" should give nearly the same
results for available memory.   HIMEMX may find about 9K more, for
it allows use of certain ACPI areas, while XMGR does not.   But 9K
bytes is not a big difference, given today's 4-Gigabyte systems!

3) "UMBPCI + XMGR" may well give far bigger differences in the memory
it finds for use, since in this case UMBPCI "detects" upper-memory
and XMGR then uses what UMBPCI found.   I did not write UMBPCI but
I believe its memory-test algorithms ARE rather different than the
ones used in JEMM386/JEMMEX.

4) "UMBPCI + XMGR + JEMM386" can also be used, when one allows UMBPCI
to scan for "normal" upper-memory (C8000h-Eh) and only desires
JEMM386 to "map" the B-B7FFFh monochrome video space for extra
upper-memory.   But NOTE that this will NOT work using FreeDOS, as
FreeDOS allows but ONE upper-memory "provider" and will not add-up
the memory found by UMBPCI and JEMM386.MS-DOS V6.22 and V7.10+
allow multiple "providers" and will do such an add-up.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Rugxulo]

Hi,

On Wed, Apr 11, 2012 at 1:24 PM, Bernd Blaauw  wrote:
> Op 11-4-2012 20:02, Rugxulo schreef:
>
> The entire idea of opensource was to be able to modify sources to suit a
> person's needs. Most people, including me, haven't got enough interest
> or experience to be a programmer, but still, a bit of messing around and
> see what happens, should be possible.

I'm no whiz myself, but the only way to learn is try, I suppose, or
read a billion books and sources. Though it's not easy, and there just
aren't enough helpful mentors.

>> If you really want, you can include both 16-bit and 32-bit
>> UNZIP*.EXE files and choose dynamically at runtime (cpulevel.com,
>> if errorlevel 3 unzip32.exe). At least this way won't be painful
>> "unnecessarily" for 90% of users.
>
> Copy proper decompressor somewhere and set path? Sounds like
> a nice option.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cpulevel2007.zip

>> P.S. I guess you know 7zdecode.exe is much smaller than p7zip. Or are
>> you just letting the end user figure out how to unpack it?   ;-)    Oh
>> wait, p7zip itself can't build (easily?) on FreeDOS, heh, now that's
>> one behemoth of a package (slow to build).
>
> Your used extender for 7zdecwat.exe wasn't compatible with public
> distribution, so I can't use it.

I built 9.22 with stock DJGPP + CWSDPMI only just to be safe with
licensing. You can find it on iBiblio. Though it bundles CWSDSTUB in
itself to ease use, but you can remove that if you want to save a few
kb.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/7zdecode/

> A 386+ build of UPX-UCL v3.08 wouldn't hurt either :)

I did manage to cross-compile it, but native DJGPP just didn't seem to
like it, and I got too frustrated to keep trying ad nauseum. (I'm
pretty sure they only cross-compile too, so they don't care about
native builds.)

So I never got back to that, hence iBiblio only has 3.07. But I can
email or upload it for you if you want. It works fine. EDIT: Never
mind, just uploaded to iBiblio, check here:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/upx-ucl-3.08.zip

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bernd Blaauw]

Op 11-4-2012 20:02, Rugxulo schreef:

> Users will always need sources, esp.  if they share, but they don't
> necessarily need to unpack them. (Well, anyways, they probably don't
> have all compilers anyways.)

The entire idea of opensource was to be able to modify sources to suit a 
person's needs. Most people, including me, haven't got enough interest 
or experience to be a programmer, but still, a bit of messing around and 
see what happens, should be possible.

> Keep in mind that outside of FDXMS286, there is no XMSv2 only driver,
> esp. for 286s that is the only one that (allegedly) works. And
> obviously XMS doesn't work at all on 8086 or 80186.

The combination of
01) System firmware (BIOS/EFI/UEFI/Coreboot)
02) Controller firmware (PCI IDE/SATA/USB controller)
03) Boot Manager (GRUB/Syslinux/Memdisk)
04) Boot Loader (boot sector usually)
05) Kernel (FreeDOS/MSDOS/DRDOS etc)
06) Shell (FreeCOM/4DOS)
07) Memory driver (XMGR/HIMEMX/JEMM386/JEMMEX
08) Other drivers (SHSUCDX etc)
09) Programs (KEYB, DEVLOAD UIDE.SYS)
10) Settings (DOS=HIGH / DOS=UMB / DOSDATA=UMB)

can be horribly misbehaving in some cases. With my own testing I found 
JEMMEX more compatible than XMGR or HIMEMX + JEMM386 in various cases, 
but on other systems it's different, as Mike mentioned. My preference 
would be no XMS driver at all, and only load as needed/wanted.

If the MEMDISK stuff in FreeDOS kernel 2041 works properly (guess it's 
not compiled in by default? not sure?) I could offer which memory driver 
to load already from the Syslinux menu.

> But I thought the default installer (since on CD) was 386+ anyways? Or
> at least default requirements. So just use DJGPP UNZIP32.EXE (or
> whatever it's called), it can run in "raw" (no mem. managers) just
> fine. If you really want, you can include both 16-bit and 32-bit
> UNZIP*.EXE files and choose dynamically at runtime (cpulevel.com, if
> errorlevel 3 unzip32.exe). At least this way won't be painful
> "unnecessarily" for 90% of users.

Copy proper decompressor somewhere and set path? Sounds like a nice option.

> Yes, but some DOS settings are quite limited by default, so sometimes
> F8 is better.

PATH and DIRCMD usually come into my way. For others, language/keyboard 
stuff might be quite relevant as typing blindly on keyboards with 
different layouts is confusing. Yay laptops from Belgium :)

> I agree with Eric, but it's your call, Bernd, obviously.   ;-)

Only done when needed (no C: present so offer FDISK if possible, or 
ramdisk which requires XMS which requires loading driver).

>> We hopefully do not have many such programs anyway...?

Flashrom is one such program at least. 4DOS might be another.

> P.S. I guess you know 7zdecode.exe is much smaller than p7zip. Or are
> you just letting the end user figure out how to unpack it?   ;-)Oh
> wait, p7zip itself can't build (easily?) on FreeDOS, heh, now that's
> one behemoth of a package (slow to build).

Your used extender for 7zdecwat.exe wasn't compatible with public 
distribution, so I can't use it. A 386+ build of UPX-UCL v3.08 wouldn't 
hurt either :)

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Rugxulo]

Hi,

On Wed, Apr 11, 2012 at 11:13 AM, Eric Auer  wrote:
>
>>> it seems even on modern hardware unpacking FreeCOM
>>> during install may take VERY long, so we need a fix:
>>
>> This seems to be specific to the old installer (v3.7.8 by Jeremy) I
>> think, as that unpacks entire packages. Sourcecode modification would be
>> required to add a "-x source/*". Alternatively, or additionally, if
>> someone modified the new installer (v4.01 by Jim) to switch to
>> destination directory after unpacking files, that would also work.
>
> That sounds as if a very small problem keeps you from
> upgrading to a newer and probably better installer...

Yes, but Jim is too busy, and barring any motivation, others (ahem)
haven't looked at it either.

>>> - it is good to have source and binary in one zip
>
> If size is critical, you can automatically make zips
> without sources by doing zip -d somefile.zip source/*

Not recommended, it's easier to just keep it together. Though if you
want to maximize size, just put sources inside their own .ZIP but
within the main .ZIP, so at least unpacking only has to create one
file. You can even use "Stored" (-0 compression) on it so the outer
.ZIP can compress it better as a whole.

>>> - but you can use info-zip's command line options
>>>    (-x source/*) to exclude sources from unzip :-)
>>
>> New installer already does this, reason why...
>
> That is sth. to discuss with the installer maintainer :-)

Again, he's too busy with real life (work, MBA) and updating the web site, etc.

>>> - a default install does not need sources, as the
>>>    user can always fetch those from the zip later
>>
>> I've never liked programs with many options/switches
>
> Exactly. So do not ASK users whether and which sources
> they want to install, just TELL them that all sources
> can be found in the zips when needed. Users will rarely
> need sources and most of the time only of single apps.

Users will always need sources, esp.  if they share, but they don't
necessarily need to unpack them. (Well, anyways, they probably don't
have all compilers anyways.)

>>> - users should be warned that install without XMS
>>>    drivers will be horribly slow due to lack of RAM
>
> Regarding the compatibility trouble discussion: Users
> BELIEVE that not loading drivers is a safe option but
> in fact it is a very problematic one because the install
> performance totally chokes on lack of memory then. You
> could better offer multiple XMS drivers to chose from.

Keep in mind that outside of FDXMS286, there is no XMSv2 only driver,
esp. for 286s that is the only one that (allegedly) works. And
obviously XMS doesn't work at all on 8086 or 80186.

But I thought the default installer (since on CD) was 386+ anyways? Or
at least default requirements. So just use DJGPP UNZIP32.EXE (or
whatever it's called), it can run in "raw" (no mem. managers) just
fine. If you really want, you can include both 16-bit and 32-bit
UNZIP*.EXE files and choose dynamically at runtime (cpulevel.com, if
errorlevel 3 unzip32.exe). At least this way won't be painful
"unnecessarily" for 90% of users.

> For not loading anything, there is always the F5 key...

Yes, but some DOS settings are quite limited by default, so sometimes
F8 is better.

>> I intend to offer loading of XMS driver at runtime as an option.
>
> Please avoid that - it complicates things and does not
> give FreeCOM or kernel enough extra RAM to matter. So
> I strongly prefer loading XMS drivers in config.sys...

I agree with Eric, but it's your call, Bernd, obviously.   ;-)

> As said, XMS drivers should be loaded in config.sys,
> there can be several XMS drivers to pick from to get
> extra compatibility, and avoiding XMS drivers should
> be hard, so only expert or masochist users do it...

Depends on the app. Most "extended" apps can support raw just fine
(more or less). Hmmm, spawning other extended apps might be tricky in
some scenarios, but only because of fragmentation or default
allocating everything for parent app.

>>> Excluding sources from unzipping instead of unzipping
>>> and then deleting them also saves CPU time and disk
>>> activity time and temporarily disk storage space :-)
>>
>> Deleting files can take ages indeed. By the way, I'm considering
>> 7-zipping sourcecode of programs that can't be compiled in DOS.
>
> We hopefully do not have many such programs anyway...?

What can't be compiled in DOS? I know a lot of DJGPP-era stuff needs
LFNs, but I can't think of any common FreeDOS util (off the top of my
head) that can't easily work. Well, there's probably something
somewhere.

P.S. I guess you know 7zdecode.exe is much smaller than p7zip. Or are
you just letting the end user figure out how to unpack it?   ;-)Oh
wait, p7zip itself can't build (easily?) on FreeDOS, heh, now that's
one behemoth of a package (slow to build).

--
Better than sec? Nothing is better than sec when it comes to
monitor

Re: [Freedos-user] Freedos 1.1 install errors...

[Eric Auer]

Hi Bernd,

>> it seems even on modern hardware unpacking FreeCOM
>> during install may take VERY long, so we need a fix:
>
> This seems to be specific to the old installer (v3.7.8 by Jeremy) I
> think, as that unpacks entire packages. Sourcecode modification would be
> required to add a "-x source/*". Alternatively, or additionally, if
> someone modified the new installer (v4.01 by Jim) to switch to
> destination directory after unpacking files, that would also work.

That sounds as if a very small problem keeps you from
upgrading to a newer and probably better installer...

>> - it is good to have source and binary in one zip

If size is critical, you can automatically make zips
without sources by doing zip -d somefile.zip source/*

>> - but you can use info-zip's command line options
>>(-x source/*) to exclude sources from unzip :-)
>
> New installer already does this, reason why...

That is sth. to discuss with the installer maintainer :-)

>> - a default install does not need sources, as the
>>user can always fetch those from the zip later
>
> I've never liked programs with many options/switches

Exactly. So do not ASK users whether and which sources
they want to install, just TELL them that all sources
can be found in the zips when needed. Users will rarely
need sources and most of the time only of single apps.

>> - users should be warned that install without XMS
>>drivers will be horribly slow due to lack of RAM

Regarding the compatibility trouble discussion: Users
BELIEVE that not loading drivers is a safe option but
in fact it is a very problematic one because the install
performance totally chokes on lack of memory then. You
could better offer multiple XMS drivers to chose from.
For not loading anything, there is always the F5 key...

> I intend to offer loading of XMS driver at runtime as an option.

Please avoid that - it complicates things and does not
give FreeCOM or kernel enough extra RAM to matter. So
I strongly prefer loading XMS drivers in config.sys...

> request to have a tiny init shell that spawns, in a loop FreeCOM

That is easy but makes things complicated compared to
just loading XMS drivers when XMS drivers SHOULD load.

I think I once made some "CMD" for that when FreeCOM
had a bug that made it exit from time to time :-p

As said, XMS drivers should be loaded in config.sys,
there can be several XMS drivers to pick from to get
extra compatibility, and avoiding XMS drivers should
be hard, so only expert or masochist users do it...

>> Excluding sources from unzipping instead of unzipping
>> and then deleting them also saves CPU time and disk
>> activity time and temporarily disk storage space :-)
>
> Deleting files can take ages indeed. By the way, I'm considering
> 7-zipping sourcecode of programs that can't be compiled in DOS.

We hopefully do not have many such programs anyway...?

Eric




--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bernd Blaauw]

Op 10-4-2012 18:21, Eric Auer schreef:
> it seems even on modern hardware unpacking FreeCOM
> during install may take VERY long, so we need a fix:

This seems to be specific to the old installer (v3.7.8 by Jeremy) I 
think, as that unpacks entire packages. Sourcecode modification would be 
required to add a "-x source/*". Alternatively, or additionally, if 
someone modified the new installer (v4.01 by Jim) to switch to 
destination directory after unpacking files, that would also work.

> - it is good to have source and binary in one zip

There's some disadvantages though, download size being one of them, 
memory size and loading times in other specific conditions. A 16MB 
binary-only ISO has its merits also.

> - but you can use info-zip's command line options
>(-x source/*) to exclude sources from unzip :-)

New installer already does this, reason why this new installer isn't 
unconditionally enabled yet is that I dislike having to search entire 
partitions for a single (post-installation) file just to find out where 
files were installed to.

> - a default install does not need sources, as the
>user can always fetch those from the zip later

I've never liked programs with many options/switches, so confusing and 
often also lacking examples.

> - users should be warned that install without XMS
>drivers will be horribly slow due to lack of RAM

I intend to offer loading of XMS driver at runtime as an option. (JEMMEX 
LOAD or DEVLOAD XMGR.SYS). However this doesn't solve low memory 
situation as FreeCOM can't relocate itself. Hence my perhaps decade-old 
request to have a tiny init shell that spawns, in a loop FreeCOM in a 
non-permanent way, so FreeCOM can be started a second time automatically 
if exiting the first FreeCOM instance. With that, automatic relocation 
to XMS.

SHELL=TINYCMD.COM C:\COMMAND.COM C:\AUTOEXEC.BAT


> - actually I would not even OFFER a boot menu item
>to skip loading the XMS driver at all: You cannot
>even boot the install CD / USB on old pre-XMS PC.
>
> Excluding sources from unzipping instead of unzipping
> and then deleting them also saves CPU time and disk
> activity time and temporarily disk storage space :-)

Deleting files can take ages indeed. By the way, I'm considering 
7-zipping sourcecode of programs that can't be compiled in DOS. Saves a 
bit of space.

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bret Johnson]

> Have you tried explicit "I=-" and "X=-" commands with
> JEMM386/JEMMEX??

I've tried several different JEMM options -- none of them fixed the problem on 
that particular computer.  I finally just gave up and went to other 
alternatives.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Jack]

>> actually I would not even OFFER a boot menu item to skip loading the
>> XMS driver at all: You cannot even boot the install CD / USB on old
>> pre-XMS PC.
>
> Probably a bad idea for compatibility reasons, unless you offer multiple  
> choices for which XMS manager to install.  E.g., I have a computer where  
> JEMM doesn't work at all, but some of the others (including MS  
> HIMEM.SYS) do.

Have you tried explicit "I=-" and "X=-" commands with
JEMM386/JEMMEX??   Both of them were designed to use "ancient" EMM386
memory detection schemes, for compatibility reasons.   However, newer
devices and/or BIOS routines may require that JEMM386/JEMMEX are told
to "avoid" their upper-memory address areas.

Re: loading with no XMS driver, that can still be a useful diagnostic
scheme, and I continue to permit UIDE/UIDEJR (but no-longer UIDE2) to
be run in such a configuration.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Mark Brown]

the "no-drivers" choice, No. 4, is provided because some
programs, such as PLoP, will not load at all unless there
are *no drivers* loaded, at least on my system...
 
PLoP chokes on any drivers in freedos 1.1, saying:
"cannot run under windows in a dos box", in effect.
 
i kid you not.
..
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
..--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bret Johnson]

> actually I would not even OFFER a boot menu item to skip loading the
> XMS driver at all: You cannot even boot the install CD / USB on old
> pre-XMS PC.

Probably a bad idea for compatibility reasons, unless you offer multiple 
choices for which XMS manager to install.  E.g., I have a computer where JEMM 
doesn't work at all, but some of the others (including MS HIMEM.SYS) do.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Eric Auer]

Hi Bernd,

it seems even on modern hardware unpacking FreeCOM
during install may take VERY long, so we need a fix:

- it is good to have source and binary in one zip

- but you can use info-zip's command line options
  (-x source/*) to exclude sources from unzip :-)

- a default install does not need sources, as the
  user can always fetch those from the zip later

- users should be warned that install without XMS
  drivers will be horribly slow due to lack of RAM

- actually I would not even OFFER a boot menu item
  to skip loading the XMS driver at all: You cannot
  even boot the install CD / USB on old pre-XMS PC.

Excluding sources from unzipping instead of unzipping
and then deleting them also saves CPU time and disk
activity time and temporarily disk storage space :-)

Eric




--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Bernd Blaauw]

Op 8-4-2012 19:44, Michael B. Brutman schreef:
> Some of us figured out that on ancient hardware (8088, 80286, etc.) the
> decompression process takes a long time.  If you are running in a
> virtual machine and your underlying hardware/operating system does not
> fully support virtualization then you are emulating the machine
> instruction by instruction, and that can take forever too.

Yeah Jim Hall insisted on combining source and binary into a single 
package so I've done that. The advantage is GPL-requirements are easier 
met this way, disadvantage is unpacking takes longer. Unpacking on a 
system without XMS-driver loaded from CONFIG.SYS is a nightmare, caused 
by a lack of memory. As FreeCOM can't relocate itself once XMS is 
available, we're in trouble and UNZIP gets very small decompression 
buffers. I've seen this happen with TDSK also taking 100KB low memory.

> My 2009 vintage Intel quad-core supports virtualzation well so I have
> very little instruction emulation.  But a user with a newer Atom tried
> it and noticed the horrible slowdown.  Apparently the Atom isn't fully
> capable of virtualization so QEMU was resorting to emulating each
> instruction, and that is very slow.

I think I mentioned somewhere FreeDOS installer unpacking everything in 
28 seconds, but that was with C: a RAMDISK and the FreeDOS CD contents 
also in ramdisk, using SHSUCDRI. That's real hardware, I still have to 
test in virtual machines and make things more robust.

Bernd


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Michael B. Brutman]

On 4/3/2012 1:18 AM, Michael Robinson wrote:
> There is a syntax error message that flashes before the where to install
> freedos to and from menu comes up.  Another problem, install freezes at
> installing command.com.  Uge!
>

Are you installing on old hardware or in a virtual machine?

Some of us figured out that on ancient hardware (8088, 80286, etc.) the 
decompression process takes a long time.  If you are running in a 
virtual machine and your underlying hardware/operating system does not 
fully support virtualization then you are emulating the machine 
instruction by instruction, and that can take forever too.

My 2009 vintage Intel quad-core supports virtualzation well so I have 
very little instruction emulation.  But a user with a newer Atom tried 
it and noticed the horrible slowdown.  Apparently the Atom isn't fully 
capable of virtualization so QEMU was resorting to emulating each 
instruction, and that is very slow.


Mike




--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Rugxulo]

Hi,

On Tue, Apr 3, 2012 at 1:18 AM, Michael Robinson
 wrote:
>
> There is a syntax error message that flashes before the where to install
> freedos to and from menu comes up.  Another problem, install freezes at
> installing command.com.  Uge!

I'm pretty sure it was agreed upon that it doesn't technically
"freeze", it just takes a (relatively) long time at installing
FreeCom, for whatever reason. Just be patient, and it should finish.

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Freedos 1.1 install errors...

[Michael Robinson]

There is a syntax error message that flashes before the where to install
freedos to and from menu comes up.  Another problem, install freezes at
installing command.com.  Uge!


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Carl Spitzer]

On Sat, 2012-01-14 at 19:14 -0800, Michael Robinson wrote:

> First off, I don't appreciate anyone calling anyone an idiot on this
> email list.  Second, I haven't experimented with Freedos 1.1 myself, but
> I hope any difficulty others have working with it is dealt with both
> patiently and professionally.  Myself, I'm waiting for the 1.2 release.


Patience is over rated.  With a spare drive and some drive caddies you
cna play around with new stuff and not hose a working system.

CWSIV
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[dos386]

Please try to empty FDCONFIG.SYS and FDAUTO.BAT, and re-add USEFUL
things piece after piece ... and supply shot of the crash ... "it
crashes AFTER the boot has finished" is NOT very informative.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

> wish VMware's video feature would use standard codecs so
> something could be posted to Youtube or

Please provide your movies in OGV or WebM files, not Loo-Tube.

> > - It fails to find any HD (see middle shot)
> In the normal configurations or the dedication one?

Both, but in "normal configurations" it "survives" the problem
and proceeds to COMMANDX ...

> I don't think it hangs, just takes ages and ages to decompress COMMANDX
> as it's a big file. For most compatibility, memory managers were
> disabled. This means kernel and shell are loaded in conventional memory
> and thus buffer space for UNZIP is tiny, making things take much longer.

Imagine an 80386 upgrade CPU model running on a 80286 board at 10 MHz :shock:

> > successfully on a __REAL__ PC ;-)
> I did and did it successfully

COOL :-)

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[Kenneth J. Davis]

On Jan 15, 2012 6:04 PM, "Ralph Deffke"  wrote:
>
> Thanx all,
>
> but as I said its impossible to figure out what driver is causing the
problem, the sequence doesn't seem to be logical to fix the problem.
> it crashes AFTER the boot has finished.
>
> I installed version 1,0 ( 0.87 beta ) with no problem.
>
> tx
> ralph
>

Maybe I missed it, could you describe your computer a little?  Real or vm,
how much RAM, and any other factors you feel may be important.

Thank you,
Jeremy
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[Ralph Deffke]

Thanx all,

but as I said its impossible to figure out what driver is causing the problem, 
the sequence doesn't seem to be logical to fix the problem.
it crashes AFTER the boot has finished.


I installed version 1,0 ( 0.87 beta ) with no problem.

tx
ralph
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[teo gum]

2012/1/15 dos386 

> > Other:
>
> >- CWSDPMI, VSM, DOSNTLFN, ... are in
> >- INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
> >ARACHNE, ... are NOT in ... what can you do with it when installed ?
>

As for the mpxplay copied it into /fdos/bin from the previous distribution.
Or maybe i didn't understand the essence of the question (for a too bad
english of mine)
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[teo gum]

2012/1/15 dos386 


> >would be nice to know how many people actually installed it
> >successfully on a __REAL__ PC ;-)
>

I did and did it successfully. Yes, it did hang on the commandx but not
mortally - for a while like some 2 minutes and then continued without
problems.
On a partition fat 32 - 3 gb.
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Bernd Blaauw]

Op 15-1-2012 3:56, dos386 schreef:
>> [Freedos-kernel] FreeDOS 1.1 released
>
> COOL :-)

thanks, worked hard for it :)

> http://jafile.com/uploads/dos386/freeds11.png

I like your style of coming up with screenshots, it clarifies issues 
quite nicely. I wish VMware's video feature would use standard codecs so 
something could be posted to Youtube or something. There's other 
software likely anyway, so no big deal.

> Problems:
>
> - What's the purpose of the menu item "Pasquale" (see top shot) ?

It serves as a dedication to the late DOS-C (FreeDOS kernel origin) 
developer Pat. However if you press TAB there you might find the 
Isolinux/Memdisk parameters used. If I remember correctly it functions 
as a hidden way to remaster the ISO, and does so by hiding all physical 
disks (the "nopassany" on commandline).

Unfortunately, this also hides the (El-Torito) CD-drive as it's 
presented as drive E0 (or F0 or whatever). If there could be a custom 
modified version of the FreeDOS kernel that doesn't return C:..Z: at 
boottime, but only at runtime when adding disk drives (ramdisks, usb 
drives, perhaps some PARSEHDD.SYS based on UIDE etc) I could remove the 
NOPASSANY parameter and thus keep CD-ROM access intact for ELTORITO.SYS. 
Right now you're forced to load UIDE driver to gain access to IDE/SATA 
CD drive (it does hardware detection, doesn't rely on BIOS hooks removed 
by "nopassany").


Thus, this option is selectable but not intended for end-users. No 
end-user will select beyond first few options (install, or fdisk to 
speed up things a bit if already experienced with DOS) anyway.

> - It fails to find any HD (see middle shot)

In the normal configurations or the dedication one?
The copyright one serves as a hidden option to load an ISO file, except 
that I omitted it for the official 1.1 release (unlike the earlier 
binary release that Michael Brutman tested and found buggy).
It's intended to get rid of CD access times by loading the ISO into RAM.

> - Using the menu item "install to harddisk", it starts installing but
>hangs at "commandx" (see bottom shot)

I don't think it hangs, just takes ages and ages to decompress COMMANDX 
as it's a big file. For most compatibility, memory managers were 
disabled. This means kernel and shell are loaded in conventional memory 
and thus buffer space for UNZIP is tiny, making things take much longer.


> - CWSDPMI, VSM, DOSNTLFN, ... are in

Yeah I've got reasons for adding them (default \AUTOEXEC.BAT, as well as 
for running MKISOFS and in my working copy, 7ZDECWAT).

> - INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
> ARACHNE, ... are NOT in ... what can you do with it when installed ?

Nothing much yet, I'll admit that. I wanted to release a basic updated 
set first, and afterwards add back the Live/Net functionality that 1.0 
base had, and yet even later add back most stuff that was in the big 1.0 
CD-image. And there's other stuff to add, as you mention already. I'd 
like to have that PDF reader in at least, and NASM/Openwatcom plus some 
of Japheth's tools.

Finding goals and then finding the most suitable corresponding tools can 
be quite challenging already. Only imagine all kinds of software related 
to CD-drives.

I've not had much luck with Arache, OBW and Dillo in VMware.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

My criticism addressed the fact that you can "select"
Pat as a menu item, not the respect to Pat ... EOD @Ralf.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

Thanks ...

> It is not a menu item, just a dedication :-(
> the same respect to Pat can be shown even
> without the highlighting of that item/line

and allowing to select it ;-)

> What types of HD do you have? IDE, SATA, USB?

IDE, and there is a FAT16 partition on.

> Maybe because there actually is no "harddisk"
> in the sense of "FAT partition useable by DOS"

there are some files installed after ... BTW, it says "no HD"
but later it says "C: 500 MB free" before it starts installing,
if I select "install to harddisk"

(other discussion)

> Some quick feedback:
> In the last 40 minutes, we've had 15 people
> download the fd11src.iso release via the web site.

would be nice to know how many people actually installed it
successfully on a __REAL__ PC ;-)

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Rugxulo]

Hi,

On Sat, Jan 14, 2012 at 9:31 PM, Ralf A. Quint  wrote:
> At 07:14 PM 1/14/2012, Michael Robinson wrote:
>
>>First off, I don't appreciate anyone calling anyone an idiot on this
>>email list.
>
> Sorry but this was just one arrogant post of him too many!
>
> He is one of the reasons, beside my past health issues, that I have
> not participated in here for years.

Let's not overreact. Everybody is welcome here, but opinions will always differ.

I don't think he meant any offense, it was just a silly question.
Don't read too much in to it, all he did was ask! He didn't piss on
anybody's grave. I'm sure he's aware of Pat's contributions. I know
DOS386 has contributed a lot to the DR-DOS wiki and tested a lot of
software, so he is equally as passionate as anyone.

As for all that extra stuff he wants, that will have to wait for a
bigger release (1.2?).

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Ralf A. Quint]

At 07:18 PM 1/14/2012, dos386 wrote:
>I can install and update FreeDOS manually (and I've been
>having it for years), so the problems don't really hurt me,
>but for potential new users, I'd prefer a well working distro.

How about you come up with a better working installer yourself then?

Ralf 


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Ralf A. Quint]

At 07:15 PM 1/14/2012, dos386 wrote:
> > > What's the purpose of the menu item "Pasquale" (see top shot) ?
> > Are you such an idiot or are you just trying to play the troll here?
> > It should be obvious to almost everyone that this is not an 
> active menu item
>
>Idiot yourself. It is active. Just try to select it and push ENTER :-D

No, I won't. I am not idiot enough to do that...

Ralf


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Ralf A. Quint]

At 07:14 PM 1/14/2012, Michael Robinson wrote:
>First off, I don't appreciate anyone calling anyone an idiot on this
>email list.

Sorry but this was just one arrogant post of him too many!

He is one of the reasons, beside my past health issues, that I have 
not participated in here for years.

Ralf 


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Eric Auer]

Hi Dos386,

>> [Freedos-kernel] FreeDOS 1.1 released
> http://jafile.com/uploads/dos386/freeds11.png

> - What's the purpose of the menu item "Pasquale" (see top shot) ?

It is not a menu item, just a dedication :-(

Maybe the fact that it is highlighted made
it look like a menu item for you... I guess
the same respect to Pat can be shown even
without the highlighting of that item/line.

> - It fails to find any HD (see middle shot)

What types of HD do you have? IDE, SATA, USB?
Does your BIOS support them? If they only have
non-FAT partitions (NTFS of modern Windows, or
Linux or other partitions) then there is no C:
style disk active for DOS. It would be possible
to then let you run a partition tool, but those
things are pretty dangerous - type or click the
wrong button any your other data is gone. So I
appreciate the ABSENCE of a partitioning tool.

People could e.g. use a GPARTED boot CD/DVD to
non-destructively add a FAT partition for DOS.

> - Using the menu item "install to harddisk", it starts installing but
>   hangs at "commandx" (see bottom shot)

Maybe because there actually is no "harddisk"
in the sense of "FAT partition useable by DOS"
at that moment on your PC, see above?

> - CWSDPMI, VSM, DOSNTLFN, ... are in

For example DOSFSCK needs CWSDPMI and long
file names are sort of widespread today.

> - INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
> ARACHNE, ... are NOT in ... what can you do with it when installed ?

You could install them later. Question to the
experts: Does the 1.1 distro already support
online FDUPDATE / FDPKG updates? Otherwise it
is of course easy to download the ZIP manually
and maybe even using another operating system.

I personally would like UNTGZ and HDPMI and if
space permits HX and 7ZIP. Maybe even MPXPLAY.

And I think the others are pretty big or not so
much for "everyday average use" so they are for
a larger, more complete distro, not a mini one.

Regards, Eric


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

I can install and update FreeDOS manually (and I've been
having it for years), so the problems don't really hurt me,
but for potential new users, I'd prefer a well working distro.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

> > What's the purpose of the menu item "Pasquale" (see top shot) ?
> Are you such an idiot or are you just trying to play the troll here?
> It should be obvious to almost everyone that this is not an active menu item

Idiot yourself. It is active. Just try to select it and push ENTER :-D

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Michael Robinson]

First off, I don't appreciate anyone calling anyone an idiot on this
email list.  Second, I haven't experimented with Freedos 1.1 myself, but
I hope any difficulty others have working with it is dealt with both
patiently and professionally.  Myself, I'm waiting for the 1.2 release.

> >Problems:
> >
> >- What's the purpose of the menu item "Pasquale" (see top shot) ?
> 
> Are you such an idiot or are you just trying to play the troll here?
> 
> It should be obvious to almost everyone that this is not an active 
> menu item but as it clearly says, it indicates that this release is 
> dedicated to Pat ("Pasquale") Villani, who wrote the initial FreeDOS 
> kernel and who passed away last year.
> Why the f*** don't you complain about the "FreeDOS is a trademark by 
> Jim Hall" menu item as well? ...
> 
> >- CWSDPMI, VSM, DOSNTLFN, ... are in
> >- INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
> >ARACHNE, ... are NOT in ... what can you do with it when installed ?
> 
> How about installing whatever software you like to run?...
> 
> Ralf 
> 
> 
> --
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Ralf A. Quint]

At 06:56 PM 1/14/2012, dos386 wrote:
> > [Freedos-kernel] FreeDOS 1.1 released
>
>COOL :-)
>
>http://jafile.com/uploads/dos386/freeds11.png
>
>Problems:
>
>- What's the purpose of the menu item "Pasquale" (see top shot) ?

Are you such an idiot or are you just trying to play the troll here?

It should be obvious to almost everyone that this is not an active 
menu item but as it clearly says, it indicates that this release is 
dedicated to Pat ("Pasquale") Villani, who wrote the initial FreeDOS 
kernel and who passed away last year.
Why the f*** don't you complain about the "FreeDOS is a trademark by 
Jim Hall" menu item as well? ...

>- CWSDPMI, VSM, DOSNTLFN, ... are in
>- INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
>ARACHNE, ... are NOT in ... what can you do with it when installed ?

How about installing whatever software you like to run?...

Ralf 


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[dos386]

> [Freedos-kernel] FreeDOS 1.1 released

COOL :-)

http://jafile.com/uploads/dos386/freeds11.png

Problems:

- What's the purpose of the menu item "Pasquale" (see top shot) ?
- It fails to find any HD (see middle shot)
- Using the menu item "install to harddisk", it starts installing but
  hangs at "commandx" (see bottom shot)

Other:

- CWSDPMI, VSM, DOSNTLFN, ... are in
- INFOPAD, 7-ZIP, UNTGZ, HX/HDPMI32, MPXPLAY, FASM, CC386, FREEBASIC,
ARACHNE, ... are NOT in ... what can you do with it when installed ?

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Robert Riebisch]

Rugxulo wrote:

>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> 
> Why is this using NOVME NOINVLPG? Is it trying to be
> ultra-conservative? Is there a known VirtualBox (or other) bug
> somewhere? Seems odd ... though INVLPG is 486 and VME is 586, perhaps
> you're trying for old 386 compatibility?? (And I blindly assume
> JEMM386 already is aware of when it's safe to use.)

Yes, it's ultra-conservative.

>From Jemm's README.TXT:
Jemm has been verified to run on the following virtual environments:
Qemu, VMware, VirtualPC, Bochs, VirtualBox
However, it might be necessary to set options NOINVLPG and/or NOVME.

Robert Riebisch
-- 
  +++ BTTR Software +++
 Home page:  http://www.bttr-software.de/
DOS ain't dead:  http://www.bttr-software.de/forum/

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[Bernd Blaauw]

Op 14-1-2012 17:59, Ralph Deffke schreef:
> anybody any suggestions for the 1.1 version ?

First thing you can do is modify FDCONFIG.SYS (or CONFIG.SYS) text file 
(EDIT C:\FDCONFIG.SYS) by commenting out the memory drivers, see if that 
works:
DEVICE=C:\FDOS\BIN\JEMMEX.EXE then becomes:
;DEVICE=C:\FDOS\BIN\JEMMEX.EXE

Alternative is to rename AUTOEXEC.BAT to AUTOEXEC.OLD and see if that 
works. Divide by zero usually is EMM386 catching some misbehaviour by 
certain drivers or programs.


Bernd


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[Jeffrey]

Hi Ralph,

This may seem obvious, but have you tried loading each driver individually?
Also try changing the order you load them. If they are chaining interrupts,
  there may be a conflict.

Hope this helps

Jeffrey


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FreeDOS 1.1 boot process ends with "interrupt devide by zero" and system halt

[Ralph Deffke]

Hi


after two nights booting in step mode I can't figure out what driver is causing 
this problem.

FreeDOS boots well in the "NO DRIVERS" option

the message is 

INTERRUPT divide by zero
9D49 C000 3A07 070F 01FC 0017 0111 0002 0008  1464  0070

I will try the 1.0 iso's to see if they work

anybody any suggestions for the 1.1 version ?

cheers
Ralph--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Ulrich Hansen]

Am 14.01.2012 um 00:17 schrieb Rugxulo:

>> In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So 
>> the JemmEx line looks like this again:
>> 
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> 
> Why is this using NOVME NOINVLPG? Is it trying to be
> ultra-conservative? Is there a known VirtualBox (or other) bug
> somewhere? Seems odd ... though INVLPG is 486 and VME is 586, perhaps
> you're trying for old 386 compatibility?? (And I blindly assume
> JEMM386 already is aware of when it's safe to use.)

Like I said, this line is from the FDCONFIG.SYS that the FreeDOS 1.1 installer 
produces. It is the same on every system with FreeDOS 1.1 installed. It has 
nothing to do with VirtualBox.

>>> X=TEST is just a test for checking which UMB areas are (un)safe to use.
>>> 
>>> Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that
>>> works. I've not been able to reproduce your case in VMWARE Workstation 8.
> 
> If VMware doesn't exhibit it, it may be a VirtualBox bug. Remember,
> VBox is not perfect, esp. for DOS, sadly, as it's not a priority for
> them (e.g. D3X extender).

Possibly. I didn't have the time to check the behavior of KEYB and JemmEx on a 
real machine. Maybe the bug is just caused by the way VirtualBox allocates its 
system ROM.

>> I don't really understand why leaving out "X=TEST" in option 1
>> solved the problem too. Testing the UMBs should lead to a
>> more stable behavior of JEMMEX.EXE. Instead it crashed
>> KEYB somehow.
> 
> Dunno, and haven't checked, but I hope we're using latest KEYB 2.01 here.

Yes, KEYB.EXE ver. 2.01 from 18.08.2011

>> It's odd but it's easy to reproduce with any fresh FreeDOS
>> installation on VirtualBox with the default settings (and
>> choosing german keyboard layout).
> 
> Does "default" mean with or without VT-X enabled? Neither is perfect.

At least on my host system, VirtualBox enables it in every new virtual machine 
by default. Disabling it manually doesn't have an effect. Still KEYB crashes. 
To make it work, you have to a) start it with the option "/NOHI". Or you b) 
start JemmEX without the option "X=TEST".

>> If this could be the default in FreeDOS, I think it would help other
>> users. At least the german ones... ;-)
> 
> Well, presumably most German users know to press F8 and manually
> disable stuff if they run into problems (or F5 for clean boot, worst
> case scenario). DOS really isn't that user friendly. Caveat emptor.
> ;-)

Maybe that's why people still like to use it. :-)

I did some further testing and KEYB also crashes for the french, the dutch and 
the spanish users. (BTW: For the polish, it says "codepage not found in 
definition file - 437", so KEYB aborts anyway...). I think we can assume that 
the bug is present for every FreeDOS user that doesn't use an US keyboard.

If we can avoid somehow that an important system driver like KEYB doesn't work 
after a fresh install of FreeDOS 1.1 for many people using a popular platform, 
we should do it.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Rugxulo]

Hi,

On Fri, Jan 13, 2012 at 2:17 PM, Ulrich Hansen  wrote:
> Am 13.01.2012 um 18:54 schrieb Bernd Blaauw:
>
>> Op 13-1-2012 16:11, Ulrich Hansen schreef:
>>>
>>> Description: I have installed FreeDOS 1.1 with german language and 
>>> keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load 
>>> FreeDOS with JemmEx) keyb will crash with the error message:
>>>
>>> Keyboard layout     : C:\FDOS\bin\keyboard.sys:GR [858]    (3)
>>> Critical error: cannot allocate memory. DOS reported error: 8
>>
>> could you try adding "/NOHI" at your KEYB line please?
>
> Wow. This worked!
>
> In AUTOEXEC.BAT I have now a line:
>
> KEYB GR,,keyboard.sys /NOHI
>
> In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So 
> the JemmEx line looks like this again:
>
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG

Why is this using NOVME NOINVLPG? Is it trying to be
ultra-conservative? Is there a known VirtualBox (or other) bug
somewhere? Seems odd ... though INVLPG is 486 and VME is 586, perhaps
you're trying for old 386 compatibility?? (And I blindly assume
JEMM386 already is aware of when it's safe to use.)

>> X=TEST is just a test for checking which UMB areas are (un)safe to use.
>>
>> Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that
>> works. I've not been able to reproduce your case in VMWARE Workstation 8.

If VMware doesn't exhibit it, it may be a VirtualBox bug. Remember,
VBox is not perfect, esp. for DOS, sadly, as it's not a priority for
them (e.g. D3X extender).

> X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched after 
> installation) look like this:
>
> 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
>
> So this is OK.
>
> I don't really understand why leaving out "X=TEST" in option 1
> solved the problem too. Testing the UMBs should lead to a
> more stable behavior of JEMMEX.EXE. Instead it crashed
> KEYB somehow.

Dunno, and haven't checked, but I hope we're using latest KEYB 2.01 here.

> It's odd but it's easy to reproduce with any fresh FreeDOS
> installation on VirtualBox with the default settings (and
> choosing german keyboard layout).

Does "default" mean with or without VT-X enabled? Neither is perfect.

> Anyway, starting KEYB with /NOHI seems to be the more elegant
> and logical solution.
> Thanks!
>
> If this could be the default in FreeDOS, I think it would help other
> users. At least the german ones... ;-)

Well, presumably most German users know to press F8 and manually
disable stuff if they run into problems (or F5 for clean boot, worst
case scenario). DOS really isn't that user friendly. Caveat emptor.
;-)

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Ulrich Hansen]

Am 13.01.2012 um 18:54 schrieb Bernd Blaauw:

> Op 13-1-2012 16:11, Ulrich Hansen schreef:
>> 
>> Description: I have installed FreeDOS 1.1 with german language and keyboard. 
>> If I boot (after a fresh install) with bootmenu option 1 (Load FreeDOS with 
>> JemmEx) keyb will crash with the error message:
>> 
>> Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
>> Critical error: cannot allocate memory. DOS reported error: 8
> 
> could you try adding "/NOHI" at your KEYB line please? 

Wow. This worked! 

In AUTOEXEC.BAT I have now a line:

KEYB GR,,keyboard.sys /NOHI

In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So the 
JemmEx line looks like this again:

1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG

> X=TEST is just a test for checking which UMB areas are (un)safe to use.
> 
> Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that 
> works. I've not been able to reproduce your case in VMWARE Workstation 8.

X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched after 
installation) look like this:

2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG

So this is OK. 

I don't really understand why leaving out "X=TEST" in option 1 solved the 
problem too. Testing the UMBs should lead to a more stable behavior of 
JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to 
reproduce with any fresh FreeDOS installation on VirtualBox with the default 
settings (and choosing german keyboard layout).

Anyway, starting KEYB with /NOHI seems to be the more elegant and logical 
solution. 
Thanks!

If this could be the default in FreeDOS, I think it would help other users. At 
least the german ones... ;-)

regards
Ulrich





--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Bernd Blaauw]

Op 13-1-2012 16:11, Ulrich Hansen schreef:
> This seems to be a minor (but annoying) bug in FreeDOS 1.1: The german 
> keyboard does not work after the install. If I install the US keyboard, there 
> is no problem.
>
> Description: I have installed FreeDOS 1.1 with german language and keyboard. 
> If I boot (after a fresh install) with bootmenu option 1 (Load FreeDOS with 
> JemmEx) keyb will crash with the error message:
>
> Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
> Critical error: cannot allocate memory. DOS reported error: 8

could you try adding "/NOHI" at your KEYB line please? Without quotes 
ofcourse. If that works I'll add it as default. I wasn't aware KEYB was 
automatically added by FreeDOS installer, haven't touched that part of 
code in ages.


> If I choose bootmenu 2 (Load FreeDOS with EMM386) instead of 1, everything 
> works fine and I have all my umlaute back ;-).

Good to know.

>
> Solution: Today I have solved this problem by removing "X = TEST" from the 
> JemmEx line in FDCONFIG.SYS. So the line looks like this:
>
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS I=TEST NOVME NOINVLPG
>
> Bootmenu 1 boots OK now, with keyb not crashing.
>
> Now my question: What do I lose by removing "X=TEST"? Will the system become 
> more unstable?
>
> I experienced this with my VirtualBox installation of FreeDOS. Is it 
> possible, that this is only relevant in VirtualBox? Does anyone else know 
> this "bug"?

X=TEST is just a test for checking which UMB areas are (un)safe to use.

Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that 
works. I've not been able to reproduce your case in VMWARE Workstation 8.



--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb

[Ulrich Hansen]

This seems to be a minor (but annoying) bug in FreeDOS 1.1: The german keyboard 
does not work after the install. If I install the US keyboard, there is no 
problem.

Description: I have installed FreeDOS 1.1 with german language and keyboard. If 
I boot (after a fresh install) with bootmenu option 1 (Load FreeDOS with 
JemmEx) keyb will crash with the error message:

Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3)
Critical error: cannot allocate memory. DOS reported error: 8

The rest seems to boot okay, but of course I have the wrong keyboard layout 
afterwards...

If I choose bootmenu 2 (Load FreeDOS with EMM386) instead of 1, everything 
works fine and I have all my umlaute back ;-).

Solution: Today I have solved this problem by removing "X = TEST" from the 
JemmEx line in FDCONFIG.SYS. So the line looks like this:

1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS I=TEST NOVME NOINVLPG

Bootmenu 1 boots OK now, with keyb not crashing.

Now my question: What do I lose by removing "X=TEST"? Will the system become 
more unstable? 

I experienced this with my VirtualBox installation of FreeDOS. Is it possible, 
that this is only relevant in VirtualBox? Does anyone else know this "bug"?

Thanks! regards
Ulrich 



--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 released

[Marco Achury]

The torrent worked for me, thanks a lot.

I think that torrent protocol is designed to look for a free port.

-- 
--
+-+-+-+-+-+-+-+
Marco A. Achury
Tel: +58-(212)-6158777
Cel: +58-(414)-3142282
Skype: marcoachury
http://www.achury.com.ve





El 04/01/2012 06:11 p.m., James Hall escribió:
>>> And in a few minutes, we'll have a torrent seed, thanks to our friends
>>> at ibiblio.
>>> :-)
>> That's working fine as well, about 3x as fast as http, with only 1
>> peer when I started (myself?, shows 6 peers by the time I was finished).
>>
>> But would be surprised if that would work for Marco, that an ISP
>> blocks FTP but NOT torrent traffic... :-\
>>
> Agreed. Maybe one of the mirrors I mentioned in my other post will
> work for Marco.
>
> Note that I only commented out the list of mirrors. If you view the
> html source of www.freedos.org/freedos/files, you will be able to see
> URLs to all of the mirror sites. I'll re-add the (working) mirrors
> over the weekend.
>
>
> -jh
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user