2009/6/23 Tom Ehlert
> one thing, though: there MUST be the possibility to keep the dates of
>
> the source files to the last change, not the last checkout.
>
> with all files having a date of 22.06.2008 the date is meaningless.
Jeremy, did you try "svn export" to another directory before zippin
2010/2/8 Braden Mailloux :
> I built the kernel with DOS compilers in an NT environment. Afterwards,
> NTLDR disappeared. Related?
It's better to use the NT-hosted compilers in %WATCOM%\BINNT. DPMI
support in the Windows NT family isn't very good (and non-existent in
64-bit Windows).
The example
The newest freedos kernel is up at sourceforge now, at the usual places --
http://sourceforge.net/project/showfiles.php?group_id=5109
you can construct the urls from previous announcements.
The emphasis for this release was on fixing bugs.
short list of changes:
bugs fixed:
- 1712 findfirst retur
The newest freedos kernel is up at sourceforge now, at the usual places --
http://sourceforge.net/project/showfiles.php?group_id=5109
you can construct the urls from previous announcements.
The emphasis for this release was on fixing bugs.
short list of changes:
bugs fixed:
- 1712 findfirst retur
On Thu, 29 Jan 2004, Imre Leber wrote:
> When testing defrag in DOSemu, it seems that i am constantly getting a
> middle mouse button press, (from the int33h handler) even if i don't press
> on the mouse. That is why the menu is so shaky (I don't get the same
> behavior in MSDOS). Does anybody hav
On Tue, 3 Feb 2004, Arkady V.Belousov wrote:
> - with BCC defaults for options may be written in turboc.cfg. How to reduce
> command line in Watcom? Where (in which .ihp file) this explained (if this
> possible at all)?
environment variables or @file
cguide.ihp has this information, look for
On Wed, 4 Feb 2004, Arkady V.Belousov wrote:
> 3-æÅ×-2004 15:17 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
> [EMAIL PROTECTED]:
>
> LG> "_emit" can be replaced by "db",
>
> __emit__ (was) allow to point variable names (including local). Though,
> I don't use this feature and now replace s
On Wed, 4 Feb 2004, Arkady V.Belousov wrote:
> BO> Anyway, -os -s or -oas -s or -oals -s will generally be smaller.
>
> Looks like best (default) should be -obhklrs and sometime with
> -oami[+]-s? Anyway, ATTRIB.OBJ for -obhklrs-oami+-s (almost) identical to
> result with -oxshki+-s.
hmm, I
On Wed, 4 Feb 2004, Steffen Kaiser wrote:
> On Wed, 4 Feb 2004, Bart Oldeman wrote:
>
> > Replacements for malloc() and free() will help; don't forget to define
> > _nmalloc as a malloc caller.
>
> Can you hook into Watcom's heap management? E.g. trace mall
On Mon, 9 Feb 2004, Gregory Pietsch wrote:
> I just checked the source for edlin from the Odin 0.6 package, and it's
> missing various files such as the configure script. Please put these
> files back into the distribution, as they are referenced in the README
> and INSTALL files that comes with t
On Mon, 9 Feb 2004, Gregory Pietsch wrote:
> Well, if you don't want to put the configure script in there, at least
> leave everything else in there so that the configure script can be
> reproduced with standard tools such as autoconf!
well configure.in is at least small :) Anyway it's Bernd's de
On Tue, 10 Feb 2004, David Turner wrote:
> I heard that you were considering a proprietary executable compression
> scheme for FreeDOS. I'm just writing to let you know the licensing and
> freedom implications of this.
Now that you're here anyway ;) I have some questions too:
first of all many F
On Tue, 10 Feb 2004, tom ehlert wrote:
> DT> I heard that you were considering a proprietary executable compression
> DT> scheme for FreeDOS.
> could you explain 'proprietary' ?
>
> is everything non-GPL 'proprietary' ?
proprietary is everything that is (in the eyes of the FSF) not Free
Software.
On Wed, 11 Feb 2004, Luchezar Georgiev wrote:
> There is a very good and easy interactive license selector at
> http://pgl.yoyo.org/lqr/ but I'd still prefer if we compose one of our
> own. More opinions, please!
The FreeDOS kernel is released under the GPL and will remain so. Getting
the agreeme
On Thu, 12 Feb 2004, Luchezar Georgiev wrote:
> On Thu, 12 Feb 2004 09:10:33 +0100, Roberto Mariottini wrote:
>
> > I understand you Lucho, but Bart is right: if it's not possible, then just it
> > isn't.
>
> So, we are (OK, I am) in the trap of our own license! The GPL, instead
> of giving us fr
On Thu, 12 Feb 2004, Aitor Santamaría Merino wrote:
> By the way, I assume from this all that there's no GPL-ed packer. So I
> suppose that according to the FSF agenda this means that, as there is no
> GPL-ed packer, then I have to give up the ussage of packers, better than
> using a closed source
On Thu, 12 Feb 2004, Luchezar Georgiev wrote:
> On Thu, 12 Feb 2004 15:14:40 + (GMT), Bart Oldeman wrote:
>
> > there is a completely GPLed packer, called upx-ucl (the one that you get
> > when you compile UPX and UCL from source). It packs slightly weaker than
> >
On Fri, 13 Feb 2004, tom ehlert wrote:
> as the EMM*.zip archives are selfcontradicting (because they claim to
> be GPL, but aren't) they might crash any GPL-aware OS internal logic.
> please remove them from all open source OS disks before you see a
> kernel panic() ;)
> Exactly my thinking.
> bu
On Thu, 12 Feb 2004, Kenneth J. Davis wrote:
> The 'major components' do not have to be provided _with_ the
> OS, they must be _of_ the OS. Thus one can use any compiler,
> linker, or whatever is deemed a major component of the OS.
true.
> So the even funnier part is about statically linked run
On Fri, 13 Feb 2004, Eric Auer wrote:
> So UPX does not work at all for the "driver EXE" file format.
Right, but UPX is GPLed so we can change it so it will work for the
"driver EXE" format!
Do you expect us to read all your long emails when you can't even read my
short one?
have a nice fortnig
On Tue, 24 Feb 2004 [EMAIL PROTECTED] wrote:
> b) How can I debug those programs from within WinNT? Both the tools in
> BINNT and BINW complain about invalid debugging information. I pass the
> "-d3" option to WCC.EXE and WLINK.EXE gets "DEBUG WATCOM ALL". The
> executable has lots of stuff append
On Tue, 9 Mar 2004, Michael Devore wrote:
> What we need people to do is try EMM386 with any DOS extended program
> they may have available and see how well it works, or not, with
> interactive feedback either way. NOEMS and NOVCPI may be tried for the
> venturesome.
Looks very promising! -- it
Hi Erwin,
> When I add /verbose I see
>'EPROM at c800:, size 0 KB'
> endlessly scrolling by ...
try booting without emm386 and then:
c:\>debug
-dc800:0 2
-q
If it says 55 AA 00 then something is very weird.
I have 55 AA 40 at c000: which means: here's an "EPROM" (video bios)
of 0x4
Hi Erwin,
> > > When I add /verbose I see
> > >'EPROM at c800:, size 0 KB'
> > > endlessly scrolling by ...
> >
> > try booting without emm386 and then:
> > c:\>debug
> > -dc800:0 2
> > If it says 55 AA 00 then something is very weird.
>
> It says 55 AA 01
> Is that "avarage" weird ?
> So
Hi,
I was wondering why we just have release candidates all the time now.
Is the current official FreeDOS still beta8 then?
It looks to me that a better naming would have been beta9rc1: beta9, ...
and then instead of beta9rc4 beta12.
There was a bit of confusion on my side when I understood that
On Tue, 9 Mar 2004, Michael Devore wrote:
> I'm a bit confused on the programs working part of your message. Does
> EMM386 work for you under some circumstances with the extenders or does
> it always fail under all circumstances?
EMM386 works.
All DPMI programs seem to work.
I can enter and ex
> > little high) but what is the real size of your BIOS?
>
> 256k
that's very big -- it's probably not all visible then within DOS or
everything between C000 and would be occupied with no rooms for UMBs.
I should have said "VGA BIOS".
> > Please check:
> > c:\>debug
> > -dc820:0 2
>
> It re
On Thu, 11 Mar 2004, Jim Hall wrote:
> Since you seem to have problems accessing Bugzilla with your NS4
> browser, I've modified the design banner & footer for Bugzilla to
> eliminate the sidebar.
>
> This should work for you now.
>
> CC'ing the freedos-devel list because this is a global change t
On Fri, 12 Mar 2004, Michael Devore wrote:
> If you would, please put this version of EMM386 through suitable tests,
> particularly with protected mode/DOS extender stuff, and let me know the
> results.
Still have the same (exit) problem as last time. Also something weird is
going on with NOEMS n
On Sun, 14 Mar 2004, Michael Devore wrote:
> Looks like they are using another illegal instruction in V86, based on
> the 0F 20 prefix, which I'll have to emulate in EMM386.
In dosemu src/emu-i386/cpu.c we have to emulate a whole bunch. Including
reads and writes of cr*, tr* and dr*, but also rdt
On Tue, 16 Mar 2004, Michal H. Tyc wrote:
> But I have also heard quite long time ago that on many machines you
> can reuse whole 32K at F-F7FFF. I believe. I just never succeeded.
If I remember well around '95 I could do that on my 386SX and there was an
UMBPCI-style shareware program called
On Wed, 17 Mar 2004, Luchezar Georgiev wrote:
> On Wed, 17 Mar 2004 10:54:16 +0100, tom ehlert wrote:
>
> > MKEYB 0.40 released
> > website http://www.drivesnapshot.de/freedos/mkeyb.htm
> > download http://www.drivesnapshot.de/freedos/mkeyb.zip
> >
> > changes:
> > now uses APACK for 200 byte sma
On Tue, 16 Mar 2004, Michael Devore wrote:
> Latest test version of EMM386 is at
> ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and
> EMMSRC.ZIP, as executable and source.
>
> These version corrects a problem with memory corruption in UMB's using
> VCPI, particularly notable with
On Wed, 17 Mar 2004, Michael Devore wrote:
> I suppose I could break up the ZIP to floppy sized units, but I'm not
> real thrilled about trying it. I'd very much rather get the CD problem
> fixed.
don't you have an old ISA network card you can put in the DOS machine?
Then you could copy via a sm
On Wed, 17 Mar 2004, Michael Devore wrote:
> >
> >Duke Nukem 3D reboots the machine as soon as it enters graphics mode. Its
> >setup program (which also uses dos4gw 1.97) works correctly though. DOOM
> >on the other hand works. Will try to run with Causeway and DOS32A later.
>
> I downloaded Duke
On Thu, 18 Mar 2004, tom ehlert wrote:
> >> Neither are most compilers in use for FreeDOS (with the exception of
> >> watcom).
>
> LG> ...and the Borland Museum compilers.
>
> AFAIR, the Borland museum compilers have a license similar to
> 'free for personal use. if you want to distribute compil
On Thu, 18 Mar 2004, tom ehlert wrote:
> JH> What about Pat Villani, who wrote prf.c and portab.h?
> this prf.c was written by the author of mkeyb, NOT pat villani.
yes, prf.c was completely recoded in the early days I started maintaining
the kernel. It's had some more updates from me in the kern
On Mon, 22 Mar 2004, Michael Devore wrote:
> I've tried QuickView Pro and a DOS extended PNG viewer and they both are
> documented as using an LFB and work fine under EMM386, so we're dealing
> with something beyond a simple LFB existence problem here.
that's right. Quake also works in LFB modes
On Mon, 22 Mar 2004, Aitor Santamaría Merino wrote:
> I'd like to ask if someone has successfully compiled UPX/UCL.
yes, but only on Linux.
> of those that I have corrected where due to things such as using
> SYSLIMITS.H not being present (it was SYSLIMIT.H, I guess that to follow
> DOS 8.3 file
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
> > if (hd(pddt->ddt_descflags) && !(pddt->ddt_descflags & DF_CHANGELINE))
>
> Thanks! As hd(x) is #defined as ((x) & DF_FIXED), the above can be
> optimised to:
>
> if ((pddt->ddt_descflags & (DF_FIXED | DF_CHANGELINE)) == DF_FIXED)
Hmm, looks like I
On Mon, 22 Mar 2004, tom ehlert wrote:
> ASM> But anyway, and in order to avoid discrepancies, I'd like to use UPX/UCL
> ASM> if available
>
> Seems GPL forces you to use second best choice
> (similar to choosing LINUX)
Hmm. What's the best choice then? Solaris? FreeBSD? FreeDOS? For whom? :)
Bu
Just wondering, there is duplicate effort involved in having newsitems at
www.freedos.org *and* freedos.sf.net and there's already way too much
boring cannot-be-automated stuff involved for each release. Can't they be
merged somehow?
-- Forwarded message --
Date: Tue, 23 Mar 2004 1
On Tue, 23 Mar 2004, Jim Hall wrote:
> However, there's the issue of placement on the FreeDOS.org page. If I
> include these on the FreeDOS.org main page, I'm afraid the page will
> become *huge*. I can create a sample index page if you'd like to see it
> - actually, that's something I'd like to
On Thu, 25 Mar 2004, Luchezar Georgiev wrote:
> Thanks, Aitor!
> > 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm
> As far as I know, APPEND is considered dangerous and incompatible. It had
> better stay missing.
> I think that SCANDISK is the most important missing program.
it
On Fri, 26 Mar 2004, Michael Devore wrote:
> There was a bug in EMM386. Map multiple pages, EMS 4.0 function 50h,
> was broken. I fixed that and Lemmings runs for me. Cute game, although
> I cannot play well enough to save any of them.
Those poor lemmings :-(
Anyway, just an ACK that all prob
On Thu, 25 Mar 2004, Gregory Pietsch wrote:
> i (insert mode) - implemented. I made the get-out-of-insert-mode
> character a period on an otherwise blank line instead of control-Z
> because the one thing I hated about MS edlin was the use of control
> characters in the syntax. (The period can be e
On Wed, 31 Mar 2004, Luchezar Georgiev wrote:
> > Oops! VolumeSeek() should be loff_t(loff_t offset) instead of off_t
> > VolumeSeek(off_t offset)! But there must be yet another bug, because
> > when I changed it, the bug was still there, although the code generated
> > for VolumeSeek() became cor
On Thu, 1 Apr 2004, Luchezar Georgiev wrote:
> Things like that are Megalo$0ft's favourite "trick"! Here's what Pat
> Villani (the author of DOS/C on which our kernel is based) wrote about the
> Microsoft's love to undocumented features:
>
> > there is constant debate over Microsoft's use of undoc
On Fri, 2 Apr 2004, Arkady V.Belousov wrote:
> 1-áÐÒ-2004 20:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
> [EMAIL PROTECTED]:
>
> LG> Adding *strings* just for information purposes in the precious resident
> LG> space is a bad idea.
>
> Lucho, you blindly skip all my mentions about os_r
On Fri, 2 Apr 2004, Arkady V.Belousov wrote:
> PS: Why you not answer for previous time?
because at this point it seems to interest more people than just
you. I just cannot answer every question, or I wouldn't have any social
life left...
> PPS: Do you report bugs in RBIL (eg, D-216C00) to Ralf?
On Fri, 2 Apr 2004, Luchezar Georgiev wrote:
> On Thu, 1 Apr 2004 21:46:29 +0100 (BST), Bart Oldeman wrote:
>
> > I sent this to Ralf Brown at the time that Matthias Paul did a desperate
> > call for updates because RBIL62 could be released any day (that was in
> > Ap
On Wed, 14 Apr 2004, tom ehlert wrote:
> Hello Michael,
>
> MD> Additionally, if any port 92h related
> MD> lockups happen, I'll move "always-on" to top the A20 test list,
> MD> see if they go away.
>
> *** PRO 'always-on' ***
I think "always on" here refers to machines that *boot* with A20 enabl
MEM 1.5 is up for grabs at http://freedos.sf.net/mem/mem15.zip
User visible changes are:
* implemented mem /c at popular request
* detect EMS memory if an EMS driver is present without a page frame
(with FreeDOS "EMM386 NOEMS"), no longer reporing "EMS Internal
Error".
* made output more MS c
On Sat, 17 Apr 2004, Arkady V.Belousov wrote:
> - bug in .lsm: "Entered-Date: 17APR2003".
Jim, can you correct this in the published LSM? It's a bit pointless to
release mem 1.6 just to correct the LSM date.
> - check_name() uppercases MCB.name. As result, instead "win386" we get
> "WIN386".
On Sat, 17 Apr 2004, Bernd Blaauw wrote:
> and what's with the "add 80KB"?
> FD-MEM: SYSTEM99,536 (97K) 12,480 (12K) 87,056 (85K)
> MS-MEM: SYSTEM 17,600 (17K) 12,480 (12K) 5,120(5K)
>
> FD-MEM: Upper 240K 106K 134K
> MS-M
Thanks for the feedback: MEM 1.6 is now available:
http://freedos.sourceforge.net/mem/mem16.zip
Changes:
* minor output tweaks, don't upcase names anymore
* try to detect UMB holes and don't count them as upper memory
* display UMB holes as "reserved" in mem/f output
* display ver
Thanks for the feedback: MEM 1.6 is now available:
http://freedos.sourceforge.net/mem/mem16.zip
Changes:
* minor output tweaks, don't upcase names anymore
* try to detect UMB holes and don't count them as upper memory
* display UMB holes as "reserved" in mem/f output
* display ver
On Mon, 19 Apr 2004, Eric Auer wrote:
> Hi, as FreeDOS 2034 is out, does it make attempts to fix
> http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1745 ?
> "renaming dir with trailing backslash makes it vanish" which could be
> blamed on shell, kernel or both?
[...]
Eric, anyone can look th
On Mon, 19 Apr 2004, Eric Auer wrote:
> Hi, I could check SOME of the problems, but I assume that you
> already KNOW which of them you have addressed and can give a
> comment about that question on the list first.
Don't assume. Any comments will end up in Bugzilla itself. If there aren't
any it m
On Tue, 20 Apr 2004, Eric Auer wrote:
> This reminds me of the 386 question: How much bigger than the FAT16
> kernel is the FAT32 kernel in RAM (low, umb, hma) and how much of
> this would be saved by optimizing for 386, experiences?
Low:
the drive data tables take 32 bytes more per drive (depen
On Tue, 20 Apr 2004, Arkady V.Belousov wrote:
> Isn't better for Watcom declare call_int2f through "#pragma aux" and do
> "#define network_redirector call_int2f"? Like this:
>
> %ifndef WATCOM
> global NETWORK_REDIRECTOR
> NETWORK_REDIRECTOR:
> ...
> ret 2
On Wed, 21 Apr 2004, Michael Devore wrote:
> At 02:06 PM 4/21/2004 +0800, Johnson Lam wrote:
>
> >Also another application call BLASTER MASTER (Sound editor) also said
> >"EMS Corrupt", I've asked the author, it become free now. I can email
> >or upload to your FTP if you want.
>
> I grabbed Blast
On Wed, 21 Apr 2004, Eric Auer wrote:
> ... which reminds me that when I fail to close() in plain DOS,
> stat() does not reflect current file size while it does in
> DOSEMU redirection drives. The DESIRED behaviour is that only
> after close() the stat() information (directory entry) should
> be u
On Wed, 21 Apr 2004, Eric Auer wrote:
> 2034_16 and 2034_32 are both 8086 kernels.
> 2034_16 supports FAT12 and FAT16
> 2034_32 supports FAT12, FAT16 and FAT32
yes, it's here:
http://sourceforge.net/project/shownotes.php?release_id=231835
also if you run the kernel it will say so in the beginnin
Hi Tom,
On 22 November 2017 at 09:57, Tom Ehlert wrote:
> as a side note: if gcc has no far pointers, its usability as a 16 bit
> compiler is serious limited.
There is one now, finally, since T.K. Chia started working on the IA16
port in June.
https://github.com/tkchia/gcc-ia16/
I managed to co
101 - 165 of 165 matches
Mail list logo
