Re: [Freedos-devel] Where is the source code?

[Danilo Pecher via Freedos-devel]

Probably the best DOS programming channel is root42:
https://www.youtube.com/@root42

He also has other retro computing stuff going on, but he does an good
lot of videos on DOS programming as well.

Cheers, Hippo

On Wed, 8 May 2024 at 17:57, Jim Hall via Freedos-devel
 wrote:
>
> On Wed, May 8, 2024 at 10:28 AM Bernd Böckmann via Freedos-devel
>  wrote:
> >
> >
> > > I like that idea. I think a good place to add these would be in the
> > > "Technical information" section on that page, maybe as another row of
> > > "info boxes" before (or after? not sure) the row that has RBIL, VGA
> > > programming, and the Graphics Programming book.
> >
> > I would put it below Technical Information as another row.
>
>
> Sounds good! I'll probably use this as a comment right before it:
> "Looking to get started in DOS programming? These YouTube videos show
> you how to write your first programs:"
>
>
> > > What are some good YouTube channels about DOS programming that I
> > > should point to?
> >
> > I like the following playlist. He uses Turbo C, PowerBasic, NASM. While he 
> > does it on DosBox, the skills are transferable. Be aware: heavy german 
> > accent :)
> >
> > https://www.youtube.com/playlist?list=PLGJnX2KGgaw2L7Uv5NThlL48G9y4rJx1X
>
>
> Thanks for that! I'll be sure to include that one.
>
> Anyone else have other recommendations?
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Where is the source code?

[Danilo Pecher via Freedos-devel]

Not to put too fine a point on it, but may I point out that your mail
comes across as somewhat rude? As for your answer: Had you even
bothered to install FreeDOS before kicking up a fuzz, you would have
known that the source code is included in it.

Cheers mate

On Wed, 8 May 2024 at 03:47, Green Fog via Freedos-devel
 wrote:
>
> I neither can find the source code in www.freedos.org or sourceforge.net. Is 
> this an open source project or not? I highly suggest that the source code 
> download link to be included in your main page.
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FETCH4FD

[Danilo Pecher via Freedos-devel]

Neofetch is a good way to give you a quick overview of the machine's
parameters. It's perhaps more of a gimmick under DOS, but in a unix
environment it can be a godsent. When I was database administrator at
Infineon I had to work with about 3000 different machines running
either Linux, Solaris, AIX or HP-UX. So you have 3000 different
hostnames to ssh into. Some you visit almost daily, but some test
servers or legacy systems you only visit once in a very long while.

In that case it is more than helpful to have the most pertinent
parameters at a glance right after login.

cheers,
Hippo

On Fri, 22 Mar 2024 at 02:53, Jerome Shidel via Freedos-devel
 wrote:
>
> Hi
>
> > On Mar 19, 2024, at 6:33 PM, Ladislav Lacina via Freedos-devel 
> >  wrote:
> >
> > Hello!
> > I write own port of utility NeoFetch known from UNIXes.
> > [..]
>
> Never used NeoFetch.
>
> What is it for?
>
> Looking at the screenshot and features you listed, my guess is it reports 
> some general system information.
>
> Like RAM, CPU and Drives.
>
> :-)
>
> Jerome
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] DX-FORTH?

[Danilo Pecher via Freedos-devel]

Used not is it.

As far as I know there is no component or application for FreeDOS
that's developed in Forth. But it should be perfectly useable under
FreeDOS, so if you have some ideas, fill your boots mate. :)

Cheers,
The Hippo

On Thu, 21 Mar 2024 at 02:20, Bruce Axtens via Freedos-devel
 wrote:
>
> I stumbled over DX-FORTH this morning which purports to be "... a
> Forth language compiler and development system for MS-DOS and CP/M-80
> operating systems. It is intended to be a complete, easy to use,
> programming tool for the creation of turnkey applications." Is this a
> language used at all in FreeDOS development?
>
> -Bruce
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Aw] MAD compiler for DOS?

[Danilo Pecher via Freedos-devel]

The most common translation of MAD would be Verrückt (bonkers, crazy),
although it can translate to wütend in some contexts. The more
accurate translation of wütend would be 'raging'. So if your theory is
right, it was a German who was rather inexperienced at English or just
took the translation form a dictionary.

On Wed, 31 Jan 2024 at 00:36, Jim Hall via Freedos-devel
 wrote:
>
> On Tue, Jan 30, 2024 at 3:51 PM Wilhelm Spiegl  
> wrote:
> >
> > https://wiki.edu.vn/wiki17/2021/01/05/mad-programmiersprache-wikipedia/amp/#
> >
> > I dont know if this helps, run a translator if necessary
> >
>
> That's very cool, thanks for sharing that. The "amp" page didn't work
> for me, but I could access it here:
> https://wiki.edu.vn/wiki17/2021/01/05/mad-programmiersprache-wikipedia/
>
> I didn't realize MAD supported abbreviations of instructions. Another
> way to get confused reading MAD source files. The wiki shows this
> 3-line program: (programs don't start with a "PROGRAM" instruction ..
> you just start writing)
>
> PRINT FORMAT HELLOW
> VECTOR VALUES HELLOW=$13h0Hello, world*$
> END OF PROGRAM
>
>
> And apparently you can abbreviate those commands like this:
>
> P'T HELLOW
> V'S HELLOW=$13h0Hello, world*$
> E'M
>
>
> Fortunately, the source files I'm working with don't have (I think)
> abbreviations like this, so I'm saved from that headache.
>
>
> *Interesting note: The page is titled "WÜTEND" (translated to English
> as ANGRY). I'm not sure if that's a German author who literally
> translated "MAD" to "WÜTEND" or why that was done. :-)
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] MAD compiler for DOS?

[Danilo Pecher via Freedos-devel]

I'm having real problems to read about MAD code written with FAP
subroutines with a straight face. I'm such a child...

On Tue, 30 Jan 2024 at 23:00, Ralf Quint via Freedos-devel
 wrote:
>
> On 1/30/2024 1:37 PM, Jim Hall via Freedos-devel wrote:
> > Jim Hall wrote:
> >>> On Mon, Jan 29, 2024 at 8:07 PM Jim Hall  wrote:
>  I am working on an academic project that requires understanding the
>  MAD programming language so I can pick apart (and faithfully recreate)
>  an old MAD program. That's the Michigan Algorithm Decoder, from 1959
>  and the early 1960s.
>  [..]
>  Does anyone know of a MAD compiler for DOS?
> >
> > Ralf Quint wrote:
> >> Up to your email, I haven't even heard of a MAD compiler. Only the
> >> magazine... 
> >> (and interesting seeing that mentioned in the Wikipedia article LOL)
> >
> > Yes, I hadn't heard of it either until a few months ago when I started
> > researching the RUNOFF source code. It's written about half in MAD and
> > about half in FAP (FORTRAN Assembly Programming). The RUNOFF program
> > is written in MAD with some support functions in FAP.
> >
> > I'm thinking about writing a book about the early history of document
> > preparation systems, and RUNOFF seemed a good place to start. I want
> > to faithfully recreate the MAD code in another programming language -
> > not an automated translation like ESR's translator would do, but an
> > understandable recreation by a human who understands what the original
> > code is doing and recreates it in a sensible way in another
> > programming language. Might do it in C or BASIC. BASIC might be
> > easier, since I'm seeing some similarities between MAD and BASIC. But
> > I'd prefer to do it in C.
> You seem to be as predisposed as me in always finding new deep dark
> rabbit holes to decent into 
> > But step #1 is to understand what's going on in the code. MAD is
> > mostly readable, but the for-next loop equivalent is a little weird to
> > me. For example, to loop from 1 to 10 (inclusive) in C, you'd do this:
> >
> > for (i = 1; i <= 10; i++) {
> > ...
> > }
> >
> >
> > Just to compare: in FORTRAN77, it's like "DO label var = start, stop, step":
> >
> > DO 10 I = 1, 10, 1
> >   ...
> > 10 CONTINUE
> >
> >
> > But in MAD, I *think* it's like "THROUGH label, FOR var = start, step,
> > failcondition":
> >
> > THROUGH LOOP, FOR I = 1, 1, I .GT. 10
> >   ...
> > LOOP   CONTINUE
> >
> >
> > And from what I can see, I think "failcondition" gets tested at the
> > end of each iteration, so it's more like this weird 'while'
> > construction in C:
> >
> >i = 1;
> >do {
> > ...
> >  i++;
> >} while ( !(i>10) );
> >
> >
> >
> > That's why I wanted to write some sample code in a real MAD compiler,
> > to see if I'm correctly understanding that (and a few other odd things
> > in the language).
> Well, the Wikipedia page lists at least two MAD manuals (the compiler,
> not the magazine), I might just download these and have a look at this
> late tonight, Tuesdays I can't get to sleep until 2am anyway and always
> watching movies on YouTube gets boring after a while... ;-)
>
> Ralf
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Learning DOS assembly programming

[Danilo Pecher via Freedos-devel]

Hi Jim,

NASM already comes with FreeDOS. It's a good one to start with. It
works perfectly fine under DOS. There is a German youtuber named
'root42' who has made some pretty good DOS Assembler tutorials in
English.

cheers, Danilo


On Tue, 26 Dec 2023 at 17:50, Jim Hall via Freedos-devel
 wrote:
>
> I actually never learned DOS assembly programming, but decided I'd
> like to start.
>
> What assembler do you recommend, and where is a good place to start
> learning about DOS assembly programming? Start with a "Hello world"
> program and eventually move up to writing an assembly version of TYPE
> and CHOICE, things like that.
>
> I was thinking about NASM, since it's open source and we include it in
> the distribution. Looking around, I found a bunch of tutorials on
> https://asmtutor.com/ that look easy enough to follow, although it's
> for Linux. Any similar tutorials to learn DOS assembly programming?
>
> Or would you recommend a different DOS assembler (and how-to guide) as
> a place to start?
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Updating the FreeDOS website

[Danilo Pecher via Freedos-devel]

Hi Jim,

I know a lot of works has probably gone into this, but quite frankly I
think it looks just like all the other plastic-y websites you find
everywhere. I might be a bit weird, but I kind of like old school
websites that are simple and render on anything. It is sort of funny
to think that we need to be "modern" when we are literally a project
that keeps a 40 year old software alive and kicking. It's a bit like
gramps trying to rap, which usually sinks every family reunion quicker
than the Titanic.

I hope I don't offend anyone, but frankly I think the yardstick should
be: can the site be viewed with the browsers that actually come with
FreeDOS (Dillo, links).

But of course that's just my opinion. And I like steam engines...

Cheers, Danilo

On Mon, 11 Dec 2023 at 17:00, Jim Hall via Freedos-devel
 wrote:
>
> The last time we made a major update to the FreeDOS website was maybe
> ten years or so. Things are definitely feeling a bit dated, such as
> certain design elements. And over time, we've added content where it
> seemed to "fit" so the usability has degraded since the last update.
>
> I have been "backburner" planning a website upgrade for the last two
> years, and sponsored several rounds of usability tests against
> different website designs. And I think I'm finally ready with the new
> FreeDOS website:
>
> https://test.freedos.org/
>
> This is a preview to the new website on our "test.freedos.org"
> website. I'll move this to the "freedos.org" primary website soon.
>
> What do you think?
>
> I think new website is more streamlined and more modern. I've tried to
> improve the navigation, and place the most important information right
> up front where it's easy to find. For example, the new website has a
> very obvious "Download FreeDOS 1.3" button that takes you to the
> Downloads page. We know from user surveys that most people use FreeDOS
> to 1. play classic DOS games, 2. run their favorite DOS applications,
> and 3. create new FreeDOS programs. So now we have "info boxes" on the
> front page that let you explore these different ways to use FreeDOS;
> they each link to a separate page with more details, information, and
> links. For example, the "Games" page has links to different archives
> of DOS games, and links to drivers that you might need to support DOS
> games on new hardware (like SBEMU) - and the "Developer" page has
> links to developer tools and technical information, as well as links
> to the source code and the "how to contribute" page.
>
> The header and footer have the links that we know most people are
> looking for right away: read the wiki for more information, links to
> the email lists and forums where they can ask questions, and links to
> the bug tracker to report a bug.
>
> I may tweak the website over time, but I think this is a good design
> that's ready to go live. But I'm looking for comments - if anything
> seems broken or lost (didn't make it to the new website) let me know
> so I can fix it or add it back.
>
>
> I haven't moved over everything yet. For example, the "History" page
> is quite old and needs updating. Same for the "FreeDOS in the news"
> page. So while I've copied over that content to the new website, I
> haven't linked to them. I don't plan to link to them until I have more
> time to update them. Or maybe that historical info should go into the
> wiki.
>
> I also haven't moved the "Books" pages. These really should be moved
> to the wiki, and I plan to do that instead of just migrating the
> pages.
>
>
> *Speaking of the wiki: Now that the website is pretty much ready to
> go, my next project is to update the wiki. The wiki effectively
> "degraded" when SourceForge updated the PHP version on their hosting
> website. The wiki content is all there, but the wiki pages are not
> styled. I don't know why. I could spend time fixing things on
> SourceForge - but I'd been planning to move the wiki to a new hosting
> website for a while, anyway. I'll do that next.
>
>
>
> Jim
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Source

[Danilo Pecher via Freedos-devel]

Hi Rob,

I would start a bit more at the meta level and research how kernels
work. There are also many sites dealing with OS development (osdev is
useful search term). It is quite instructive to see the first steps
that happen after the machine boots (the boot loader mainly). Once
you've really understood that and perhaps cobbled together your own
simplistic test OS, you should be well on your way to dive into the
FreeDOS kernel source.

Cheers, Hippo

On Thu, 30 Nov 2023 at 01:02, robert roper via Freedos-devel
 wrote:
>
> Is there a FreeDOS walk thru of the source code that you would consider 
> helpful to the uninitiated?  I want to start down the road to more bare metal 
> coding and would love to be able to help with FreeDOS in the far future but 
> I'm not sure where to begin.  I do know how to program in C and have just 
> purchased some old 8086 assembly books to start learning that but none of 
> them talk about operating system concepts.
> I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds 
> perfect, except it was published in 1996.  Is there anything like this that 
> is more current?  Or do you consider that the definitive guide?
>
> Thanks for any help you can provide and apologies if I've sent this to the 
> wrong group.
>
> Rob
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Question about USBDOS license

[Danilo Pecher via Freedos-devel]

Hi,

I think the question is rather academic. The Patreon membership is
voluntary. Nothing prevents a user from downloading and using the
program for free and under conditions described by the program's
author. This is different to, let's say, a website that requires a
paid membership to get access to it, or including it on a collection
CD/DVD that you'd have to buy.

cheers, Hippo

On Wed, 29 Nov 2023 at 21:08, Jim Hall via Freedos-devel
 wrote:
>
> Someone else asked me about the USBDOS license. This person
> highlighted a note in the USBDOS license that suggested "if your
> website collects money, then you can't distribute USBDOS" - and the
> person asked about the Patreon link on the www.freedos.org website.
>
> So I thought I'd share my reply here, and see if anyone else had
> thoughts on this. Overall: I don't think the Patreon link is an issue
> for the USBDOS license. Let me know if you disagree.
>
> I don't know if Bret still subscribes to the freedos-devel list, but
> maybe he is and can answer more definitely. :-)
>
>
> I downloaded a copy of the USBDOS files from https://bretjohnson.us/
> and evaluated that. In USBINTRO.DOC, I found the "COPYRIGHTED
> FREEWARE" section which said this: (entire copy)
>
> > The accompanying programs are authored by Bret Johnson with suggestions,
> > programming, documentation, and testing help from Richard Bonner
> > (http://www.chebucto.ns.ca/~ak621).
> >
> > This section contains the license for all of the enclosed programs.  I'm
> > not going to inject a bunch of legal language in here that a smart
> > lawyer can find a loophole in.  I'm writing down the intent of how I
> > want the programs to be distributed and used in my own words, and hope
> > that the intent is clear, no matter how the literal words can be twisted
> > to mean different things (remember when President Bill Clinton, a
> > lawyer, claimed he didn't understand the meaning of "is" during the
> > Lewinsky hearings?).
> >
> > All of these programs, as well as their documentation and source code,
> > are freely available to anyone who wants them.  You can use the programs
> > without restriction, but you cannot directly or indirectly use the
> > executable programs, documentation, or source code to create or
> > distribute new programs that are not also freely available.  You also
> > cannot distribute the programs, documentation, or source code and charge
> > (even indirectly) for their distribution.  You can charge someone enough
> > to cover your actual, direct costs for distribution (disks, shipping
> > materials, postage, etc.), but cannot charge for "handling".  This also
> > means that you cannot distribute the programs, documentation, or source
> > code directly from a web site that charges a "registration fee" in an
> > attempt to make a profit or to recover direct or indirect costs for
> > maintaining the web site.
> >
> > If you distribute related or derivative programs, you must use
> > essentially the same license.  You must provide and distribute the
> > programs and documentation for free, and you must include the
> > documentation with the program.  You must give credit where it is due,
> > and must make the source code freely available to anyone who wants it.
> >
> >
> > Perhaps a good test of whether your program is adhering to the license
> > or not would be if you are willing to let me post the program,
> > documentation, and source code on my web site, to be downloaded by
> > anyone who wants it.  In fact, if you create any new related or
> > ancillary DOS USB programs, I would like the opportunity to distribute
> > them from my web site.  I won't guarantee that I will necessarily do it,
> > but would like the opportunity.  Distribution from my web site
> > (http://bretjohnson.us) is not required by the license.
>
> I see several terms in this license: (some of these are reworded,
> numbers added by me for reference)
>
> (1) All of these programs, as well as their documentation
> and source code, are freely available to anyone who
> wants them.
>
> (2) You can use the programs without restriction, with
> this exception: you cannot directly or indirectly use
> the executable programs, documentation, or source code
> to create or distribute new programs that are not also
> freely available.
>
> (3) You cannot charge (even indirectly) to distribute the
> programs, documentation, or source code
>
> (4) You can charge someone enough to cover your actual,
> direct costs for distribution but cannot charge for
> "handling".
>
> (5) You cannot distribute the programs, documentation,
> or source code directly from a web site that charges a
> "registration fee" in an attempt to (5a) make a profit or
> (5b) to recover direct or indirect costs for maintaining
> the web site.
>
> (6) If you distribute related or derivative programs,
> you must use essentially the same license.
>
> (7) You must provide and distribute the programs
> and documentation for free, and you must include the
> 

Re: [Freedos-devel] Simplified Chinese Edlin?

[Danilo Pecher via Freedos-devel]

The simple answer is - you can't. For starters you would need to
activate the secondary character table in text mode, giving you 512
characters to work with, at the expense of 8 background colours.
Therein lies the problem though. Firstly, it only works on EGA and VGA
cards and secondly - as the highest bit of the screen attribute is
repurposed to indicate which character table the char is coming from -
you would need to include the screen attribute in the NLS files.

cheers, Hippo

On Wed, 15 Nov 2023 at 01:24, Gregory Pietsch via Freedos-devel
 wrote:
>
> While perusing Github, I noticed that the NLS project hasn't upgraded Edlin, 
> which has three new messages to be translated. I also noticed that recently, 
> many of the downloads of Edlin from SourceForge are from Hong Kong, which I 
> found amusing. I also found a "fork" of Edlin in Github where the guy 
> translated the messages into Simplified Chinese. This begs the question of 
> what I should do to get Edlin to work with Simplified Chinese (I know very 
> little about how an Asian language with 50,000 characters is used on a PC) 
> and can we include it in NLS. I think searching for "edlin.zh-hans" on Github 
> will find it.
>
> Gregory
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Danilo Pecher via Freedos-devel]

As far as I know the earlier Turbo-Pascal compilers (I think 5.5 and
earlier) have been freeware'd years ago. They can natively compile
16bit code on Freedos and might be worth a try. You can find even
ancient versions of TP, like 3.0 on winworldpc, and I actually quite
like to go down memory lane once in a while, although I have ported
most of my projects to Watcom C by now.

cheers, Hippo

On Thu, 9 Nov 2023 at 23:44, Bernd Böckmann via Freedos-devel
 wrote:
>
> Btw, when compiling in large memory model via
>
> fpc -Wmlarge
>
> the pointer errors when compiling keyb are gone. There are some 20
> remaining compile errors. Perhaps these can be solved.
>
> Bernd
>
> On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:
> > Hello Aitor,
> >
> > > Could you please post the exact message you got from the compiler?
> >
> > For something like this "FarPointer(@Buffer)" I get the following
> > error message:
> >
> > "Error: Illegal type conversion: "Pointer" to "FarPointer""
> >
> > My opinion is that this should be supported by the compiler, because
> > it is well defined for the small memory model I am working in.
> >
> > I looked into the keyb source code and tried to compile it with
> > FreePascal. One problematic line is for example:
> >
> >  PWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > Here, Ptr emits a far pointer, and PWord would cast this to a near
> > pointer. FreePascal complains about it.
> >
> > BUT the following at least gets accepted by the compiler:
> >
> > type PFarWord = ^Word; far;
> >
> >  PFarWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > This converts it to a typed FAR pointer, which than can be de-referenced.
> >
> > What is more concerning are error messages like:
> >
> > "Warning: Use of +offset(%ebp) is not compatible with regcall
> > convention", since there is not a trace of 32 bit instructions in the
> > code.
> >
> > Bernd
> >
> >
> >
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] i have a tech question about 286 and XMS

[Danilo Pecher via Freedos-devel]

If you have a windows or Linux machine at hand, you might want to
check with pcem. It can emulate several 286 BIOS/board variants. That
would give you a hint if it might be a problem with your board or the
286 architectur in general.

On Wed, 8 Nov 2023 at 14:33, tom ehlert via Freedos-devel
 wrote:
>
> Hallo Herr sparky4 insano via Freedos-devel,
>
> am Mittwoch, 8. November 2023 um 04:23 schrieben Sie:
>
> > i think i found the problem i ran the SAME driver and same code on my 486
> > and it works without fail.
>
> > there is something wrong with my 286 board 
> not necessarily.
> one of the usual problems with XMS drivers are the way A20  s switch on/off,
> and the 486 may use a different method. impossible to tell from far.
>
> try to use MSDOS/HIMEM.SYS on the 286.
>
> Tom
>
>
> > with love,
> > sparky4
> > Administrator of 四葉の芽◇ちゃんねる
>
>
> > On Mon, Nov 6, 2023 at 5:48 PM sparky4 insano 
> > 
> > wrote:
>
> >> ah i found a more specific bug
> >> using TED5 from https://github.com/sparky4/16-0
> >> i tried to scrolling and it crashes
> >>
> >> Wolfenstein 3d crashes in the demo
> >>
> >> i think there is a bug in the software
> >>
> >> with love,
> >> sparky4
> >> Administrator of 四葉の芽◇ちゃんねる
> >>
> >>
> >> On Sat, Nov 4, 2023 at 10:03 AM Eric Auer via Freedos-devel <
> >> freedos-devel@lists.sourceforge.net> wrote:
> >>
> >>>
> >>> Hi!
> >>>
> >>> > FDXMS286.sys is the driver i am using
> >>> > it works with wolf3d code but not the dos game code. i made a work
> >>> around
> >>> > but there might be a bug in that xms driver's code
> >>>
> >>> Please be more specific about what went wrong and which
> >>> work around in which code snippet resolved the problem.
> >>> I think a workaround in FDXMS286 could be a good idea.
> >>>
> >>> Regards, Eric
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Freedos-devel mailing list
> >>> Freedos-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >>>
> >>
>
>
>
>
>
> Mit freundlichen Grüßen / with kind regards
> Tom Ehlert
> +49-15151898538
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] i have a tech question about 286 and XMS

[Danilo Pecher via Freedos-devel]

Sorry, Tom, but this reply is, to use a technical term, pretty shit.
We're talking about FreeDOS, a system that by design was created for
hardware that would lose to our phones these days. If you 'only want
to support 386+' then you can just as well install Dosbox. Either
FreeDOS has the ambition to be what it says on the tin - a Freeware
DOS replacement - in which case it should support all hardware that
the original MS-DOS supported, including pre-386 hardware, or you can
just as well bin the original premise. All in all I think your reply
needlessly confrontational.

Cheers, Hippo.

On Wed, 1 Nov 2023 at 23:13, tom ehlert via Freedos-devel
 wrote:
>
>
> > is there any supported XMS driver for 286 that FreeDOS provides? himemx
> > dose not support it and the fd286xms driver is old and not supported.
>
> why do you think that software for 30+ years old hardware needs to be 
> 'supported'.
> it's the same as last year, and 20 years before.
> And will work for the next few hundred  years as well.
>
> Tom
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Help Development with djgpp

[Danilo Pecher via Freedos-devel]

As far as I know, VESA graphics mode numbers are not standardized,
which is why the vesa info block of standard 1.2 and higher, returned
by INT 10h function AX=4F00h, contains a mode list, which you then
need to traverse using INT10h AX=4F01. So as a first step I'd check if
the watcom graphics library does that. As a first test you might want
to use the 'listvesa' package from the FreeDOS Live-CD (utilities
section IIRC) to see if your graphics card does support at least VESA
1.2 and then if it supports that specific mode.

cheers, Hippo

On Fri, 27 Oct 2023 at 01:18, Jim Hall via Freedos-devel
 wrote:
>
> On Wed, Oct 25, 2023 at 5:58 AM Walter Oesch via Freedos-devel
>  wrote:
> >
> > From Code:
> >
> >   if(_setvideomode(_SRES16COLOR) == 0) /* Switch to 800*600 mode with 
> > 16 colors */
> >   {
> >  printf("\n\nVideo mode not supported!!!\n");
> >  printf("Maybe the VESA driver has not been loaded!\n");
> >
> >
> > There must be used VESA driver.
> >
>
>
>
> If it helps to have a quick test program to try on your board, you can
> find GRAFTEST.EXE here:
>
> https://personal.freedos.org/temp/GRAFTEST.EXE
>
>
> This just puts the display into graphics mode then draws a square,
> circle, and diagonal line. The EXE is compiled with OpenWatcom C using
> the defaults (using "WCL -q GRAFTEST.C") so it's without optimization
> - it's just a demo program. Source code is in GRAFTEST.C (at same
> location, also copied below)
>
>
> #include 
> #include  /* getch */
> #include  /* graphics mode */
>
> int main()
> {
> if (_setvideomode(_VRES16COLOR) == 0) {
> puts("cannot set video mode");
> return 1;
> }
>
> /* draw shapes */
>
> _setcolor(1); /* blue */
> _rectangle(_GFILLINTERIOR, 50,75, 350,375); /* from 50,75 to 350,375 */
>
> _setcolor(2); /* green */
> _ellipse(_GFILLINTERIOR, 300,200, 500,400); /* from 300,200 to 500,400 */
>
> _setcolor(15); /* br white */
> _moveto(10,10);
> _lineto(600,400); /* line from 1,1 to 600,400 */
>
> if (getch() == 0) {
> /* if getch is zero, then extended key. call getch again to clear
>it and get a new extended code */
> getch(); /* but we don't really need it anyway :-) */
> }
>
> /* done */
>
> _setvideomode(_DEFAULTMODE);
> return 0;
> }
>
>
>
> (my code formatting may be messed up when copied/pasted into an email)
>
> I'll delete the https://personal.freedos.org/temp/ URL around November 1.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Calculator for DOS with GUI

[Danilo Pecher via Freedos-devel]

I've had a look at it, and I doubt there's much use for it on FreeDOS.

The most glaring obstacle is the choice of programming language.
Neither Microsofts Quickbasic, nor Borlands Turbo-Basic are free
software, so the amount of people who would be able to compile it, is
probably dwindingly small. Also, Basic is not really a language that
lends itself to large scale projects as it is by its own definition
more of an educational nature.

The second problem is the reliance on the mouse. Although I doubt too
many people out there don't have one, a GUI without proper keyboard
support is dysfunctional at best. I better not repeat the sort of
replies we got from the accounting department 15 years ago when we
presented them with a shiny new GUI for their invoice processing
software that had moved many functions from hotkeys to mouse clicks.

The program works as a tool to show that you can write GUI programs
with BASIC, but in the grand scheme of things that amounts to proving
that you can use a driving instruction car as a mini cab. I think the
whole tutorial concept would work a lot better if you ported it to one
of the free languages that come with FreeDOS, like FreePascal or
Watcom C.

cheers, Danilo

On Mon, 9 Oct 2023 at 06:41, Pedro Luis Carballosa Mass via
Freedos-devel  wrote:
>
> Thanks for the suggestion (https://www.gnu.org/licenses/gpl-howto.en.html).
>
> The author of the mouse subroutines (Andreas Andersson) does not ask to be 
> contacted, only mentioned, and that is why I mention him in the tutorial.
>
> He says:
>
> "If you use any of this code in your programs, please give me a credit".
>
> The code to manipulate the mouse is not difficult to make, but there was no 
> point in doing it again if it was going to be the same.
>
> Indeed, the calculator is an example, and it still does not contain all the 
> updates, nor all the components, it was an intermission so as not to make the 
> tutorial too boring.
>
>
>
> El dom, 8 oct 2023 a las 16:33, Paul Dufresne via Freedos-devel 
> () escribió:
>>
>>  Le sam., 07 oct. 2023 20:08:05 -0400 Pedro Luis Carballosa Mass via 
>> Freedos-devel  a écrit 
>>  > Indeed, but that line can be changed (consider it GNU license), as author 
>> I guarantee that the code can be used to be improved if that serves for 
>> something to someone.
>> Then I would suggest you read/use 
>> https://www.gnu.org/licenses/gpl-howto.en.html
>>
>>  > Note: The calculator also use a bit of code shared by others (mouse 
>> subroutines by Andreas Andersson (alhambr...@hotmail.com)) as I mencioned in 
>> the tutorial 
>> (https://cubansolutions.blogspot.com/2022/11/diseno-e-implementacion-de-una-gui.html).
>> If it was me, I would probably then only publish the .bas file with that 
>> part removed... unless you are able to contact him and get the permission to 
>> publish it.
>>
>> The code is likely to be interesting to build graphical programs other than 
>> a calculator, as the calculator seems to mostly be an example of GUI 
>> routines.
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

[Danilo Pecher via Freedos-devel]

> Beside that
> leaves you in general also with the problem on how to transfer your
> programs from your fancy Windows/Linux/macOS box to that VM. That's a
> problem that that you simply do not have when programming ON DOS.

Well, I often use DOS in an emulator (pcem) because that emulates
specific hardware from an old 4Mhz 8086 up to a Pentium Overdrive MMX
and two dozen different graphics adapters from Hercules to a Stealth
3D 2000, which is really helpful if you test hardware-specific
routines.

Like all emulators/Vm's it uses Disk images (and isos for CDROM), so
the easiest way to get your stuff from from your Linux machine to the
VM is creating a disk image of your stuff, or an iso if it is too
large for a disk. with dd and the loopback interface that's a matter
of seconds. I made a script for it, so it's literally a one-liner on
the command line.

It's even easier if you run FreeDOS in Virtualbox, where the network
drivers actually work instead of bailing out with a 'physical hardware
networking not supported' error. Install the sshdos2 package and you
can simply scp your stuff to the VM.

cheers, Danilo

On Fri, 6 Oct 2023 at 03:13, Ralf Quint via Freedos-devel
 wrote:
>
> On 10/5/2023 4:44 AM, tom ehlert via Freedos-devel wrote:
> > Hallo Herr Ralf Quint via Freedos-devel,
> >
> > am Donnerstag, 5. Oktober 2023 um 02:50 schrieben Sie:
> >
> >> On 10/3/2023 11:30 AM, Michael Brutman via Freedos-devel wrote:
> >>> There is no point in punishing everybody by shipping tools that most > 
> >>> people don't use.  You can probably count all of the active DOS > 
> >>> developers on your fingers and toes.
> >>>
> >>> All of the various tools and compilers remain available for download.  > 
> >>> Not being on the CD image is not the barrier it used to be.
> >> But could you consider that there are so few people programming in and for 
> >> DOS simply because there are no simple to use programming environments 
> >> available and instead some folks keep pushing oversized Linux influenced 
> >> behemoths of  programming environment which need to be shoehorned to run 
> >> and produce results within the basic limitations of DOS?
> > i have said it before, but repeat it anyway:
> Well, no matter how many time you repeat that, that doesn't make it in
> MY opinion a valid argument.
>
> I joined some retro computing and BASIC groups and there are LOTS of
> people  that would just for old times sake like to program in (Free)DOS,
> in something simple as a BASIC interpreter, like they did 30 years ago.
> Not everyone wants to run DOS to play games. Or develop multi-megabyte
> applications. And not everyone is running (Free)DOS in a VM. Beside that
> leaves you in general also with the problem on how to transfer your
> programs from your fancy Windows/Linux/macOS box to that VM. That's a
> problem that that you simply do not have when programming ON DOS.
>
> Ralf
>
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

[Danilo Pecher via Freedos-devel]

Hi,

I'm with Kirn on this one. I think people have a wrong idea what
people use FreeDOS for, if at all. First of all, I think that the
assumption that there's a mahoosive community out there might be a wee
bit optimistic. It's probably rather modest, as not too many people
these days use DOS for anything but playing old games or running
legacy software. If we were to organize a developer conference, we'd
probably not be required to book the Royal Albert Hall.

Looking at how just about any operating system has come over the
years, you always get a basic system with close to no development
tools. They've always been something you install from a secondary
source, like a supplemental disk (or disk set as it was in the days
before the CDROM). Now, notwithstanding that anyone choosing ia16gcc
over watcom is a glutton for punishment to begin with, I don't think
it needs to be on the base install medium. In fact, I think the Base
CD is bloated enough as it is, with a lot of tools that most users
will never install, and in most cases won't have a scooby-doo what
they do in the first place. Jim correctly pointed out that there's
quite a bit of overlap between the LiveCD and the Bonus CD.

Honestly, I'd prefer a 3-tier split, actually. The Base CD should be
somewhere around 300MB max. If you still insist on a Basic interpreter
(for nostalgic reasons or somesuch) put Bywater on it and all's good.
Add to that some basic networking tools, dillo and one or two editors
that the average user can actually use without a computer science
degree or a 10 year nerd history. I've seen university graduates with
top grades fall apart when presented with nothing but vi for an
editor. It's an advanced user's choice, so it doesn't take anything
away from the system to put it on an extra disk.

The best solution would be three disks:

BaseCD - no bigger than 300MB, only basic tools

ApplicationCD - Editors, Gemes, Utilities - the lot

DeveloperCD - what it says on the tin: all that concerns development.
It could actually contain a lot more packages as it does now. For
instance it could contain freeware'd former commercial software, like
the Borland C 4.5 command line tools or source packages, like the
open-sourced Wolfenstein 3D, which would help developers learn about
advanced programming techniques.

sorry, I'm hopelessly useless at keeping my replies short.

cheers, Danilo

On Thu, 5 Oct 2023 at 07:47, Kirn Gill via Freedos-devel
 wrote:
>
> I think you're blinded by DJGPP. At no point did I argue for keeping THAT 
> mess in... or gcc-ia16. You just assumed that I would, so assumed that's 
> exactly what I was advocating for. No, keep it simple. A "base" disc's dev 
> tools shouldn't take more than 20MB at most. An assembler, a basic 16-bit C 
> compiler (Small C?), a 'make' tool of some sort, a cheap linker (if the 
> compiler and assembler don't already include these.) Maybe FreeBASIC. The 
> largest piece of this would be FreeBASIC at 8MB for version 1.10 released 
> this year. It's been a while since I've looked, but certainly one could ship 
> basic dev tools on the base disc and leave the heavyweight GNU crap for the 
> supplemental disc.
> --
> Kirn Gill II
> Mobile: +1 813-300-2330
> VoIP: +1 813-704-0420
> Email: segin2...@gmail.com
> LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6
>
>
> On Wed, Oct 4, 2023 at 7:53 PM Ralf Quint via Freedos-devel 
>  wrote:
>>
>> On 10/3/2023 11:30 AM, Michael Brutman via Freedos-devel wrote:
>> > There is no point in punishing everybody by shipping tools that most
>> > people don't use.  You can probably count all of the active DOS
>> > developers on your fingers and toes.
>> >
>> > All of the various tools and compilers remain available for download.
>> > Not being on the CD image is not the barrier it used to be.
>>
>> But could you consider that there are so few people programming in and
>> for DOS simply because there are no simple to use programming
>> environments available and instead some folks keep pushing oversized
>> Linux influenced behemoths of  programming environment which need to be
>> shoehorned to run and produce results within the basic limitations of DOS?
>>
>>
>> Ralf
>>
>>
>>
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

[Danilo Pecher via Freedos-devel]

I think the developer tools should go to the bonus CD. As was
mentioned, most FreeDOS users will probably use it to run legacy apps
and games. People who still have the knowledge to do some
honest-to-god proper DOS programming will probably be quite able to
switch the CD and install the stuff from the Bonus-CD or perhaps even
a dedicated developer CD, which then could include some libraries
(like pdcurses) and - a real must really - a version of Ralph Brown's
Interrupt list.

I would also move VIM to the bonus disk as most 'normal' users won't
have a scooby-doo what to do with it.

VIM, Watcom, GCC IA16 and FPC are large packages and would free up a
lot of space on the Live-CD for other stuff more suitable to the
casual user.

Speaking of installing packages. I'm really reaching the end of my
tether with FDIMPLES. Has that ever been tested on real metal? It runs
fine in VMWare, but lob it on a 33Mhz 386 and you're in for a very
sluggish experience. I've switched to just pumping the packages
manually with unzip.

cheers, Danilo


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

Re: [Freedos-devel] CD-ROMs was ANSI for DOS

[Danilo Pecher via Freedos-devel]

Yeah, around 1993 was when the first ones arrived.

On Mon, 7 Aug 2023 at 01:12, Steve Nickolas via Freedos-devel
 wrote:
>
> On Mon, 7 Aug 2023, Danilo Pecher via Freedos-devel wrote:
>
> > The first one I can remember was the Mitsumi CRMC-LU005S single speed
> > drive, which was the one I had. It had its own card because it was
> > non-IDE despite the fact that the cable and plug looked exactly like
> > IDE. They did use a proprietary standard. They definitely worked on an
> > 80286, so I think we can conclude that CDROMs did not require an
> > 80386. I can remember some early Shareware CD's with stuff I couldn't
> > use because I only had a 80286. DJGPP springs to mind.
>
> I remember seeing an XT with an external CD-ROM drive at a library 30
> years ago.
>
> -uso.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] CD-ROMs was ANSI for DOS

[Danilo Pecher via Freedos-devel]

The first one I can remember was the Mitsumi CRMC-LU005S single speed
drive, which was the one I had. It had its own card because it was
non-IDE despite the fact that the cable and plug looked exactly like
IDE. They did use a proprietary standard. They definitely worked on an
80286, so I think we can conclude that CDROMs did not require an
80386. I can remember some early Shareware CD's with stuff I couldn't
use because I only had a 80286. DJGPP springs to mind.

On Sun, 6 Aug 2023 at 23:59, Jerome Shidel via Freedos-devel
 wrote:
>
>
>
> On Aug 3, 2023, at 3:57 PM, Ralf Quint via Freedos-devel 
>  wrote:
>
> On 8/3/2023 11:54 AM, Jerome Shidel via Freedos-devel wrote:
>
>
> On Aug 3, 2023, at 12:37 PM, Bret Johnson via Freedos-devel 
>  wrote:
>
> 
>
> Yeah, USB and CD/DVD makes only sense for a 386+ ...
>
> USB, yes.  CD/DVD, no.  USB requires PCI which in turn requires 386+.  
> Actually, there were supposedly USB host controllers manufactured for the ISA 
> bus instead of PCI, but I've never actually seen one.  But USB protocols 
> assume you're using a 32-bit (and in some cases 64-bit) CPU so USB really 
> only makes sense on 386+, though you could probably make things work on a 
> lesser CPU if you absolutely had to.
>
> But CD drivers existed back in the early days and they never required 
> anything special of the CPU.  They would sometimes take advantage of special 
> features if they were available, but it wasn't required.  AFAIK, there are no 
> DOS DVD drivers anyway since I don't think anything has ever supported UDF.
>
> I don’t recall any sub-386 ever shipping with a CD-ROM drive. But, there may 
> have been a couple very high end machines.
>
> The main problem why I consider a CD/DVD drive is that on pre-386 computers, 
> you rarely have an IDE/ATAPI controller to connect a common CD-ROM drive. 
> Yeah, theoretically, you could use a SCSI one, but that's a completely 
> different kettle of fish...
>
> The first time I used CD-ROM drives was at least on a 486 machine. You could 
> try to use and ATAPI controller on an AT class computer (80286, or lower), 
> but then you are getting down into a deep dark rabbit hole where you need to 
> know what you're doing anyway, so trying to adapt FreeDOS would be a manual 
> option.
>
> Hence, from a general, default installation option POV, I stick with my 
> assessment that it makes only sense for a 386+ machine...
>
>
> Ralf
>
>
> Yep. Same here.
>
> For some reason, I’m thinking that first CD drive came with a controller card 
> because it was a SCSI drive.
>
> However, I already had a SCSI scanner with a better card and just used that 
> card.
>
> But that was 30 years ago, I could be miss-remembering it as SCSI.
>
> Ah, SCSI terminators…. :-)
>
> Jerome
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] ANSI for DOS

[Danilo Pecher via Freedos-devel]

I did have a Mitsumi single speed CD-ROM drive on my massive 20 Mhz
80286 back in 1993. It came with an own ISA interface card, so I think
it probably used some proprietary protocol instead of ATAPI.

Funnily enough that thing did faithful service until 2007 when it
still happily see-sawed inside a friend of mine's under-table 'server'
for his small business.

On Thu, 3 Aug 2023 at 21:58, Ralf Quint via Freedos-devel
 wrote:
>
> On 8/3/2023 11:54 AM, Jerome Shidel via Freedos-devel wrote:
> >
> >> On Aug 3, 2023, at 12:37 PM, Bret Johnson via Freedos-devel 
> >>  wrote:
> >>
> >> 
> >>> Yeah, USB and CD/DVD makes only sense for a 386+ ...
> >> USB, yes.  CD/DVD, no.  USB requires PCI which in turn requires 386+.  
> >> Actually, there were supposedly USB host controllers manufactured for the 
> >> ISA bus instead of PCI, but I've never actually seen one.  But USB 
> >> protocols assume you're using a 32-bit (and in some cases 64-bit) CPU so 
> >> USB really only makes sense on 386+, though you could probably make things 
> >> work on a lesser CPU if you absolutely had to.
> >>
> >> But CD drivers existed back in the early days and they never required 
> >> anything special of the CPU.  They would sometimes take advantage of 
> >> special features if they were available, but it wasn't required.  AFAIK, 
> >> there are no DOS DVD drivers anyway since I don't think anything has ever 
> >> supported UDF.
> > I don’t recall any sub-386 ever shipping with a CD-ROM drive. But, there 
> > may have been a couple very high end machines.
> The main problem why I consider a CD/DVD drive is that on pre-386
> computers, you rarely have an IDE/ATAPI controller to connect a common
> CD-ROM drive. Yeah, theoretically, you could use a SCSI one, but that's
> a completely different kettle of fish...
>
> The first time I used CD-ROM drives was at least on a 486 machine. You
> could try to use and ATAPI controller on an AT class computer (80286, or
> lower), but then you are getting down into a deep dark rabbit hole where
> you need to know what you're doing anyway, so trying to adapt FreeDOS
> would be a manual option.
>
> Hence, from a general, default installation option POV, I stick with my
> assessment that it makes only sense for a 386+ machine...
>
>
> Ralf
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS

[Danilo Pecher]

Jim put it best, I think - remove the GUI's from the official media,
but leave them on ibiblio, which would be the FreeDOS equivalent of
the Hobbes archive for OS/2.

On Wed, 22 Feb 2023 at 23:53, Liam Proven  wrote:
>
> On Sun, 19 Feb 2023 at 17:52, Jim Hall  wrote:
> >
> > It's been a few days since the last comment on this thread, so I think
> > those who have an opinion on this have voiced it.
>
> Just seen it. I've moved house recently and have no broadband at my new place.
>
> > The consensus appears to be "Keep OpenGEM but drop oZone and SEAL"
>
> Sounds good. But please _fix_ OpenGEM. Either configure it to run from
> the subdirectory FDIMPLES puts it in, or tweak its batch file to
> SWSUBST it to a drive letter of its own.
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS

[Danilo Pecher]

Quite frankly, I would throw them all on the scrap heap. As Jim said,
none of them has any number of apps worth noting and there is a reason
why no GUI other than Windows 3.11 ever took off under Dos. I know
that from painful experience of wasting two years on an attempt to
create one in the early 90s. It's just not what Dos is about, I think.
Unless someone puts together a serious attempt (perhaps PCGeOS
qualifies) I wouldn't include any GUI. Frankly, if you are after a
freeware GUI OS, Linux or ReactOS are better options.

On Wed, 15 Feb 2023 at 23:43,  wrote:
>
> Hi Jim,
>
> > On Feb 15, 2023, at 5:05 PM, Jim Hall  wrote:
> >
> > As I mentioned in my other email, I don't think we need to have
> > Graphical Desktops included in FreeDOS. I propose that we remove
> > Graphical Desktops from the next FreeDOS, starting with the next
> > FreeDOS Test release.
> >
> > Graphical Desktops were a neat experiment, long ago. We used to have a
> > few desktops in FreeDOS, including Desktop2 (which was really just a
> > graphical menu and file launcher). Today, we have three desktops in
> > the FreeDOS distribution, under the "Graphical Desktops" group:
> >
> > 1. OpenGEM
> >
> > This is a very nice graphical desktop that is basically the old GEM
> > desktop ("Graphics Environment Manager"). If you used DR-DOS, you may
> > have seen GEM. It works well and is solid. But no one writes apps for
> > OpenGEM - and without apps, it doesn't really add much value. The
> > packages are broken (wrong paths) but that is fixable.
> >
> > I propose we remove OpenGEM from the distribution anyway.
> >
> > 2. oZone GUI
> >
> > This is a nice-looking GUI, but it has some noticeable bugs. Even the
> > included Minesweeper game doesn't count properly (see 3:40 in
> > https://www.youtube.com/watch?v=nw-Fx5k7Smg)
> >
> > I don't foresee anyone fixing these bugs. And like OpenGEM, it
> > includes a few built-in apps, but no one is writing new apps for it.
> > Without apps, it doesn't do much more than a graphical menu program.
> >
> > I propose we remove oZone GUI from the FreeDOS distribution.
> >
> > 3. SEAL
> >
> > This is another nice-looking GUI, and if I recall correctly, a version
> > of SEAL became Qube OS. This has a few built-in apps, but no one is
> > making new apps for it. And without apps, it doesn't do much more than
> > a graphical file launcher.
> >
> > I propose we remove SEAL from the FreeDOS distribution.
> >
> > Jim
>
> I personally do not use any GUI under FreeDOS.
>
> But, I’m not sure that we should remove all GUIs from the release. At least 
> maybe, keep the best one the Bonus CD.
>
> It seems like every couple weeks, someone fairly new to FreeDOS wants to 
> create a GUI. I feel that some of those prospective developers really just 
> want something similar to Windows 3.x or 9x to run windows software. Others 
> are most likely coming from a "modern” desktop OS and think FreeDOS needs a 
> GUI. They may be wrong or right. I try not to judge. But instead of just 
> having them wonder down their own path to a half finished GUI, it would be 
> more productive to point them at one of the existing ones. Giving them a 
> place to contribute.
>
> As Jim said, oZone GUI and SEAL have had unfixed bugs for a long time. They 
> also have very little software. They should probably be removed.
>
> At present, OpenGEM is probably the most popular and stable. But, it may not 
> be the answer either. If I recall correctly, the last release was the final 
> version and for all purposes development has ceased.
>
> There is at lease one very popular desktop GUI still under development. That 
> would be PC-GEOS. It was open sourced some time back and a small team has 
> been working on removing any proprietary code.
>
> Perhaps we should keep OpenGEM around for a while. Then maybe at some point, 
> when the team working on PC-GEOS feels comfortable with a general public 
> release, we could switch over to including it. We could could also suggest to 
> those who want to create a GUI, the check out contributing to the PC-GEOS 
> project.
>
> Jerome
>
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Linking asm with C

[Danilo Pecher]

If you are comfortable programming in Pascal, stay with it. In fact
Turbo-Pascal has pretty much the best integration of inline assembler
of all the languages I encountered in 30 years. And in general, just
don't follow tutorials blindly, collect your own experience. Maybe it
would help if you told us what exactly you are attempting to do.

On Fri, 13 Jan 2023 at 20:10, Knedlik  wrote:
>
> To be honest, I’m just following a tutorial that said it’s better to do it in 
> asm - but it’s in Pascal, so I’m translating it into C.
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Linking asm with C

[Danilo Pecher]

Accepting the danger of sounding somewhat arrogant, but you seem to
lack some basic knowledge of system programming. Are  you sure you
need assembler programming in the first place? Everything you've set
out so far is perfectly doable in C.

On Fri, 13 Jan 2023 at 17:35, Knedlik  wrote:
>
> Okay, this is just weird.
> I can’t for the love of god figure out why this is throwing the divide by 
> zero interrupt.
>
> void setMCGA() {
> _asm {
> mov al, 0x13
> int 0x10
> ret
> }
> }
>
> void setText() {
> _asm {
> mov al, 0x03
> int 0x10
> ret
> }
> }
>
> void clearScreen(char color) {
> int i;
> for (i = 0xa000; i < 0xfa00; i++) {
> char* byte = i;
> *byte = color;
> }
> }
>
> int main(int argc, char** argv) {
> setMCGA();
> clearScreen(255);
> getchar();
> setText();
> return 0;
> }
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Linking asm with C

[Danilo Pecher]

Oh dear, if you really want an answer for that, you need to give more
infos, like which linker are you using, which memory model?

On Thu, 12 Jan 2023 at 20:45, Knedlik  wrote:
>
> Hello,
> I’m currently trying to make a function in a separate assembly file, but I’m 
> having problems linking it with a C program. Are there any guides that show 
> how to do this?
> Thanks in advance,
> -Knedlik
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Bonus/Devel CD

[Danilo Pecher]

Hi all,

I say the most important thing first - I'm not very keen on a Live
DVD. One of the things that severely goes on my man-mammaries is that
every Linux, BSD and whatnot nears the 1GB mark, when a basic system
install could easily fit in a 300MB image. I don't think we have too
many casual users using FreeDOS anyway. If you run this on actual
hardware, you kept that around for a reason and know what you're
doing, and it is the same for people who configure a VM or go through
a qEmu install to run FreeDOS. So I think the best idea is to have an
install medium with the base system an close-to-system addons (like
the network packages, archivers etc) and move other things to a
Addon-CD and a Devel-CD, or just call it Applications-CD and
Developer-CD, whatever floats your boat.

cheers, Danilo

On Sun, 23 Oct 2022 at 20:46, Jerome Shidel  wrote:
>
> Although there has not been a lot of feed back on what to do with the 
> excessively (nearly 1GB) BonusCD in T2210, I think the majority of feedback 
> has been in favor of splitting off the development packages from the BonusCD 
> on to their own DevelCD.
>
> And, we should do this instead of dropping packages for several reasons. The 
> main reason is for the convenience of users who may be on older hardware or 
> without network support. Those users might experience some difficulty getting 
> all of the programs they need into their “DOS” machine.
>
> It has also been suggested to provide a “Developer Oriented” release of 
> FreeDOS. One that is specifically geared towards DOS development.
>
> Another suggestion has been to just slim down FreeDOS to basic DOS.  Leaving 
> it up to the user to find, download and install what they want after the OS 
> has been installed.
>
> Personally, I don’t think dropping everything except basic DOS is the way to 
> go. I think doing so would be off-putting to most “New” users. Although they 
> would have a fully functioning DOS, it really would not do much on it’s own. 
> It would require them to go get other software or games and create a usage 
> barrier that most would just uninstall the OS an move on to something else.
>
> Most “modern” operating systems either provide numerous bonus software. They 
> do this by either providing it on their release media or through an easy 
> method of downloading and installing software. There are many examples of 
> this in the Linux world. For example, openSUSE does both. It provides 
> thousands of extra packages on it’s release DVD and also connects to a 
> download center to provide them.
>
> Although the next major version of FDIMPLES will most likely support online 
> repositories, it is being written %100 in assembly and not coming soon. Even 
> once the new version of FDIMPLES is ready, general networking support under 
> FreeDOS is very limited. This leaves us with providing additional packages on 
> the release media for the near future.
>
> I’m unsure of the best solution to the problem.
>
> I don’t think providing a Developer Oriented skew of the OS is a good idea. 
> With the LegacyCD, LiveCD, LiteUSB, FullUSB and Floppy Edition, I think we 
> provide to many OS skews already. Since we want to support a wide range of 
> DOS hardware, we really need to keep the Floppy and CD version around.
>
> We could probably drop the LiteUSB for several reasons. I think it’s direct 
> usage is very limited and most users probably opt for the FullUSB version. 
> Also, every “how-to” and video I’ve seen online that shows how to create a 
> bootable USB stick for FreeDOS uses the LiveCD to create it. However, 
> occasionally, I do see questions on how to write one of the USB media to a 
> flash drive.
>
> We could also probably drop the LegacyCD as well. There is only a very 
> limited range of early hardware that cannot boot the LiveCD. But, it can boot 
> the LegacyCD. That hardware will most likely also have a floppy drive. If 
> their CD drive is supported by the drivers, they could boot using the “Floppy 
> Boot Image” included in the download zip. Once that is done, they can install 
> from CD.
>
> So where does that leave us? I think there are at least two practical 
> solutions at present.
>
> First, split off all development related packages that are on the BonusCD 
> onto a new DevelCD. This would require very little work. The Release Build 
> Environment (RBE) is already capable of creating multiple extra package discs 
> images. However, I will probably want to add some functionality to use 
> specific labels for them. At present, it would generate BonusCD0 and 
> BonusCD1. It will not be hard to update the RBE to use custom labels for the 
> discs. This first solution implies we may eventually have a GamesCD, UtilsCD 
> and others as well. If we go down this path, perhaps we should start 
> separating some other packages on to their own media as well.
>
> The second option is to go big. On this path, we could do away with the 
> BonusCD. We could keep the LiveCD as-is. 

Re: [Freedos-devel] Detecting VMs (was: Bonus/Devel CD)

[Danilo Pecher]

Since thengraphics cards of VMs are, as far as I'm aware generally
VESA compatible, unless you specifically decide not to use one in qemu
or bochs, you should have a relatively high hitrate by using the 4Fh
interrupt to query the VESA info. In the case of Virtualbox/VMWare,
you'll definitely find out that way.

On Wed, 26 Oct 2022 at 18:01, Jerome Shidel  wrote:
>
>
>
> > On Oct 26, 2022, at 3:40 AM, Ralf Quint  wrote:
> >
> > On 10/24/2022 6:38 PM, Bret Johnson wrote:
> >> Anyway, I'm wondering how "involved" FreeDOS should be in the VM world (I 
> >> think in today's world the vast majority of users install DOS under a VM 
> >> rather than on real hardware, though I personally do both). How involved 
> >> in testing/recommending applications (including games) for compatibility 
> >> should FreeDOS actually be, particularly when a VM is involved?
> > To be honest, we should not get involved with ANY VM at all. This will just 
> > lead us potentially into a deep dark rabbit hole that leads us far away 
> > from Kansas^H^H^H^H^H^Hthe DOS world.
> > The goal of FreeDOS is to be MS-DOS 6.0 compatible, so any VM should be 
> > able to run MS-DOS 6.0, and so should FreeDOS run as well.
> >
> > Going by the messages either here in the mailing list or the occasional 
> > post on the Facebok page, it seems the vast majority of compatibilty issues 
> > are related to support of specific hardware, mainly sound cards and network 
> > cards. That is absolutely something that is only to be solved on side of 
> > that VM.
> >
> > Another possible issue is that of incompatibilities with some memory 
> > managers included in FreeDOS. And this is a really tricky part, as there is 
> > very little active participation of the authors in order to properly 
> > diagnose and fix any such issues that would arise..
> >
> > All in all, I think venturing too far into the support of VMs is a very 
> > slippery slope for us, with only a few people actually participating
> >
> >
> > Ralf
> >
>
>
> For VM detection, it is mostly useful for current DOS application development.
>
> Without going into great details, I have made a couple programs that can do 
> some (i think) neat visual tricks that require VGA support. One such visual 
> trick works on nearly all REAL hardware and in DOSBox. However, it does not 
> work in any other tested VM. Therefore testing for any VM (that is not 
> DOSBox) and disabling the feature when appropriate is very useful to that 
> program.
>
> Also, I have seen where a VM says it supports something, yet it does not. 
> Under those, sometimes a workaround is needed.
>
> But like I previously mentioned, I really only worry about the VM platforms 
> (DosBox, QEMU, VirtualBox and VMware) I think are most common.
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] DOS runtime library format

[Danilo Pecher]

Well, one could also question the point of shared libraries in a
system that doesn't support multitasking.

Dynamic loading has a point in so far as to load binaries based on the
availability of hardware, as in the BGI drivers. Having the code to
support all gfx cards in the exe would be wasteful, so it made sense
to load them dynamically. C and PASCAl support that through their
ability to define functions as data types.

On Mon, 28 Dec 2020 at 22:30, tom ehlert  wrote:
>
> Hallo Herr Ralf Quint,
>
> am Montag, 28. Dezember 2020 um 17:06 schrieben Sie:
>
> > On 12/28/2020 2:39 AM, tom ehlert wrote:
> >> Hallo Herr Ralf Quint,
> >>
> >> am Montag, 28. Dezember 2020 um 10:59 schrieben Sie:
> >>
> >>> On 12/27/2020 10:54 PM, Mercury Thirteen via Freedos-devel wrote:
>  Hey, all! Just a question I've never seen addressed here - or anywhere
>  else, for that matter.
> 
>  Was there ever any "official" format for a shared runtime library
>  under MS-DOS? Windows has .DLL files, Linux has .KO files, and MS-DOS
>  had... what, exactly? In all my years DOSsing I've never heard of
>  anything official like this, so I'm pretty sure there was no such
>  thing (unless you count a TSR, but that's not really what I'm after)
>  but I figured it doesn't hurt to ask you folks, as you have more years
>  under various flavors of DOS than I.
> 
>  Any constructive feedback would be appreciated! :D
> >>> Well, it is very simple. There is no such thing under DOS...
> >> This almost would have been my answer as well.
> >>
> >> But I recently learned 
> >> http://www.bttr-software.de/forum/board_entry.php?id=17354
> >> that there exists Borland BGI (Borland Graphics Interface) drivers
> >> that are arguably equivalent to DLLs (for Borland compilers) as they
> >> are separately compiled binaries.
> >> So this is not a DOS, but Borland standard.
> >>
> >> I know of no other example of this.
> >>
> > Yeah, that came to my mind too, but then it is commonly referred to as
> > drivers, so it is a border line case of this kind of functionality, but
> > it is not a "shared runtime library under DOS"...
>
> 'drivers' usually refers to functionality available to everyone, and
> the interface are defined by the OS.
>
> BGI 'graphic drivers' were only open to Borland compilers; I'd call
> them runtime libraries.
>
> but this is more wording then actually functionality difference.
> no point to have a long thread discussing this ;)
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] DOS runtime library format

[Danilo Pecher]

IIRC there was never something like a standard DLL concept, but we
used to use flat binaries for that concept. Back in 1994 or something,
a friend of mine and I wrote something akin to fractint and we defined
a 'fractal driver' for each type. What it basically boiled down to was
typedef'ing a function type in the calling program, then pointing it
at a dynamically loaded flat binary and calling it.

Cheers, Danilo

On Mon, 28 Dec 2020 at 11:40, tom ehlert  wrote:
>
> Hallo Herr Ralf Quint,
>
> am Montag, 28. Dezember 2020 um 10:59 schrieben Sie:
>
> > On 12/27/2020 10:54 PM, Mercury Thirteen via Freedos-devel wrote:
> >> Hey, all! Just a question I've never seen addressed here - or anywhere
> >> else, for that matter.
> >>
> >> Was there ever any "official" format for a shared runtime library
> >> under MS-DOS? Windows has .DLL files, Linux has .KO files, and MS-DOS
> >> had... what, exactly? In all my years DOSsing I've never heard of
> >> anything official like this, so I'm pretty sure there was no such
> >> thing (unless you count a TSR, but that's not really what I'm after)
> >> but I figured it doesn't hurt to ask you folks, as you have more years
> >> under various flavors of DOS than I.
> >>
> >> Any constructive feedback would be appreciated! :D
>
> > Well, it is very simple. There is no such thing under DOS...
>
> This almost would have been my answer as well.
>
> But I recently learned 
> http://www.bttr-software.de/forum/board_entry.php?id=17354
> that there exists Borland BGI (Borland Graphics Interface) drivers
> that are arguably equivalent to DLLs (for Borland compilers) as they
> are separately compiled binaries.
> So this is not a DOS, but Borland standard.
>
> I know of no other example of this.
>
> Tom
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi

Ralf makes a very interesting and important point here, especially as it
reminds me of my idealistic and somewhat overconfident self from 1993. Like
many people back in the day I thought I was a l33t hax0r after three years
of dabbling with Turbo-Pascal, Turbo-C and even some assembler. So,
naturally, I started to make grand plans to write a proper GUI for DOS.
Sadly, those grand plans consisted of starting up the IDE and get cracking.
Things like proper planning, defining interfaces - in my 1993 delusions of
grandeur that was for wimps. Needless to say; I went very fast, very
straight, nowhere when it became apparent that such an undertaking is, to
use a technical term, a s**tload of work.

And that was my thinking behind it. Writing yet another nondescript GUI
would be sort of pointless. The main strength of FreeDOS is its ability to
keep legacy software alive. But by definition there's no legacy software
available for a GUI that's written in 2020. Getting close to a free Windows
3 clone however would be a perfect continuation of a project that keeps
legacy stuff around. And more importantly, with the wine project there is
already a solid foundation on which such a project could be based.

Cheers, Danilo

On Mon, 28 Dec 2020 at 00:08, Ralf Quint  wrote:

> On 12/27/2020 11:10 AM, Jim Hall wrote:
>
>
> The challenge we've had is lots of developers have wanted to create a GUI
> for FreeDOS, but then they get halfway through building one before they
> realize it's a lot of work. And then the project gets dropped. That leaves
> us with things like SEAL and oZone that look cool - until you look more
> closely and find a bunch of features that don't work. Or it hogs memory. Or
> whatever. And that brings us to the conversation we started here some weeks
> ago about removing some stale packages, like SEAL and oZone. I don't want
> to get into another situation like that.
>
> Well, that is the problem with all of those GUI attempts. Some people have
> grand ideas and start to create some nice colored pictures but none of them
> is seriously thinking about (before they start coding!) on all the basics
> "behind the scenes", to make things really work and being useful.
> And when you point this out to them, they quickly get all defensive and
> pissy...
>
> IMHO, anyone who is REALLY interested to get  a working GUI for FreeDOS
> working, should much rather looking into participating in getting (Open)GEM
> a little bit more up to date.
>
> Ralf
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4749868332659970652_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi,

Wouldn't you reinvent the wheel with that? 32 bit DOS applications
rely on a DOS extender and run okay that way, and to run 32bit WIndows
applications, well, that's literally one of the purposes of ReactOS.
What got me thinking was when I could no longer run Borland Delphi on
Windows, because 16bit. Up to Windows XP and to a degree Windows 7,
you could still run old win3x (and even most win 2x) applications
natively. In windows 10 that's gone for good, which is why I thought,
with FreeDOS being by far the best platform for legacy software, this
might be something worth looking at.

But maybe that's just last century me ;)

Cheers, Danilo

On Fri, 25 Dec 2020 at 02:35, Mercury Thirteen via Freedos-devel
 wrote:
>
> Just a bit of FYI despite the project being nowhere near ready to go as of 
> yet: there is a small group of us working on moving DOS into the 32-bit realm 
> in the form of the Night Kernel. As part of that journey, we eventually want 
> a compatibility layer to make running Windows 3.x executables possible.
>
>
>
> Sent with ProtonMail Secure Email.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, December 24, 2020 6:52 PM, Danilo Pecher 
> danilo.pec...@data-experts.biz wrote:
>
> Hi Eric,
> The ReactOS/Wine combo was what got me thinking in the first place.
> ReactOS was from the start meant to replicate WIndows NT though, which
> isn't quite what I had in mind, as that isn't quite the 16 bit world
> in which FreeDOS exists. Wine would be a starting point, as that
> definitely has 16 bit remnants, like WING. Back many moons ago I used
> some of that source to port Microprose's Grand Prix manager to SDL
> under Linux.
> My idea was more along the line of rebuilding Windows 3.11, Best
> windows ever, even if Jim will probably disagree ;)
> Cheers, Danilo
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi Eric,

The ReactOS/Wine combo was what got me thinking in the first place.
ReactOS was from the start meant to replicate WIndows NT though, which
isn't quite what I had in mind, as that isn't quite the 16 bit world
in which FreeDOS exists. Wine would be a starting point, as that
definitely has 16 bit remnants, like WING. Back many moons ago I used
some of that source to port Microprose's Grand Prix manager to SDL
under Linux.

My idea was more along the line of rebuilding Windows 3.11, Best
windows ever, even if Jim will probably disagree ;)

Cheers, Danilo


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

[Freedos-devel] New packages for future releases

[Danilo Pecher]

Ho,ho, everybody,

First of all, merry holidays to all and I hope you're all safe in
these difficult times.

As the new year looms, it's time to get them new years resolutions in.
I'm foregoing the usual stuff, like losing weight, because that won't
work, just like the other years. Instead, inspired by #DOScember, I
got back into DOS programming and I started to port some of my old
early 90s projects from PASCAL to C and/or assembler.

So here's the question: Is there a process to pitch new packages for
possible inclusion in future releases? At the moment I'm porting my
old textmode font utils, which are in a way comparable to the existing
gnuchcp package, but go beyond that. The fontloader can load two fonts
and enable the VGA 512 char mode and it also loads fixed-width X11 bdf
and pcf fonts. They also include a font editor that runs in text mode.

The second question is a more speculative one. FreeDos is doing an
excellent job of running legacy software, and I think other than
adding more hardware support, it is pretty much as good as it gets.
Which got me thinking. Windows 3.11 has tons of legacy software, so
there's me wondering:

a) Has there ever been an attempt at creating a FreeWin?

b) Knowing that Jim dislikes it with a passion, would there even be
interest in it?

Enough rambling from me. Enjoy your holidays, everybody,,
and stay safe :)


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

Re: [Freedos-devel] Jordan Hargraphix SvgaBGI goes MIT license

[Danilo Pecher]

It happens on both Virtualbox and my ancient Compaq NX-8220. And
indeed, as hinted by several folks, it seems to be connected to fdapm.

On Mon, 21 Dec 2020 at 20:03, Robert Riebisch  wrote:
>
> Hi Danilo,
>
> > I still have legal copies of Turbo Pascal 3.0, 4.5, 6.0 and Borland
> > Pascal 7.0, so if there's interest, I'd be willing to take a look at
> > them to see if there's any insects to weed out.
>
> It might be interesting only, if some existing project already relies on
> these drivers.
>
> The, probably better, von Bassewitz drivers are also under zlib license.
>
> > Speaking of which. I noticed that pretty much all Borland Test-mode
> > IDE's for Turbo-C, Turbo Pascal and Turbo-Prolog react very sluggishly
> > in FreeDOS while working okay on MS-DOS and PTS-DOS. Anyone got a clue
> > what might cause this?
>
> Is this real hardware or some emu./virt. environment?
>
> Cheers,
> Robert
> --
>   +++ BTTR Software +++
>  Home page: https://www.bttr-software.de/
> DOS ain't dead: https://www.bttr-software.de/forum/
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Jordan Hargraphix SvgaBGI goes MIT license

[Danilo Pecher]

BGI ran like a three-legged pregnant hippo in a mud pit, mainly
because it used the INT10h functions. Pretty much everyone I know, who
also started programming in the late 80s got their first taste of
inline assembler and hardware programming, when we realized that you
could speed up things by magnitudes by just vomiting your data
straight into the A000h segment. In fact I blew up at least 3 monitors
by fooling around with port-registers on my ridiculously expensive
Realtek 512KB SVGA card in an attempt to initialize the weirdest
256-color modes, like 734x412 and somesuch.

On Mon, 21 Dec 2020 at 07:55, Bitácora de Javier Gutiérrez Chamorro
(Guti)  wrote:
>
> I used them in the past but soon moved to SVGA386.BGI by Ullrich von 
> Bassewitz with are a lot of faster (https://www.von-bassewitz.de/uz/bgi.php)
>
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Remitente:Robert Riebisch 
> Destinatario: freedos-devel mailing list 
> Fecha:domingo, 20 de diciembre de 2020, 20:02:21
> Asunto:   [Freedos-devel] Jordan Hargraphix SvgaBGI goes MIT license
> Archivos: 
> --===--
> (To whom it may concern.)
>
> In April 2020 I got in touch with Jordan Hargrave, who wrote SVGA BGI
> drivers for Turbo C/Turbo Pascal/Borland C++ until the mid-1990s:
> 
>
> Jordan wrote on 19 December:
> #
> Hi Robert,
>
> If you are still interested in the BGI drivers, I found an old box of
> disks which had my original Svga driver source on it! So I've now posted
> that up to github.
> It would be interesting to know if they still work!!
>
> https://github.com/jharg93/SvgaBGI
>
> Enjoy!
> --jordan hargrave
> #
>
> According to the Wikipedia article, which I updated accordingly, there
> are bugs in the drivers, which can be fixed now.
>
> Cheers,
> Robert
> --
>   +++ BTTR Software +++
>  Home page: https://www.bttr-software.de/
> DOS ain't dead: https://www.bttr-software.de/forum/
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Jordan Hargraphix SvgaBGI goes MIT license

[Danilo Pecher]

I still have legal copies of Turbo Pascal 3.0, 4.5, 6.0 and Borland
Pascal 7.0, so if there's interest, I'd be willing to take a look at
them to see if there's any insects to weed out.

Speaking of which. I noticed that pretty much all Borland Test-mode
IDE's for Turbo-C, Turbo Pascal and Turbo-Prolog react very sluggishly
in FreeDOS while working okay on MS-DOS and PTS-DOS. Anyone got a clue
what might cause this?

Cheers, Danilo

On Sun, 20 Dec 2020 at 23:37, Robert Riebisch  wrote:
>
> (To whom it may concern.)
>
> In April 2020 I got in touch with Jordan Hargrave, who wrote SVGA BGI
> drivers for Turbo C/Turbo Pascal/Borland C++ until the mid-1990s:
> 
>
> Jordan wrote on 19 December:
> #
> Hi Robert,
>
> If you are still interested in the BGI drivers, I found an old box of
> disks which had my original Svga driver source on it! So I've now posted
> that up to github.
> It would be interesting to know if they still work!!
>
> https://github.com/jharg93/SvgaBGI
>
> Enjoy!
> --jordan hargrave
> #
>
> According to the Wikipedia article, which I updated accordingly, there
> are bugs in the drivers, which can be fixed now.
>
> Cheers,
> Robert
> --
>   +++ BTTR Software +++
>  Home page: https://www.bttr-software.de/
> DOS ain't dead: https://www.bttr-software.de/forum/
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

I agree Jim,

If you go for effective, then the standard FreeDOS window is certainly not
the ideal solution, and perhaps I should have made it clearer that my
remark to Tom wasn't meant overly seriously.

The nice thing about FreeDOS is that you have choice these days, unlike in
the days of yore, so there's something for everybody. You even have choice
of compilers. Personally, I probably never really left the 90s, so I feel
right at home in an 80x25 world. I run CDE on my Linux and BSD Systems, so
my X11 looks still the same as it did on a 1997 Sparc Station, and my
Terminals always start in 80x25, black background, green text - because
that's what the screen looked like on my old A7150 in 1990, a haphazardly
cobbled together East German IBM PC clone. I'm just weird I guess ;)

Cheers, Danilo

On Thu, 3 Dec 2020 at 01:04, Jim Hall  wrote:

>
>
> On Wed, Dec 2, 2020 at 8:05 AM tom ehlert  wrote:
>
>> Danilo,
>> > Sorry, but I think you're too snippy here.
>>
>> > First of all, if the idea of an 80x25 single file editor frightens
>> > you, you're either a wimp or too young to have done any programming
>> > when that was the norm.
>>
>> my first 'editor' were punched cards.
>>
>> next came a single line editor (TECO on a PDP10), roughly comparable
>> to EDLIN. that was a HUGE improvement. I would never go back to
>> punched cards.
>>
>>
>> next came a full screen 25*80 editor; first VI on UNIX, with HJKL
>> cursor movement commands. that was a HUGE improvement. I would never go
>> back to
>> EDLIN.
>>
>> now it's two 28 inch monitors, with google search, RBIL, editor,
>> program output and debugger all living nicely side by side.
>> that was a HUGE improvement. I would never go back to
>> single screen 25x80. FOR DEVELOPEMENT!
>> [..]
>>
>
>
> I write code in FreeDOS and for FreeDOS, like when I recorded the "How to
> program in C" video series. I use the FED editor, which is probably my
> favorite programming editor under FreeDOS. The code syntax highlighting is
> a nice feature.
>
> But 80x25 is a very small "window" for effective coding. So I usually do
> not code on FreeDOS. I use a full screen editor on my Linux desktop system,
> and transfer the files to FreeDOS. This was a lot easier when I used DOSEmu
> to run FreeDOS - DOSEmu booted from a directory in your Linux home, so you
> could edit a file on Linux and it would appear immediately in your running
> DOSEmu session. But since DOSEmu hasn't been updated in a while (haven't
> checked DOSEmu2 lately) I do it another way with QEMU.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Hi Tom,

Well, I guess we'll have to agree to disagree then, and maybe I'm just
weird. I'm the sort of guy that actually would look for spare parts on
horse back, because that's way more fun. Probably not for the horse though,
considering that, unlike 30 years ago, I weigh more than Belgium these
days.

As for using the best available tools - if that means using a completely
different OS, I think it sort of beats the purpose of the exercise. If I
wanted to do Dos programming on Linux, I could just as well use Dosbox. Of
course, with your 28 inch home cinema with all the bells and whistles,
you'll most likely beat the pants off me as far as productivity goes, but
that's where our idea of FreeDOS differs.

What you describe is programming for maximum efficiency. That's something I
use on my day job, but not when I'm programming for the fun of it. When I'm
programming for FreeDOS, I'm doing it IN FreeDOS. And on the whole I tend
to keep it as simple as possible in the first place. I've had people laugh
at me, because I do my C and C++ programming in vi (or vim, I've developed
a sense of luxury with age), but the thing is, no matter what sort of Unix
box you're tasked to work on, you'll always have vi. And you even have one
in FreeDOS, which is good, because it would drive me potty to use a
different editor, punching ESC everytime I want to save my file.

And that's not just crazed nostalgia even. I'm a freelance IT contractor. I
do everything from programming to database administration. In 2014, I
landed myself a sweet one-year contract as an Oracle dba with Volkswagen in
Wolfsburg. (I had nothing to do with the exhaust systems, just to make
sure). When it comes to Oracle administration you have a whole smorgasboard
of powerful tools, like TOAD, and knowing those is a nice thing, but had
those been my primary tools, I would have lasted exactly one day in that
contract, because they didn't allow access to the servers by anything than
ssh, and the servers were basically vanilla Solaris or HP-UX setups with an
Oracle server slapped on, so basically all you had at your disposal was vi
for text editing and sqlplus for running sql queries or scripts. People
came and went, sometimes the same week they arrived, because they didn't
have the experience to use the 'steam age tools'. It's nice know how to use
an electric drill, but you're three miles up the creek without a paddle in
a leaking canoe if the power is out and that's the only way you know of
drilling a hole.

Now that's of course an extreme example. I've worked at banks too and even
they weren't that restrictive. You obviously know your way around and if
you prefer the 28 inch option, all power to you. I'm the sort of guy who's
happy toiling about drilling holes using his hand-cranked drill, and only
uses the electric one if the hole-drilling is urgent.

Cheers, Danilo

PS: I'll take you up on the slide-show request. Any excuse to fiddle with
VGA registers is a welcome one. But since I'm one of the few lucky bastards
whose job has survived the lockdown, I'd like to ask you for waiting till
the weekend comes around.

On Wed, 2 Dec 2020 at 15:06, tom ehlert  wrote:

> Danilo,
> > Sorry, but I think you're too snippy here.
>
> > First of all, if the idea of an 80x25 single file editor frightens
> > you, you're either a wimp or too young to have done any programming
> > when that was the norm.
>
> my first 'editor' were punched cards.
>
> next came a single line editor (TECO on a PDP10), roughly comparable
> to EDLIN. that was a HUGE improvement. I would never go back to
> punched cards.
>
>
> next came a full screen 25*80 editor; first VI on UNIX, with HJKL
> cursor movement commands. that was a HUGE improvement. I would never go
> back to
> EDLIN.
>
> now it's two 28 inch monitors, with google search, RBIL, editor,
> program output and debugger all living nicely side by side.
> that was a HUGE improvement. I would never go back to
> single screen 25x80. FOR DEVELOPEMENT!
>
>
> > May I introduce you to Turbo Pascal 3.0? 80x25 text is the best there is.
> Turbo Pascal was really impressive. in 1990.
>
> > Programming 'something useful' is a subjective term. If you program
> > on FreeDOS, you are by definition programming for a fringe audience,
>
> you obviously don't understand the difference between 'programming on'
> and 'programming for'.
> and I simply want to have the best tools possible when programming for
> FreeDOS.
>
>
> even if your hoppy is a steam engine, you don't use steam age tools to
> take care of your steam engine. you use probably electric drills and
> go by car to find spare parts, not on horse back.
>
>
>
>
>
> > For me, FreeDos allows me to go back to the days when programming
> > was actually a testament to your skills, rather than just being able
> > to cobble a few lines of code together and nail a GUI on it by
> click-and-point.
>
> for a start: why don't you show us your slide show program for DOS,
> using any tools you like.
>
> talk 

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

wireless, I don't even go there, it's an iwi that need proprietary Intel
firmware - no sale.

No, the machine is a geriatric Compaq Nx8220 and the NIC in question is a
Broadcom Ethernet card. BCM5751M.

On Wed, 2 Dec 2020 at 00:09, Eric Auer  wrote:

>
> Hi!
>
> > laptop is 15 years old, and even that has hardware that is 'too new'
>
> You mean wireless?
>
> > I think you're asking two implicit questions here: a) Should we abandon
> > 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.
>
> No. Things which work well with 640k can AND should stay 16 bit :-)
>
> Just relax that requirement for things which work BETTER in 32 bit.
>
> > why FreeDOS?
>
> Because you can :-) And because many DOS apps already exist.
>
> > Not trying to get too philosophical here
>
> Who knows ;-)
>
> > FreeDos needs to find its main purpose and then adjust course
>
> It already has a purpose - the question is what you want to change.
>
> Regards, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Hi Eric,

Well, your argument is compelling, but I think it sort of misses the point.
FreeDOS is a system for legacy hardware - I mean - really legacy. My oldest
laptop is 15 years old, and even that has hardware that is 'too new' and
not supported by FreeDOS. I'm currently trying to nail a Packet driver
together for its Broadcom Nextreme NIC, but if that'll work is a matter of
'we'll see'.

I think you're asking two implicit questions here: a) Should we abandon 16
bit hardware as nobody has any, which would mean FreeDOS goes 32bit.

The second question is: What is it for? If you have 32bit hardware in the
first place, And except for a few stray early pentiums we're talking about
machines that can run dosbox at reasonable speeds, why FreeDOS? I mean, you
can run just about every DOS Software on a puny littleRaspberry Pi.

Not trying to get too philosophical here - I like FreeDos for he nostalgic
fuzzies - but that group is a rather small one.I think FreeDos needs to
find its main purpose and then adjust course accordingly.

sorry for the rambling, it's been a long day...

On Tue, 1 Dec 2020 at 23:30, Eric Auer  wrote:

>
> Danilo,
>
> > First of all, if the idea of an 80x25 single file editor frightens you,
> > you're either a wimp or too young to have done any programming when that
> > was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
> > best there is.
>
> Tom is neither, but you could argue that he could use more modern,
> more advanced editors for DOS, with higher text mode resolutions.
>
> On the other hand, his impressive FreeDOS development track record
> shows that cross-compiling from another system or using DOS in a
> window while using another host operating system for the rest of
> your activities does not keep you from being productive DOS-wise :-)
>
> I think it is an important point that ancient machines are no longer
> widespread. There is little use in having a 640k, 16-bit scandisk
> or defrag for FAT32, if nobody has managed to connect a large disk
> to such ancient hardware. So it is fine for me that dosfsck needs
> a 386 to check FAT32 partitions.
>
> People today seem to be more worried about the other end of the
> spectrum: Why is DOS limiting them to 2 TB disk size or 3 GB of
> RAM, running on only 1 of their 16 CPU cores? Not that I would
> know ANY application for DOS which would need that kind of power,
> I agree that people wonder whether DOS *may* use it, now that the
> 2020 PC on their desk has it anyway :-)
>
> Cheers, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Tom,

Sorry, but I think you're too snippy here.

First of all, if the idea of an 80x25 single file editor frightens you,
you're either a wimp or too young to have done any programming when that
was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
best there is.

As for not finding a 486 machine that hasn't got a Pentium - that's not the
point - Dos was written for pre-386 processors and unless you want to chuck
that heritage overboard with FreeDOS, it should remain able to work on
those machines.

Programming 'something useful' is a subjective term. If you program on
FreeDOS, you are by definition programming for a fringe audience, unless we
can find a new market for FreeDOS (like the SBCs I mentioned earlier). The
legacy gamers are better off just slapping a dosbox on whatever system
they're using. Programming for FreeDOS is basically done because you like
it that way, a labour of love if you want, but you won't reach a huge
audience. Personally, if I was in charge, people at university would still
start programming on DOS to learn things like memory management, something
that modern languages hide behind ridiculously bloated runtimes. Sadly, I
am not in charge.

For me, FreeDos allows me to go back to the days when programming was
actually a testament to your skills, rather than just being able to cobble
a few lines of code together and nail a GUI on it by click-and-point.

Cheers, Danilo

On Tue, 1 Dec 2020 at 20:36, tom ehlert  wrote:

> P.S.:
>
> I have done a LOT of programming for FreeDOS.
> this includes Kernel, command, lba boot sector, himem, emm386, mkeyb,
> kitten, fdisk, and probably more.
>
> not a single edit or compile were done on DOS.
> just the idea of a single file, 25*80 editor frightens me.
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

I would agree with Ralf on most points.

As for the 16 bit C-Compiler, I think Turbo-C fits that bill but acquiring
it legally requires a registration with embarcadero, so not exactly optimal
and not everyone is an old hack like me, who started coding in 1989 and
still legally owns nearly every Borland Compiler ever released.
What is with the OpenWatcom compiler? Does that need an extender too? Else
we're looking at a completely new project, and as much as I feel tempted by
it, such work would only make sense if there was enough interest and at
least a small group of people volunteering to work on it.

A 16-bit Pascal compiler would probably be the easier choice to start with
as the language is better structured and easier to compile.

The biggest barrier in my view is that FreeDOS is still a bit of a toy for
old hacks like me, who can't let go of the past when programmers had to
actually code properly instead of relying of monstrous languages that come
with garbage collectors and whatnot and leave you with memory-leaking
megabyte-sized executables. When I go into my local supermarket, they have
these large LCD-screens that usually display the latest discount deals, but
these days tell people to wear their mask and how far you need to stay away
from each other. Every other day the thing bombs out with a windows blue
screen and I thinks to myself - Why? Why run a windows system for what is
effectively a simple slide show? This would be a prime example for slapping
in a SBC with a small SD card and DOS in it. But it seems that nobody
builds such SBCs, even though considering DOS's modest requirements, you'd
think they could make such things dirt cheap.

So apart from the software I think FreeDOS needs to find a market for
serious use other than retro afficionados, and cheap SBCs would be
something that could work. Maybe we should port FreeDOS to the raspberry Pi
;) Just kidding...

Cheers, Danilo



On Tue, 1 Dec 2020 at 05:12, Ralf Quint  wrote:

> On 11/29/2020 6:17 AM, zz zz wrote:
> > I would much rather see some efforts in reviving some true DOS versions
> of programming languages, in a open source form. That also run on DOS, not
> require cross compiling on a multi-GB graphical OS.
> >Sounds interesting, but what exactly do you mean by "DOS versions" of
> such languages? As in previous versions of the C standard for example? or
> perhaps the borland "mannerisms"?
>
> A easily working 16bit version of FreePascal that can compile a large
> amount of old Turbo Pascal code, for example. And can run on DOS. Or a
> proper DOS version of (Open)COMAL, a nice structured interpreted
> programming language that to this day is still used to teach
> programming, kind of like a "better BASIC". Or a true 16bit C compiler,
> that runs on FreeDOS. Or a 16bit dBASE clone. Or Modula 2...
>
> In general, it would be nice to see some people really programming FOR
> DOS again, creating useful Open Source DOS application that people can
> actually use. Not just trying to recompile some behemoth Linux took that
> isn't really suited for DOS, and that to make things work require
> another behemoth development system ported from Linux, shoehorning both
> into the limitations of DOS.
>
> Ralf
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel