Hello list.
Here's another release of lDebug (with a small L). This application is
an advanced line-oriented debugger for 86-DOS alike systems. It can be
loaded instead of a DOS kernel (bootloaded), as a device driver, or as a
DOS application. The DOS uses may attach or detach from processes
Hello list!
Today I prepared release 7 of lDebug (small L). lDebug is an advanced
debugger for 86-DOS like systems. It is based on Paul Vojta's and
Japheth's FreeDOS Debug/X, which in turn started out as a clone of
MS-DOS Debug. Like all of these, it operates with a line-based terminal
On at 2023-09-03 20:31 +0200, C. Masloch via Freedos-user wrote:
On at 2023-08-26 16:30 +0200, C. Masloch via Freedos-user wrote:
Hello list,
I finished release 6 of lDebug (with a small L) today. This is my
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn
based on MS-DOS
On at 2023-08-26 16:30 +0200, C. Masloch via Freedos-user wrote:
Hello list,
I finished release 6 of lDebug (with a small L) today. This is my
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn based
on MS-DOS Debug), with some ideas from DR-DOS Debug. The duration since
Hi Jerome,
On at 2023-08-28 17:20 -0400, Jerome Shidel via Freedos-user wrote:
For the most part, that section
on ibiblio is fully automated and basically just requires me to drop a
new version of a package into the appropriate upload directories. The
management software takes care of the
On at 2023-08-28 16:15 -0500, Jim Hall via Freedos-user wrote:
Hi Jim,
I noticed that the file on ibiblio isn't updated yet [1]. Likewise the
FreeDOS Software page [2] linked from the website [3]. Though both of
these list 1.3 in their pathnames, so I'm not sure what the appropriate
action
On at 2023-08-26 11:30 -0500 , Jim Hall via Freedos-user wrote:
Great news, thanks! I've been following the feature request discussion
on the tracker, so it's great to see the new version with the cool new
changes.
There's a lot in this announcement (because so many new features) so I
wasn't
Hello list,
I finished release 6 of lDebug (with a small L) today. This is my
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn based
on MS-DOS Debug), with some ideas from DR-DOS Debug. The duration since
the prior release 5 is back to less than 6 months as opposed to the
Hi,
On at 2023-07-16 09:21 -0500, Jay F. Shachter via Freedos-user wrote:
Esteemed Colleagues:
I have a computer, with an MBR-partitioned disk, that is configured to
perform Legacy boot. Microsoft Windows is installed on three primary
partitions, because that is what Windows does, and every
Hello list,
I decided to push out a new release today of my debugger, lDebug (it
starts with a small L). Besides many bug fixes, the past year brought
some new features, such as some support for a 40-column mode (developed
for my HP 95LX handheld computer), the ability to load the debugger as
On at 2022-07-17 13:32 -0400, Travis Siegel wrote:
On 7/17/2022 7:56 AM, C. Masloch wrote:
On the assumption that DR-DOS is included among the CP/M derivatives,
which would agree with the fact that DRDOS, Inc. did sell DR-DOS 7.xx
(and the shortlived DR-DOS 8.xx) and so had the rights
On at 2022-07-17 13:42 +0200, Liam Proven wrote:
I wrote a story about this on the Register:
https://www.theregister.com/2022/07/15/cpm_open_source/
Bryan Sparks (president of DRDOS Inc, which is still around) has given
official permission for the modification and distribution of "CP/M and
On at 2022-07-17 11:07 +0200, C. Masloch wrote:
Next problem: The cursor always stays in the lower left corner of the
DOS screen. This is sort of documented in the manual [8], but I don't
fully understand it.
The idea was to either wrap at the end of line for a dumb terminal
experience or try
On at 2022-07-16 23:17 +0200, Eric Auer wrote:
Hi!
That sounds like great question to discuss with other dosemu2 experts
including you, as the serial port emu of dosemu2 has to do a large
part of the work in what you want to do, I think? :-)
It may be related to dosemu2 oddities, yes.
Hi list,
I was just about to write to Eric concerning some problems of mine in
using the Terminal program. I figured someone else on this list may also
be able to help with some of these problems.
I received this program from some mirror of Eric's, and mirrored it in
turn on our server [1].
On at 2022-07-07 09:39 -0700, Ralf Quint wrote:
Similar with NASM, where for some weird reasons, they made the assembler
case-sensitive, which I would consider utter nonsense (also among my
griefs with C(++)). And it really bites you if you are trying to link
assembler modules with other
On at 2022-06-30 10:00 -0500, Santiago Almenara wrote:
Hello!
What book or webpage do you recommend to learn some DOS assembler?
Thanks in advance
Santiago
I learned primarily using these methods:
1. Read existing code and try to understand it. Even better, start with
higher-level
On at 2022-03-14 18:47 +0100, Liam Proven wrote:
I don't agree that this feature "makes DOS apps part of the apps on
the computer"
DOS apps (not games but productivity applications) are by nature text
mode apps, with only a few modern exceptions which probably won't work
well on DOSemu anyway.
Hello list,
today I finished release 4 of my libre 86 DOS debugger called lDebug [1].
This release fixes several bugs, including several in the interactive
enter mode (E command), one of which was reported in January to the
original Debug/X project [2]. (lDebug is a fork originally based on
Hello FreeDOS developers and users,
Another 3 months have gone by and here's the next release of the
advanced Debug re-implementation, lDebug, based on FreeDOS Debug. It is
free/libre and builds from source using a toolchain including NASM and a
C compiler.
Like before, there are 5
Hello FreeDOS developers and users,
I decided to push out release 2 of my FreeDOS Debug fork today, nearly 3
months after release 1. It is based on 2008's FreeDOS Debug 1.13 first,
staying with the Netwide Assembler source, though with many of the
changes added to FreeDOS Debug since ported
On at 2020-12-14 07:36 +0100, Mateusz Viste wrote:
Hi Christian,
Your docs seem very interesting! I didn't know about them. Having them
available as AMB books would definitely be very cool.
I am not very fond of HTML as a source-to-be-processed data, but the halibut
thing appears very
On at 2020-12-13 09:15 +0100, Mateusz Viste wrote:
I'd love to have the FreeDOS books in there, too.
https://www.freedos.org/books/
I don't think I have the free time to convert them, but if I sent you
the ODT files, could you convert
Sure, if the books are terminal-friendly (ie. no
On 5/30/20 1:09 PM, Eric Auer wrote:
>
> Hi ECM,
>
>> https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/boot32lb.asm
>> -- also last change 2004. Note that this requires a 386 and doesn't
>> check for it. My take on a FAT32 boot sector loader allows to load
>> FreeDOS
On at 2020-05-29 20:54 -0500, Rugxulo wrote:
> There may have been a bug in older FreeDOS boot sectors requiring
> 186?? But I thought that was fixed (by ecm).
I don't think I ever contributed to the boot sector loaders. I actually
checked but there doesn't seem to be any such contribution.
On at 2020-05-22 07:58 -0700, Ralf Quint wrote:
> And the license kind of disallows to re-use the
> code from the files, similar to that of the DOS 1.x/2.0 source they
> published last year...
That's incorrect. Note that in the blog post they're referring to
"re-open-sourcing" the old MS-DOS
On at 2020-02-18 18:25 +0100, Matej Horvat wrote:
> I have managed to get Mercurial 3.4.2 running on DOS semi-reliably (at
> least for local use) with some modifications. I can try to reconstruct
> the steps needed if you want.
I'd be interested in this. I'm using Mercurial for my own projects.
On at 2019-10-26 03:09 -0500, Rugxulo wrote:
>> I also worked some on an 8086tiny fork of mine recently. There are
>> several bugfixes there, as well as implementing all 186 instructions, so
>> it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/
>
> I tested all of this
On at 2019-10-05 18:49 -0500, Rugxulo wrote:
> "Unfortunately, nasm doesn't run over 8086/8088 processors,and I
> couldn't find a compatible assembler!"
>
> Strange. I was lightly playing with 8086tinyplus (on Windows)
> recently, and I noticed that the (in)famous 16-bit NASM build from
> 2005 of
On 2019-05-09 18:02 +0200, ZB wrote:
> BTW: which macroassembler you prefer?
I prefer NASM. The reason I initially forked lDebug was actually to keep
its source in the NASM dialect. Also, I adjusted the (default)
disassembly display to mostly match NASM's syntax.
Regards,
ecm
Hello,
On at 2019-05-05 18:16 +0200, ZB wrote:
> For testing small snippets of ML code "debug" is quite enough. But the
> disadvantage is that when I try to script it ("debug using files like this example:
>
> a 100
> mov ax,10
> [...some other ML code...]
> [...some other ML code...]
>
On at 2019-05-01 21:11 +0200, ZB wrote:
>> (While we still get DJGPP builds, there haven't been any 8086 builds
>> since 2005's 0.98.39.)
>
> Actually, why? Are all of these programs that large - or there are some
> significant advantages in providing them as DJGPP builds? "Ordinary" x86
> build
I have not posted on this forum in almost 5 months due to the
rather VICIOUS attacks on me by Bret Johnson, Ralf Quint, and
Tom Ehlert re: diskette detection in the UIDE drivers.
However, this post has now become necessary.
A++ would read again
Regards from our Bunch of Trolls That Ruin
Example:
WCD 5.2.0
Erwin Waterlander has released wcd 5.2.0. [...]
has absolutely no info about what the thingie is after all ;-)
I agree. Hmm... I think to vaguely remember what /this/ WCD was, but it's
still not as clear as it could be. In general, maybe append a short
description of
I'll link to the 1.0 boot floppy image, under the FreeDOS 1.0 section.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img
Kernel on that image uses 386+ instructions... and it seems as if it does
that without (properly) checking for the presence of a 386.
Maybe you should reread what I wrote previously:
Right, sorry. I didn't look into that.
grub root (hd0,0)
grub setup (hd0,0)
grub quit
I thought you were referring to how to *load* FreeDOS from within GRUB,
considering how that was the topic previously. But that's of course
installing
* DOSBox ... sure, it's only for games and is really its own fake
DOS, but it sorta works and is free/libre, popular, and easy to find
binaries.
I wouldn't specifically include DOSEMU because it needs a real DOS,
DOSBox can also boot an actual DOS version (like dosemu always does),
which
On a semi-related note, I think you can boot Win 3.x inside DOSEMU,
DOSBox, etc. Even Mike Chambers' Fake86 can (mostly) boot it. There
may even be some experimental support on some of those for booting
Win9x, but since that's uninteresting to me, I've never delved deeper.
This is irrelevant
I think it still did use DOS file system calls, but I could be wrong.
It circumvented DOS for higher performance if no DOS software was
intercepting or handling the FS and block device functions (from DOS Int21
API through DOS block device down to ROM-BIOS Int13 API), at Windows
start-up.
Is DosEmu actually capable of working with Portuguese
diacritics and supporting a standard Brazilian keyboard in
the first place?
It's probably possible, but it might require configuring dosemu more, or
maybe even patching dosemu's source.
And if DosEmu can't do it,
Again, this was purely marketing, not technical, as MS wanted to
exclusively bundle their DOS with Windows. With (very creaky) shims,
DR-DOS was said to be able to boot Win95 (and proved such in court),
Where and when was that? This lawsuit was never brought to trial in
the first place...
I read the announcement in July that Grub 2.00 supports FreeDOS.
So does Grub Legacy, [...]
As opposed to GRUB 2, it additionally needs setting up the correct boot
sector file (to be chainloaded from GRUB for loading the kernel), which is
possible using FreeDOS's SYS.
There's a fork
Where neither source mentioned that there was anything proved in
court, as there was never a trial on that matter.
Right, it wasn't. So the rumour part was _only_ the mention of proved in
court, which it didn't quite reach. But it isn't a rumour at all that
MS-DOS 7 and 8 were unnecessarily
grub root (hd0,0)
grub setup (hd0,0)
grub quit
Oh so difficult,
That also requires the boot sector to /already/ be set up correctly, just
in the partition itself this time =)
shenanigans, and 5-10 times the HD space sprawled across several
directories and/or partitions, required to make
A:\ SYS C:
[...]
A:\ FDISK /MBR
Yep, you successfully circumvented GRUB now =P
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and
why does the line
unlike the old ms dos freedos lets you access fat 32 file systems
appear?
fat 32 file systems existed in ms dos about 1997 or so.
I have fat 32 partitions on my ms dos system in fact, and there is no
windows on my computer whatsoever.
While there are likely many things
Yes, Win95 OSR (or whatever) introduced FAT32 later on, but it wasn't
in DOS per se,
This does not accurately describe the technical circumstances.
If we were to discuss LFNs, in that case the MS-Windows-bundled DOS
versions alone did indeed only provide rudimentary help and application
still the point is as you shared yourself, might be understood to mean
older stand alone ms dos, it might not as well. be understood..that is.
I agree.
for my part, the edition of ms dos 7 i run was packaged by developers
much like yourselves.
I maybe would personally prefer not to be
Hi Karen,
Does freedos have its own long file name utility?
If so, is it close enough to ms dos to be run?
Just curious, the person I know seeking it says they are running freedos,
but they are using the old ms dos 7.1 lfn command.
Made little sense to me, unless there is no specific freedos
This seems a poor way do discover what I see in the initial fdconfig.sys
file created by the FreeDOS installer, which is very broken and useless
I think the FreeDOS 1.0 installer wrote a menu for these choices, which
was more useful. If the new installer left you with no menu display by
There is also Dissecting DOS, ISBN: 0-20162-687-X, by Podolsky;
Without commenting on my opinion of the book or RxDOS; no, I don't think
the author's named Podolsky ;)
Regards,
Chris
--
Live Security Virtual
Podanoffsky, isn't it? :)
Yeah. At least my copy does have Michael Podanoffsky on it! =)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has
If code is released to the public domain, anyone can use it
without restriction.
Right.
But there would be no license to protect us, to keep someone like
Microsoft from copying our code, and re-releasing it as their own
under a proprietary license.
Yeah, that's a subset of anyone can use
I just ask that you choose a license that preserves the freedom
of the source code, so that everyone may use it and contribute to it.
Rhetorically speaking, MIT-style licences could be read as not preserving
the source's freedoms as much as licences with copyleft (such as the
GPLs). (Note
~Warning~: Pedantry ahead. Only read on if you dare.
(Then again, if you read more than eight bits of my past contributions,
you probably already recognised that I'm a proud and unapologetic pedant.)
Other licenses may be more free in that they have less restrictions,
including the copyleft.
I agree, I'm certainly overly pedantic and unreasonable and silly.
And you're the one using the term intellectual property as if that was a
coherent concept.
=)
--
Live Security Virtual Conference
Exclusive live event
lol
--
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
I'm not sure if this is a bug, misfeature, lack of testing (re:
FreeDOS specifically vs. arcane dark corners of MS-DOS), or user
error.
You don't need to be sure, because I am sure enough what it is.
And what it is, is completely broken file system semantics. Nothing to do
with arcane dark
In very rare cases only, though.
Irrelevant.
Admittedly nobody wants corruption, but I don't think most people rely
on deleting open files (except POSIX, so it's probably only a problem
when porting GNU stuff to DJGPP).
Inaccurate. RBIL's notes seldom refer to programs that target POSIX.
FWIW, I use MS-DOS on a daily basis instead of FD for reasons like
this. MS-DOS is, by far, the most stable of the DOS's, and is still the
minimum standard to which others must compare. I would classify
possible file corruption as a major problem, not a side issue.
You do always load
No, not by default. According to the official documentation (e.g.,
the MS-DOS on-line HELP utility), you only need SHARE in a network or
multi-tasking environment, which doesn't apply to my current situation.
Then the particular problem in question is generally not a reason to
prefer
Recently there was a thread
about concurrent file access in the network - apparently FreeDOS
SHARE and kernel support for it are not as good as in MS DOS
... where this not as good support apparently amounts to may corrupt
your file system when concurrent write access occurs. This,
conclusion: don't use FreeDOS as a 'server' machine.
Sure, that's the obvious easy way out.
But wouldn't it be better overall (and wiser) to 1). actually find
out what MS-DOS does, and 2). fix it in FreeDOS' kernel?;-)
If you are indicating that you want to volunteer... ;-) (... if that
Thanks. Here's some comments if you care to read them. Not all of them are
particularly relevant to our thread's topic.
MSDOS, and presumably FreeDOS, does not natively provide a framework for
safe filesharing and file locks, this needs to come from the server
software
working in
if the answer to 2) is 'FreeDOS' then either SHARE.EXE is not running
or SHARE.EXE is buggy. the latter is quite likely as it was never
really tested against network access.
I think SHARE.COM must be running because the two-computer test
network works perfectly -- as long as the two users
Hi Tom,
This might be irrelevant to the case at hand.
if the answer to 2) is 'FreeDOS' then either SHARE.EXE is not running
or SHARE.EXE is buggy. the latter is quite likely as it was never
really tested against network access.
If you know; does FreeDOS's file locking (ie SHARE) propagate
However, I get a warning on boot: InitDisk Warning: using suspect
partition Pri: 1 FS 0C with calculated values 970-42-42 instead of
1018-8-40. I've tried partitioning the disk with different CHS values,
but it always complains that the calculated values are different than
those other
Hello Henry,
One of the steps of the
howto says to edit autoexec.bat changing the line REM LH PCNTPK
INT=0x60 to LH PCNTPK INT=0x60. This didn't work for me. Somehow the
packet driver was never actually loaded on startup. What did work is
changing the line to PCNTPK INT=0x60 without the LH.
Problem I see is, the OS used is freedos and the disc costs $34.95 to
activate. [...] Is the way freedos is being used here legal, or have I
discovered an abuse?
If they provide all required sources (ie of GPL- or similarly-licensed
programs) along with their discs, it is legal. Free
it's drive
letter correctly using the find utility.
So... how exactly doesn't it work then? Is the file created? Is it called?
(Try to insert some echo commands into the batch script and check whether
they're visible.)
regards,
C. Masloch
. Your case, as I understand it, would be a special case to
circumvent DOS's FS driver's limits.)
regards,
C. Masloch
--
Try before you buy = See our experts in action!
The most comprehensive online learning library
if the
file system structures (reserved sector number, FAT size, root size. And
the cluster size must be = target's sector size) are properly aligned; as
you implied.
regards,
C. Masloch
--
Keep Your Developer Skills
now, but as I remarked in the previous paragraph, an
upwards transformation could be /to/ 512 B if the stored file system
(whether it is stored on some physical medium, in a file as an image, on a
RAM disk, etc) uses smaller sectors.
regards,
C. Masloch
Another additional note, as I went thinking about this a bit. Only
cluster values are stored in the FS (think FAT contents, FSINFO, and
start cluster fields of directory entries) apart from what is in the
*BPB, so a runtime upwards sector size transformation (say, from 512 B
to 4 KiB,
with
sector sizes 512 B in a DOS that doesn't support such sector sizes. The
FDK appears to almost or entirely support such smaller sectors properly
already though. (They are much easier to implement than larger sectors,
requiring no special larger buffers.)
regards,
C. Masloch
...
That doesn't even figure into it though, as I am not aware of any
assemblers or interpreters (yet) that would directly read a command of the
form Intxx.yy... to execute it.
Regards,
C. Masloch
--
Keep Your Developer
!
This can be easily extended to 32-bit registers in the same manner as the
extension from 8-bit registers to 16-bit registers when necessary.
Regards,
C. Masloch
--
Keep Your Developer Skills Current with LearnDevNow!
The most
77 matches
Mail list logo
