Some web searching has yielded no useful results for my query.
I'm considering developing some graphical programs for FreeDOS, but I'm
not sure what graphics APIs are available and documented for it.
My expertise is in C, but if I can achieve it in Pascal, I'm open to
getting deeper into it.
I have some modifications I'd like to make to PowerPaint as hosted on
the FreeDOS archives, but I'm unable to compile the source. I'm
attempting to use FreePascal to do the job, but it's failing to compile
some of the units due to assembler syntax errors.
I can't exactly tell what the problem is;
.org www.fsf.org
On 07/29/2016 11:04 PM, Rugxulo wrote:
> Hi,
>
> On Fri, Jul 29, 2016 at 10:45 PM, David McMackins <cont...@mcmackins.org>
> wrote:
>>
>> Indeed, the msdos target exists, but it's not in the distribution on the
>> FreeDOS host.
>
> Go32v2 (3
, Rugxulo wrote:
> Hi,
>
> On Fri, Jul 29, 2016 at 7:52 PM, Ralf Quint <freedos...@gmail.com> wrote:
>> On 7/29/2016 5:04 PM, David McMackins wrote:
>>
>>> I have some modifications I'd like to make to PowerPaint as hosted on
>>> the FreeDOS archiv
I was thinking the same thing. I've been writing my own set of UNIX
tools for DOS for personal use. I've written cat, head, wc, and split,
and I've made my own implementation of getopt which uses DOS-style flags
(begin with '/', use ':' to separate flag from argument) called
getswitch. I used WCC
But isn't bcc proprietary, thereby undermining the entire goal here?
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On 11/18/2017
On 10/29/2017 09:36 PM, Ralf Quint wrote:
> MS/PC-DOS predates the FSF, GPL and the Stallman virus. DOS itself (in
> pretty much any incarnation, up to and including FreeDOS itself) has
> always been depending on "less-than free" development tools.
So what? UNIX was 100% proprietary when it was
On 10/29/2017 11:00 PM, Ralf Quint wrote:
> Well, I happily invite you to provide us with a free development tool
> that will work in our case and fits your (IMHO) overly idealistic POV.
I'm the one who started this mail chain. It started as a mere inquiry
(on behalf of a friend, really) as to
Interesting! Thank you for researching this. Sadly, this guy's program
is just a binary. I would be curious to read it and see exactly how he
did it. I would like to implement a function to test if this works so
that programmers can use it when available or otherwise use polling.
The big concern
24, 2018, 9:50 AM David McMackins <mailto:cont...@mcmackins.org>> wrote:
>
> I suppose I could do that. I left them together for the simplicity of
> the build script.
>
> What if I added a deploy script that created separate distributions for
>
www.eff.org www.gnu.org www.fsf.org
On 06/24/2018 03:23 PM, Jim Hall wrote:
>> On Sat, Jun 23, 2018 at 8:09 PM, David McMackins
>> wrote:
>>>
>>> Finally, I also wrote a program called the Multi-Disk Split Archive
>>> Installer (MDSAI) which is an i
I've noticed that PASSWORD is written for FreePascal, but the executable
in the distribution is only 8k in size. When I compile myself, it is
60k. How is it being stripped to that small size?
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
In my playing about with FreeDOS, I wrote my own versions of cat, head,
wc, and split.
For these, I also wrote a small library for parsing command-line options
in a typical DOS-like fashion.
Finally, I also wrote a program called the Multi-Disk Split Archive
Installer (MDSAI) which is an
I'm new to graphics programming on DOS. My experience programming
graphics on PC is on modern systems where I can use a library that
handles all low-level calls for me. I know about Allegro, but it's kind
of fat and I don't think it supports 16-bit.
Anyway, I'm figuring out VGA and VESA graphics
I have been informed that gcc has a -m16 flag that actually outputs
binaries that can run in 16-bit mode. Is there then anything stopping
FreeDOS from being compiled fully with gcc?
If not, why are we still using Watcom?
Happy Hacking,
David E. McMackins II
Associate Member, Free Software
Might pop by #freedos on there at some point if other people go there
:)
I idle in there. I had asked before if anyone on the mailing list was
there but it appeared no one was.
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate
(#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On 07/28/2018 12:31 PM, Mateusz Viste wrote:
> On Sat, 28 Jul 2018 11:49:42 -0500, David McMackins wrote:
>> Is there a way to allocate a buffer in O
Perhaps I should clarify that by "buffer" I just mean some space on the
heap allocated via malloc()
Forwarded Message
Subject: Re: [Freedos-devel] Larger buffers in Watcom
Date: Sat, 28 Jul 2018 18:55:31 +0200
From: Eric Auer
To: David McMackins
Hi Dav
Is there a way to allocate a buffer in OpenWatcom that is larger than
64k? I'm currently trying to stay within the compact memory model, but
even if I compile for huge memory model, I'm getting an out of memory
error for trying to allocate about 80k for a buffer. My machine has 128M
of memory, so
While I was doing something else, I went on a tangent that led me to
look at the FreeDOS EDIT source code. I noticed some problems.
The first of these problems is that it appears at first glance EDIT has
a build dependency on Borland C. At least, there isn't a build script
for any other compiler.
ese to the
> open source tools.
>
> On Sat, Aug 11, 2018, 9:45 AM David McMackins <mailto:cont...@mcmackins.org>> wrote:
>
> While I was doing something else, I went on a tangent that led me to
> look at the FreeDOS EDIT source code. I noticed some problems.
>
&
And that means you still have to pay
$59 to get the source code for the compiler, which I think, regardless
of license, doesn't really qualify as ' more "free" than
OpenWatcom'...
Not really. If it's under a free (as in freedom) license, then only one
person (or many pooling together) needs to
/25/2018 04:15 PM, Ralf Quint wrote:
> On 8/24/2018 4:48 AM, David McMackins wrote:
>>> in that case, you are showing acute symptoms of stallmanitis.
>> You can use slurs all you want. I'm citing an accepted definition to
>> clear a misconception. By the way, I don't even like Rich
m
www.eff.org www.gnu.org www.fsf.org
On 08/25/2018 10:21 PM, Ralf Quint wrote:
> On 8/25/2018 4:22 PM, David McMackins wrote:
> ...
> Sorry David, but you are naive at best. And I leave it at that...
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivi
t for decades.
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On 08/24/2018 01:39 AM, Ralf Quint wrote:
> On 8/23/2018
> in that case, you are showing acute symptoms of stallmanitis.
You can use slurs all you want. I'm citing an accepted definition to
clear a misconception. By the way, I don't even like Richard Stallman,
and I won't be part of the FSF much longer. FreeDOS claims to be a free
system with all
I've discovered something weird (to me). I'm on a 1998 Sony Vaio with a
Pentium 3 processor running FreeDOS 1.2. I have a test program which
draws 64 full frames to the screen via VGA mode 13h. Each frame is a
different color to force a full redraw. In addition, I draw a 1-pixel
mouse cursor onto
ackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On 07/20/2018 01:17 AM, Ralf Quint wrote:
> On 7/19/2018 12:34 PM, David McMackins wrote:
>>> so basically you want to find out how fast you can
>>> update blocks of 64 000 pixels
>>
>> I never said t
be useful.
On Mon, Jul 16, 2018 at 9:08 AM, Mark Olesen
wrote:
https::/gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [2]
On Mon, Jul 16, 2018 at 4:51 AM, David McMackins
wrote:
I'm doing some graphics programming, and I want to support many
different graphics modes, but I need a way of checking
I was replying to Jerome who is the original author of the Pascal one.
I get that VGA is widely available. I'm writing a library, so I want to
support as much as possible. My intended targets (in the order of
planned implementation) are VGA, VESA, CGA, and EGA. I want to have
contained tests
If you think you can do ti with subtraction and bit-shifting (without
requiring MMX or something similar) please show it to us.
With multiplication:
new_mask = color & alpha_mask;
new_mask >>= 6;
new_mask *= 0x7F;
Without multiplication:
new_mask = color & alpha_mask;
new_mask <<= 1;
I have two oppositions to this. First, I'd like to be able to do this in
pure C. Second, this appears to be a byte-level operation, but the whole
point of doing this is to work on multiple bytes simultaneously.
I think I might be able to do it with a subtraction and two bitshifts,
though.
>>> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
>>>
>>> Where mask1 and mask2 are the negated forms of each other.
>
> That one only works for boolean masks, but it works on 386.
By boolean mask, do you mean something like all 1s over the colors for
opaque and all 0s for
> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
>
> Where mask1 and mask2 are the negated forms of each other.
> This even works for alpha masks:
>
> 2) new pixels = (old pixels "*" mask1) "+" (new pixels "*" mask2)
I understand what you're going for in principle, but I'm not sure
I'll take a look at that. An idea I came up with last night while I was
asleep was a method that uses my current encoding.
With 4 pixels loaded in a 32-bit register:
AND the input pixels with the alpha mask
SHR this result so that the bit is in position 0
Multiply so that this bit is expanded to
The multiplication does appear to be costly indeed. I'm now trying to
find a way to get around it. I'll explain the method using a 1-byte
example, but the logic scales up:
Our dear color:
0100
^ the alpha bit
Alpha mask:
0100
The color on screen doesn't matter, as will be
> Your definition of "force full redraw" sounds odd. What
> should be forced by that? A graphics library? Hardware?
I suppose I'm not explicitly forcing, but since every pixel on the
screen is being changed, it shouldn't be something weird where the
hardware is not actually doing what I ask as an
hat hardware are you doing this on? Have you seen Allegro? [0][1]
[0] http://liballeg.org/stabledocs/en/index.html [8]
[1]
https://github.com/liballeg/allegro5/releases/download/v4-2-3-1/all4231.zip
[9]
On Thu, Jul 19, 2018 at 5:42 AM David McMackins
wrote:
Your definition of "force full
so basically you want to find out how fast you can
update blocks of 64 000 pixels
I never said that. I wanted to find out why my frame rate was dependent
on the mouse activity.
You probably want to optimize that copying routine.
Game programmers would at least use MMX to do the
alpha checks
On 2018-07-16 10:11, Mark Olesen wrote:
https://github.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [9]
On Mon, Jul 16, 2018 at 9:08 AM, Mark Olesen
wrote:
https::/gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [8]
On Mon, Jul 16, 2018 at 4:51 AM, David McMackins
wrote:
I'm doing some
Yeah, seems he wants the program to write itself via "contributions".
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On
I'm trying to link a program as a COM executable, but when I add the
"format DOS COM" directive to the linker, it complains that libraries
aren't available (such as clibs.lib). It works fine and produces an EXE
if I leave out this directive. What's really happening?
Happy Hacking,
David E.
On 07/07/2018 12:49 PM, Ercan Ersoy wrote:
> I think FreeDOS needs a 16 bit calculator program.
Is FoxCalc not 16-bit?
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org
It is good idea. Will this BASIC environment be compatible BASICA?
Maybe eventually. Sounds like a good goal, but I care first about
minimal BASIC and shell access, then I can consider extensions.
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation
I think I'd go with "basica" for a GW clone, simply because it's what
a lot of batch files will expect. (And "GW-BASIC" is trademarked.)
Or you could just add an alias to your AUTOEXEC.BAT file.
---
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation
As someone who would like to write code that can be easily understood by
users of other 80s computer systems, I prefer to write my scripts in
BASIC. I've been using Bywater BASIC from the FreeDOS distribution, and
it's quite good up until you want to start considering the outside world.
In my
Yeah, 4DOS is another one that I think should be removed. If I remember
right, it has something in the license about commercial usage which
makes it nonfree. In the interest of making rare software available, I
think it would be fine to continue hosting it on the server, but it
should not be
, so this isn't my area of expertise.
But Free BASIC is 32 bit. So I think bwbasic is the only one that
meets your requirements.
On Wed, Jul 11, 2018, 5:50 PM David McMackins
wrote:
As someone who would like to write code that can be easily
understood by
users of other 80s computer systems, I
Will the BASIC interpreter comptiable Microsoft QBASIC?
I wish this BASIC interpreter is QBASIC.EXE for FreeDOS
for compatibility. It's name may be "FreeQB".
Eh, we may have different goals here. I'm looking for something closer
to ANSI BASIC (actually I'm thinking of basing mine on ECMA-55
x workalikes are here:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
>
> Thanks!
> Jim
>
>
> On Sat, Jun 23, 2018, 10:57 PM David McMackins <mailto:cont...@mcmackins.org>> wrote:
>
> In my playing about with FreeDOS, I wrote my
o, 24 de junio de 2018, 11:41:01
> Asunto: [Freedos-devel] FreeDOS PASSWORD executable size
> Archivos:
> --====----=======--
>
> On Sat, 23 Jun 2018 21:09:17 -0500, David McMackins wrote:
>
> *> I've noticed that PASSWORD is written for FreePascal, but the executable
>> in the
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
>
> On Sun, Jun 24, 2018, 6:01 AM David McMackins <mailto:cont...@mcmackins.org>> wrote:
>
> I've hosted the source code here:
>
> https://mcmackins.org/dl/dos/UTILSSRC.ZIP
> ht
I noticed the PASSWORD program puts password attempts in plain text into
its log file. This is dangerous if the user only barely miskeys their
password and another user reads the log file.
I made a modification to only say which user was attempted. Patch file
included.
Happy Hacking,
David E.
in FreeDOS.
David McMackins
Sent from mobile
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Yes, thank YOU Jim and all the long time devs who made FreeDOS a thing
we can enjoy today. I've learned a lot and had quite a bit of fun so
far, and I'm looking forward to making some contributions of my own to
the community.
Happy Hacking,
David E. McMackins II
www.mcmackins.org
There really isn't going to be anything Qt-like for DOS. Qt is built around the
existence of a display server which isn't really a concept in DOS.
Theoretically it could be done in protected mode, but I don't know of anything
that does this.
Your best bet is going to be C or C++ and just do
56 matches
Mail list logo
