Hello all,
DISCLAIMER: I have only minimal understanding of DOS internals, so don't
count on what I write being accurate; it reflects a year of superficial
reading.
Anyhow, I would never see the bug DOS386 mentioned because
1. I haven't used that much space; most of my DOS drives are 2 GiB
2. I
Hello Pat, Eric, and everyone else,
Clarification:
Formerly, Ikon was sold as an OS (for a short period from September to
November this year), with the FreeDOS kernel and some other GPL code
included in binary form. The source for GPL programs was available as a
separate download.
The Ikon GUI
Your Nov 15 build (http://www.fdos.org/kernel/sys/sys.com) works here,
while the last build (Nov 13) still had the bug. So I guess you fixed it;
the only question is what changes made the difference.
I tried sys with these options:
c: c:\large.bin
d: d:\small.bin /bootonly
c: large.bin /bootonly
Hello everyone,
First, I have a bug report against the 1497 fdos.org build of sys
(OW386/FAT32/UPX)--
if I specify a file to write the bootsector to (sys c: large.bin, with or
without /BOOTONLY or /BOTH), sys crashes with Invalid opcode at 00AB
(etc.)
System halted
(no drivers, HimemX, or Jemmex)
Hello all,
I have a slightly outdated disk (~1 month) 1.44M image here:
http://cid-f785bf5e55218c8e.skydrive.live.com/self.aspx/.Public/DOS/fdboot.img?ccr=6115lc=1033
for details, or
Hello all,
I've tried the 1495 automatic build (OW, 8086, FAT16) and there are no
_major_ regressions--in other words, the standard stuff still works. It
is bootable via grub4dos (have not tried any native boot sectors yet), and
here's what I've loaded (or run):
JEMMEX
LSL (NETWARE 16-bit)
RTEODI
Eric:
Thanks for telling where to find the minimal OW--versions are 1.3 (16bit
targets), 1.7a (not downloaded), and 1.8 DOS only--20+ megs (I think-not
downloaded).
(Also on the page--DJGPP small versions; to kernel builders: IGNORE THESE)
For what it's worth, Borland C++ 5.5 may not be able to
Hello all,
In another forum
(http://www.bttr-software.de/forum/forum_entry.php?id=6773), I ran across
a discussion of GPL vs. BSD-style licenses. While I personally find the
GPL satisfactory, one clause allows relicensing by the author.
In the discussion I refer to, relicensing was mentioned. I
Jeremy:
The FAR printf is probably good for 16-bit builds with DEBUG defined.
However, there are at least two potential issues (NOT YET VERIFIED).
1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past
4GB. I don't know how the compilers treat FAR in these builds.
2.Low
Hello all,
It is true that no DOS provides pipes. HX makes up for this by creating a
new file and opening 2 instances (1 read only)--per the HX docs that I
looked at on Sunday. If SHARE is not loaded, this ostensibly may not
work as expected.
Christian:
Is your file sharer ready yet (able to
Hello all,
1470 builds and works fine (not much testing done though).
cd \ works again
(resources handled correctly) from Christian's test program.
HDPMI (HX 2.15 dpmi server) loads.
Regarding the patch I saw mentioned, here's the thread:
Hello all,
Regarding Win--yes, I did just use the WIN option for build.bat.
A trick I just tested today: you can boot multiple kernels in parallel via
grub for dos (eg,
title Boot FreeDOS
root (hd0,2)
chainloader /kernel.sys
title FreeDOS second kernel
root (hd0,2)
chainloader /ktc18616.sys
)
Hello all,
I've been trying to patch 2039-svn with Christian's fix, while working
under a TC 186/FAT32/Win kernel (built myself), and I have found the
following:
1. Code changed. In other words, the
if (!tsr)
line referred to seems to not exist (per TC find, and visual inspection)
2. BUG!
Hello all,
I finally tried to build FreeDOS myself.
It works better than I had imagined possible! (having seen Linux)
The hardest part was to find a 16-bit NASM.
I have used TurboC because
1 I already have it,
2 OpenWatcom would take too long to download at~78 mb,
3 OW is too large for the 256 mb
Hello,
DOS386: Sorry for being rude.
Anyhow, when I tried running the old GEMXM under pre-2038rc2 kernels, I
got the same sort of ARF bug--while GEMVDI.EXE was the running
application. This seems to imply that either this is a common application
bug or else the kernel has some obscure code which
Hello all,
1. I have checked out the latest build (kernel 2038-32). It works fine
with GEM/XM. (So did the 2nd RC.)
2. Congratulations on a great kernel/OS
3. PLEASE stop the flame wars--the last few digests have looked rather (?!)
4. I would rather see more of the features from 2037 in stable
Hi Pat,
I would say 2038 as default, 2037 (including winkrnl) as option--unless
2039 shows up first (doesn't look likely). If 2039 gets something
worthwhile, 1.11 is an option.
Thank you,
ibidem
--
Crystal Reports -
Hello:
1. The updated GEM/XM is what I run. It simply was hacked to autofail
on FCB errors.
2. I am unfamiliar with debugging, asm, programming, etc. I just know
some tools.
3. LOAD.ASM is part of the missing source for GEM/XM. It was lost
before release under the GPL.
4. It is indeed a branch
Hello,
I've tried running GEM/XM under freedos kernels 2035b, 2036, 2037, and
Christian experimental build (later renamed 2038pre). Official
documentation says it will not work due to using FCBs to read the driver
loading file, 'ASSIGN.SYS'. GEM/XM complains about assign.sys, then
dies. So I
Hello,
I tried 2038rc1svn out _briefly_. It works about the same as prior builds
(runs edit, mem, command, gem; loads ctmouse, gcdrom, himemx,jemm386,
shsucdx; still does not run GEM/XM).
If anyone else wants to test GEM compatibility, I would suggest
downloading the OpenGEM SDK from Sourceforge
20 matches
Mail list logo
