Re: [Freedos-devel] Contribution of Free Source Code without License for Everyone

[tom ehlert via Freedos-devel]

>> :http://master.dl.sourceforge.net/project/api-simple-completa/

> Warning! Malware detected. Download at your own risk.

> Just go away.

correction. on virustotal.com 32 major virusscanners found no issue with the 
.zip.

I don't know what sourceforge is complaining about.

Tom



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

Re: [Freedos-devel] Contribution of Free Source Code without License for Everyone

[tom ehlert via Freedos-devel]

> :http://master.dl.sourceforge.net/project/api-simple-completa/

Warning! Malware detected. Download at your own risk.

Just go away.

Tom



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

Re: [Freedos-devel] zoo

[tom ehlert via Freedos-devel]

>> 64 Ki * 16 KiB = 1024 MiB. (The actual maximum amount of clusters is of
>> course slightly less than 64 Ki, to be exacting.) So you're off-by-one,
>> a "2 GB" file system cannot possibly be fully utilised with FAT16 at a
>> 16 KiB per cluster size.

> Ah, OK. My apologies.

> Off-by-one errors are of course one of the two hardest problems in
> computer science, 

Off-by-one errors are indeed hard to catch once you made them.
Off-by-a-factor-of-two is usually NOT hard to catch.

> along with cache invalidation and naming things.
other then throwing buzzwords around you heard about (without probably 
understanding what they mean) how does this help?

Tom



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

Re: [Freedos-devel] zoo

[tom ehlert via Freedos-devel]

Hi Wilhelm ,

am Donnerstag, 23. Mai 2024 um 12:56 schrieben Sie:

> Hi Tom,
>
> Thank you for not having a choleric attack!

;)

   
> FDT24xx are monthly trial versions (if I remember right, you know it for two 
> or three months now).  
I know about "FreeDOS distributions", but I don't care much.


> While working on FD help I ran a lot of tests with all these programs and 
> noticed a lot of bugs.  
And I'm thankful for that.
Problem is that there are so few programmers left, so many bugs will be left 
"forever" unfixed because nobody cares.


> I agree with you that zoo working on FAT16 only is not important for FDT 
> (with the working FAT32 support - I have the binary - it would have looked 
> different). 
It's FAT16 > 1GB or FAT32 for software that doesn't understand FAT32

> I agree that there are a lot of other tools that could be removed from 
> FDT24xx. Outdated compressors are not the worst proposal.  
YEP. I don't mind if there would be a *findable*link to ZOO or UNZOO. But 
having these as part of any distribution is ridiculous.


> But I got the feedback from Jerome  to ask the FD mailing list first as it is 
> not possible to remove it if only one person  
> asks for removing. So I did this.   

So Jerome is now suddenly the official rule maker for FreeDOS? I don't remember 
dicussing this.

> Here are some more. Strictly spoken I would have to create two new posts now, 
> but I hope it is ok for Jim.  
>
> There are at least two other programs on FDT where I will ask the mailing 
> list now:  
>
> a) fdtui - a mixture between dosshell and an NC clone - please check it, I am 
> sure you will confirm, (sorry, Berki)

fdtui. my first *visual* program by a 12 years old. how that would slip behind 
any quality control is beyond me.

> b) localcfg - creates a country.sys. Version 0.9 is out of date - and the 
> latest version is still buggy with the options.  
I never tested this. but by it's own description I vote "dismiss".

Tom



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

Re: [Freedos-devel] zoo

[tom ehlert via Freedos-devel]

>> it seems that no knowledgable person  finds zoo interesting enough to fix it.
>> and those who care about zoo have no clue.
>> I regret that I have to say this.
>>
>> Tom

> Was zoo even popular in its heyday?
I don't think so.

> I feel like when it comes to DOS, for the last 30 years it's been exclusively 
> ZIP, except in Japan where it's been exclusively LHA...

I don't know about Japan(where Freedos is probably not no popular due to 
characterset isseus), but everybody else should use ZIP.

just remove ZOO and all other (ARC,...) archivers. It's ok to retain them 
somewhere on the internet (to be downloaded if needed 
for some reason) but not as part of FreeDOS distribution.

One of the few cases where deleting the program actually 'solves' the problem.

Tom



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

Re: [Freedos-devel] zoo

[tom ehlert via Freedos-devel]

Hallo Herr Wilhelm Spiegl via Freedos-devel,

am Mittwoch, 22. Mai 2024 um 13:14 schrieben Sie:

> Hi,
> thank you for these important informations referring to zoo.  
> But: A teacher would say: You have missed the point, I have to give you the 
> worst grade for it.  
> Reason: The comments will not create a bugfix packet. I am sure that the old 
> version of zoo will be in FDT2406 too.  
> OK, then let us keep it.  
> Sometimes I have the feeling this is intention - or a very strange discussion 
> culture.  
> I regret that I have to say this.  

it seems that no knowledgable person  finds zoo interesting enough to fix it.
and those who care about zoo have no clue.
I regret that I have to say this.

Tom

> W. Spiegl
>   
>   
> Sent: Tuesday, May 21, 2024 at 8:21 PM
> From: "E. C. Masloch via Freedos-devel" 
> To: freedos-devel@lists.sourceforge.net
> Cc: "E. C. Masloch" 
> Subject: Re: [Freedos-devel] zoo  
> On at 2024-05-19 00:37 +0100, Liam Proven via Freedos-devel wrote:
 >> On Fri, 17 May 2024 at 17:14, tom ehlert via Freedos-devel
 >>  wrote:
 >>
 >>>> Below 1GB FAT16 uses 8kB clusters. From 1GB-2GB it uses 16kB ones.
 >>>> (Below ½GB it uses 4kB.)
 >>>
 >>> That would require FAT17.
 >>
 >> (?)
 >>
 >> Not at all.

>  64 Ki * 16 KiB = 1024 MiB. (The actual maximum amount of clusters is of
>  course slightly less than 64 Ki, to be exacting.) So you're off-by-one,
>  a "2 GB" file system cannot possibly be fully utilised with FAT16 at a
>  16 KiB per cluster size. Hence tom's suggestion of FAT17.

 >> Here is the full list:
 >>
 >> FAT12
 >>
 >> Drive size Secs/cluster Cluster size
 >> < 16 MB 8 4 KiB
 >>
 >> FAT16
 >>
 >> Drive size Secs/cluster Cluster size
 >> < 128 MB 4 2 KiB
 >> < 256 MB 8 4 KiB
 >> < 512 MB 16 8 KiB
 >> < 1 GB 32 16 KiB
 >> < 2 GB 64 32 KiB

>  This supports what tom and I wrote: up to (nearly) "2 GB" you need 32
>  KiB per cluster.

 >> < 4 GB 128 64 KiB (Windows NT only)

>  I agree with this. Enhanced DR-DOS, FreeDOS, and my MS-DOS v4 fork also
>  support 64 KiB per cluster now.

 >> < 8 GB 256 128 KiB (Windows NT 4.0 only)
 >> < 16 GB 512 256 KiB (Windows NT 4.0 only)

>  EDR-DOS, FreeDOS, and lMS-DOS also support 128 KiB clusters, using 256
>  Sectors per Cluster. For further comment see below.


 >> FAT32
 >>
 >> Drive size Secs/cluster Cluster size
 >> < 260 MB 1 512 bytes
 >> < 8 GB 8 4 KiB
 >> < 16 GB 16 8 KiB
 >> < 32 GB 32 16 KiB
 >> < 2 TB 64 32 KiB

>  It seems that a 2 TiB file system could actually use 8 KiB per cluster
>  if you were willing to tolerate a FAT size of 1 GiB each. (1 GiB is the
>  maximum size of a FAT's usable data in FAT32.)

>  2 * 1024 * 1024 * 1024 * 1024 / (2 ** 28) = 8192.

>  Not claiming any formatting tool does this, but the numbers check out.

>  (If anyone is confused about 2 to the power 28, this is because FAT32
>  actually reserves the top 4 bits of every 32-bit FAT entry. They're
>  masked off by drivers and never set by anyone AFAIK. So the usable
>  amount of entries is 2 ** 28, not 2 ** 32.)

 >> Source:
 >> https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
 >>
 >> Confirmation:
 >> https://www.researchgate.net/figure/Default-cluster-size-for-FAT-compatible-OS_tbl1_261851917

>  To get to the "Windows NT 4.0 only" entries: I'd never heard of any MSW
>  supporting 256 Sectors per Cluster. Let alone 512. I didn't find any
>  other source that confirms this or even explains how such large SpC
>  values are to be encoded in the file system in order for a driver to use
>  them. I was also under the impression that EDR-DOS was the first
>  implementation of FAT FS with 256 SpC.

>  The only other source I found that supports the possibility of 256 KiB
>  clusters is in the English Wikipedia page for FAT, in the FAT16B info box:

 >> Max volume size
 >>
 >> 2 GB (with 32 KB clusters)
 >> 4 GB (with 64 KB clusters) (NT 4, PTS-DOS, EDR-DOS)
 >> 8 GB (with 128 KB clusters and 1 or 2 KB sectors) (NT 4 and
>  EDR-DOS only)
 >> 8 GB (with 128 KB clusters and 512 byte sectors) (EDR-DOS only)
 >> 16 GB (with 256 KB clusters and 2 or 4 KB sectors) (NT 4 only)

> https://en.wikipedia.org/wiki/File_Allocation_Table#Final_FAT16

>  You will note that the "8 GB" limits listed use 512 BpS only for the
>  EDR-DOS 256 SpC extension, only. The other "8 GB" and the "16 GB"
>  specify larger sector sizes. That would explain how to get to a 256 KiB
>  cluster, without even the 256 SpC extension.

>  Regards,
>  ecm


>  ___
>  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

Re: [Freedos-devel] zoo

[tom ehlert via Freedos-devel]

>> I ran one more test with zoo. It runs with FAT16 998 MB but not with FAT16 
>> 1025 MB.

> Below 1GB FAT16 uses 8kB clusters. From 1GB-2GB it uses 16kB ones.
> (Below ½GB it uses 4kB.)

That would require FAT17.

and indeed the problem (which was solved in january) is with clustersize
32KB that is erronously interpreted as negative 32K.

Tom



___
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?

[tom ehlert via Freedos-devel]

Hallo Herr Ralf Quint via Freedos-devel,

am Mittwoch, 8. Mai 2024 um 20:30 schrieben Sie:

> On 5/8/2024 1:22 AM, tom ehlert via Freedos-devel wrote:
>>> It's on the website, under the "developer" section.
>> in my version of firefox, there is no "developer" section onwww.freedos.org
>>
> Look again, in my Firefox (125.03, on Windows 10/64) it is right below and 
> slightly to the right of the blue "Download FreeDOS 1.3" button, one of those 
> three rather prominent boxes linking to "Playing Game", "Running 
> applications" and, wait for it,  "For Developers". 

you are right, and I was 100% wrong.

I have no idea why I overlooked for so long time...

unfortunately archive.org hasn't archived this website earlier then jan 2 2024, 
so 
I can't see for how long time.

Sorry
Tom



___
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?

[tom ehlert via Freedos-devel]

> I hate to be the one to tell you, but "how Tom navigates a website" is
> not the same as "how many others navigate a website." 

As a matter of fact, Tom navigates the web as any other people:
the way the websites make us use their website leaves usually little choice.

> Today, many more
> people expect to find a "mini 'site navigation' menu" in the footer.
> It's just what they've come to expect; if they can't find a link in
> the main body of the page, they look in the footer for a "mini 'site
> navigation' menu". 

So I went to three major websites: https://arstechnica.com/, 
https://www.washingtonpost.com/
and https://www.nytimes.com/.

All three of them behave similar:

links to other *content* in a navigation bar at the top, 

and another at the bottom for *site related* links like subscribe, unsubscribe, 
contact, ...

and I certainly think that download the sources is a) *content* and b) probably 
deserves a font as 
prominent   as "Play classic games" and "Run applications".

>> now show me a way to locate the command.com sources.
>>
>> or the sources for the DVD driver.


> You're a smart guy and you've been part of FreeDOS for many years.
It shouldn't be a requirement to be a smart guy, and be part of FreeDOS for 
many years to locate freecom sources.
I actually know about the "devel" link for about an hour. And I *often* 
searched for it.

> Click on the "FreeDOS sources" link, and you'll end up at the FreeDOS
> source code archive at . You can find the
> source code there, including command.com ("FreeCOM") and everything
> else. The kernel sources are in there too, but you probably already
> know that.

this is misleading at best.
sooner or later you will accidently click on one subsection where freecom is 
located.
some sort of listing with links to projects would be helpful so the tree would 
be searchable.

Tom



___
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?

[tom ehlert via Freedos-devel]

Hallo Herr Jim Hall via Freedos-devel,

am Mittwoch, 8. Mai 2024 um 15:43 schrieben Sie:

> On Wed, May 8, 2024 at 3:23 AM tom ehlert via Freedos-devel
>  wrote:
>>
>>
>> > On Tue, May 7, 2024, 8:46 PM Green Fog via Freedos-devel <
>> > freedos-devel@lists.sourceforge.net> 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.
>> >>
>>
>>
>> > It's on the website, under the "developer" section.
>>
>> in my version of firefox, there is no "developer" section on www.freedos.org
>>
>>
>> > In the info box where it says:
>>
>> *>>>Create new programs*
>> *>>>FreeDOS includes lots of compilers, assemblers, and other programming
>> > tools so you can create your own DOS programs. You can also modify FreeDOS
>> > itself, because we include the source code under an open source license.*
>> *>>>*
>> *>>>Create programs*
>>
>>
>> > ..click on the link, and you'll find a page with more information and links
>> > to the source code.
>>


> And yet you quoted back to me the text from the "info box" that has
> the link about where to find the "developer" section?

I quoted from your email.


> To make this more clear on the website, I've changed the info box
> title from "Create new programs" to "For developers" - and changed the
> action link in that info box from "Create programs" to "Developers".
> I've also changed the "sitenav" link in the website
Wow. having "sitenav" at the bottom of the page in 5 point font is really 
inventive.

How about having ONE place to navigate the site; maybe near the 
" Read the wiki / Ask a question / Report a bug " location?

now show me a way to locate the command.com sources.

or the sources for the DVD driver.


Tom



___
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?

[tom ehlert via Freedos-devel]

> On Tue, May 7, 2024, 8:46 PM Green Fog via Freedos-devel <
> freedos-devel@lists.sourceforge.net> 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.
>>


> It's on the website, under the "developer" section.

in my version of firefox, there is no "developer" section on www.freedos.org


> In the info box where it says:

*>>>Create new programs*
*>>>FreeDOS includes lots of compilers, assemblers, and other programming
> tools so you can create your own DOS programs. You can also modify FreeDOS
> itself, because we include the source code under an open source license.*
*>>>*
*>>>Create programs*


> ..click on the link, and you'll find a page with more information and links
> to the source code.


> I put this here because usability testing showed that people expected to
> find FreeDOS source code in a place where developers would find other info
> about *developing programs on FreeDOS*.





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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[tom ehlert via Freedos-devel]

Hallo Herr Steve Nickolas via Freedos-devel,

am Dienstag, 30. April 2024 um 17:07 schrieben Sie:

> On Tue, 30 Apr 2024, Bernd Böckmann via Freedos-devel wrote:

>> Sadly not. Only the binaries are released under MIT through the repository.
>>
>>> Does that mean we finally have a genuinely open sourced OMF linker?
>>>
>>> -hpa

> It's my opinion that including them was more of a fortuitous accident than 
> actual intent.  I'd _like_ to try to migrate as much as possible away from 
> them and onto something like OpenWatcom 1.9, but it's proving to be a pain in 
> the neck.  Ideally, I'd like to organize the source a little better too so 
> that there isn't a lot of stuff being compiled and assembled in the INC 
> folder.

> I started bashing on a copy of the tree, and I started to get stuff rolled in 
> Watcom, but mainly ran into trouble over parse(), sysloadmsg() and 
> sysdispmsg(), which are ASM and mostly call into deep, dark, officially 
> undocumented parts of DOS and could probably be replaced, if I could figure 
> out what they were doing in the first place...

> No luck doing the same with the kernel or any of the other ASM stuff. 
> Watcom's MASM emulation isn't 5.1-tier.

I have no idea why I would recompile old MS stuff, but as a hobby it's ok.

JWASM is supposed to be better MASM compatible; at least Japteth changed some 
things as he had 
problems with "WASM not compatible enough".

Tom



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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[tom ehlert via Freedos-devel]

all GITHUB files have LF line endings.
as old MSDOS tools insist on CRLF line endings, you have to convert the files 
first.

Tom



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

Re: [Freedos-devel] libm-0.7 Released!

[tom ehlert via Freedos-devel]

> Surprisingly, I have not received any communication whatsoever regarding 
> libm. 

possibility 1) libm orks exactly as laid out in the documentation.

poosibility 2) nobody cares about libm


btw: do you have a lot of communication about EDLIN?

Tom



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

Re: [Freedos-devel] Tools for building old FreeDOS EMM386?

[tom ehlert via Freedos-devel]

> I wonder if they can be released (at least, binary-only) so people can
> use them on other things?
> Since it is listed in EMMS*.ZIP's makefile, reproducible builds can't
> be built without them.

so what?

Tom



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

Re: [Freedos-devel] Tools for building old FreeDOS EMM386?

[tom ehlert via Freedos-devel]

Hello,

> In freedos/files/dos/emm386/emm/2.2/emms226.zip, its makefile shows it
> need to use sy2pack.exe or sy3pack.exe to pack just-compiled
> emm386.exe.

sy2pack/sy3pack used to be the only compressor that was able to compress 
binaries
that act both as drivers (device=himem.exe) and executable (c:>himem.exe /test)

Bart Oldemann looked at it and disassembled/reengineered it for UPX.


> But where is sy2pack and/or sy3pack? Tried to search in the web finds
> only some posts in FreeDOS ML.

sy2pack/sy3pack is my private invention and can't be found in the wild.

Tom



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

Re: [Freedos-devel] Bochs modified to run SoftICE dual screen

[tom ehlert via Freedos-devel]

Hallo Herr Liam Proven via Freedos-devel,

am Mittwoch, 31. Januar 2024 um 18:23 schrieben Sie:

> This could be useful to several here, I think.

> https://and0uille.net/misc/debug90.html

thanks for the link. 

SoftICE was indeed tremendously useful when debugging the FreeDOS kernel; I 
think 
freedos wouldn't be where it is today without (me and me using) SoftICE.

i still have a (AMD K600) machine with a seondary monochrome (Hercules) adapter 
for this reason.
 
nice find.

Tom



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

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

[tom ehlert via Freedos-devel]

> 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.

it would make this much more interesting if you would describe why this 1960s 
program
does something interesting toda.



> MAD is similar to original FORTRAN,
if wikipedia is right, NOPE.
according to wikipedia, it's 'inspired' by ALGOL60. and that is not even 
remotely close
to FORTRAN.
 
 

>  but there are some things that are just
> weird. So I thought if I had a MAD compiler, I could try writing a few
> simple programs to make sure I understand what is going on.
actually a good idea.

> This seems like something that might have been ported to DOS at some point
> in the 1980s. At least, I thought that might be a good place to look.

> Does anyone know of a MAD compiler for DOS?
according to wikipedia: unlikely.

tom



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

Re: [Freedos-devel] Learning DOS assembly programming

[tom ehlert via Freedos-devel]

>It is also possible to write TSRs and Device Drivers in higher-level languages 
>but it is very cumbersome and you need to do a lot of "tricks" to get things 
>to do what you want without wasting a lot of memory.
I wouldn't call it "tricks". It's "technics". Advanced programming is usually 
not done by newbies.

mKEYB is 98% high langage, but still by far the smallest general keyboard 
driver ever.
FreeDOS kernel is 99% "C" (with a couple of "technics")

with the use of modern tools (including inline assembly) assembly is close to 
"dinosaur fate". 


> For me, the debugger is just as, if not even more, important than the 
> assembler.  

sure. you just ´missed out on SoftICE

what a waste on life hours

Tom



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

Re: [Freedos-devel] Learning DOS assembly programming

[tom ehlert via Freedos-devel]

Hallo Herr Jim Hall via Freedos-devel,

am Dienstag, 26. Dezember 2023 um 17:42 schrieben Sie:

> I actually never learned DOS assembly programming, but decided I'd
> like to start.

> What assembler do you recommend,
for noobies, they are all the same: take NASM.

"hello World" programmers don't need highly optimizing C++ complers nor do they 
have a need for macros.



>  and where is a good place to start
> learning about DOS assembly programming? 
get a book.
read other peoples programs. with a little luck there are even comments in the 
source.
while FreeDOS luckily is almost free from assembler nonsense, there is still 
enough .ASM
to learn from.
read what ASM the C compiler generates from your C programs.


> Start with a "Hello world"
> program and eventually move up to writing an assembly version of TYPE
> and CHOICE, things like that.

get the Ralph Brown interrupt list
implement stuff in C.
learn to single step your programs using DEBUG. 

learning to program (in any language) is mostly about reading and 
understanding, 
not so much about writing programs. 


Tom



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

Re: [Freedos-devel] FreeDOS Source

[tom ehlert via Freedos-devel]

> Is there a FreeDOS walk thru of the source code that you would consider
> helpful to the uninitiated?  
if you mean the *kernel* source, please say so.



> 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?

even as the book is quite old, it's the best (ecause only) gde you wll find.
even as there has been many changes since 1996, the general structure of the 
kernel 
is mostly the same.
you will also need some book(s) with 'DOS programming explained' and 
'undocumented'
in their title to make sense of the kernel source.

Tom



___
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

[tom ehlert via Freedos-devel]

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  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

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

[tom ehlert via Freedos-devel]

sorry,

but my reply related to fdxms, not himem.exe.
and then you have an xms driver for 286

am Donnerstag, 2. November 2023 um 03:28 schrieben Sie:

> 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





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

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

[tom ehlert via Freedos-devel]

> 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

Re: [Freedos-devel] Help Development with djgpp

[tom ehlert via Freedos-devel]

>> I work for embedded software on the board Vortex86DX 800MHz.
>> I need at least SVGA graphic (800X600).

> https://www.vortex86.com/products/Vortex86DX SoC has no built-in VGA, 

https://icop-shop.com/product/vdx-6324rd/  has buildin VGA so there are at 
least some boars available.

it might still be easier to o your project on a Raspberry Pi.

Tom





___
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

[tom ehlert via Freedos-devel]

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:

there is not much sense to develop DOS software ON DOS. Software FOR DOS is 
many times easier crossdeveloped in a windows/linux
environment, and even debugged in a 32 bit Windows console environent or 
"DosBox".

however if you are so devoted to program ON DOS ten you should be ale to 
download and copy the compiler
yourself. you are a programmer!

and there are so many more compilers/interpreters/AWK/SED/ available then 
would ever fir on any medium.

however it might be cool to have the tools necessary to regenerate freedos 
itself as present on te CD.
imo thats  watcom C, NASM and UPX. nothing depends on any dialect of BASIC.

Tom

 



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

Re: [Freedos-devel] Interim Build Delayed

[tom ehlert via Freedos-devel]

t; 
>> https://github.com/atomicobject/heatshrink/blob/7d419e1fa4830d0b919b9b6a91fe2fb786cf3280/LICENSE
>> [3]: https://hg.pushbx.org/ecm/inicomp/file/41860de1db0e/heatshr.asm
>> [4]: > 
>> https://hg.pushbx.org/ecm/ldebug/file/654bf2cbfffb/source/hshrink.asm#l208
>> [5]: > https://hg.pushbx.org/ecm/ldebug/file/654bf2cbfffb/source/mak.sh#l309
>>
>>
>> ___
>> 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





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

Re: [Freedos-devel] ANSI for DOS

[tom ehlert via Freedos-devel]

> Note that I have a different goal to most people. Most people
> want to run DOS-era software. I want to redefine the DOS era
> now that the "rush to market" is long over.

> Any thoughts?

Yes.
Good luck with that.

Tom



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

Re: [Freedos-devel] dir issues

[tom ehlert via Freedos-devel]

Hi Ralf,

am Montag, 24. Juli 2023 um 20:06 schrieben Sie:

> On 7/23/2023 9:35 AM, tom ehlert via Freedos-devel wrote:
>>> ISTM that all the other graphical shells in FreeDOS are even less
>>> useful than GEM, and it would be no loss to remove them... but adding
>>> GEOS would be a win.
>> in what way is GEOS even related to FreeDOS which runs on PC's?
>>
>> unless wikipedia has it completely wrong GEOS needs 6502 (commodore c42, 
>> AppleII etc)
>> computers.
>>
>> Tom
> Well, there is/was a PC version of GEOS, which for a while now is Open Source 
> and available as PC/GEOS (to differentiate it from THAT GEOS you were 
> thinking of) at

> https://github.com/bluewaysw/pcgeos

I forgot about PC-GEOS, or simply didn't connect it to GEOS.

Yes, PC-GEOS is probably the best public domain GUI (on DOS or anything else),
probbly much better then anything the FreeDOS distribution provides 
(without testing any of the others beside GEM).

so I agree with 
>>> useful than GEM, and it would be no loss to remove them... but adding
>>> GEOS would be a win.

there is nothing wrong with a website pointing to many different alternatives 
for anything,
but a distribution should make decisions.


Tom



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

Re: [Freedos-devel] dir issues

[tom ehlert via Freedos-devel]

> ISTM that all the other graphical shells in FreeDOS are even less
> useful than GEM, and it would be no loss to remove them... but adding
> GEOS would be a win.

in what way is GEOS even related to FreeDOS which runs on PC's?

unless wikipedia has it completely wrong GEOS needs 6502 (commodore c42, 
AppleII etc)
computers.

Tom



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

Re: [Freedos-devel] format /s

[tom ehlert]

> So in short, DOS is not great for real-time stuff, 
+1

> but it certainly is not as bad as Windows :-p

Windows is actually quite good for realtime stuff (even hard realtime stuff) -
if you write your time critical stuff as a device driver.

there are a lot of provisions, directives, howto's etc. to make realtime 
applications 
possible - if they have a driver part.

Unfortunately there is no Visual Bsic for realtime noobies.

Tom




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

Re: [Freedos-devel] format \s

[tom ehlert]

Hallo Herr Harald Arnesen,

am Freitag, 23. Juni 2023 um 21:29 schrieben Sie:

> Patrick McCavery [23/06/2023 18.13]:

>> If I could run format \s right from Linux, I could use all of my
>> existing toolchain and I would not have to run this command on a USB key
>> from within qemu.
>> > Could this be done?

> Get a copy of the bootsector from a DOS disk, store it somewhere on your 
> Linux machine, format your disk from Linux, dd the bootsector to the disk.

Nope.
not 'a DOS disk', it must be a FreeDOS disk.

and then again, nope.

the bootsector contains some (~50 byte) disk specific data like disk size, 
cluster size ...
and then some MSDOS/FreeDOS code to load kernel.sys into memory.

Tom



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

Re: [Freedos-devel] useful HTMLHELP bug findings and proposals

[tom ehlert]

Dear Vacek,

> If it wasn’t on the to-do list earlier, I'd kindly request a mapping of
> codepage 3845. Please map code point 0x9F, the Ft sign temporarily to
> U+FFFD and add a comment to the definition file along the comments of
> "addition of the forint sign into Unicode pending".

> This would make it easier for the UTC to realize that addition of the
> forint sign is needed for a contemporary operating system.

Do I understand you correctly: you want us to somehow implement Ft so that 
you can go to the UTC and claim that "a contemporary operating system" uses it?
just because your gouvernement dreamed when unicode was designed?

Tom






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

Re: [Freedos-devel] EXIST NUL

[tom ehlert]

Hallo Herr Ralf Quint,

am Montag, 5. Juni 2023 um 23:06 schrieben Sie:

> On 6/5/2023 1:56 AM, jer...@shidel.net wrote:
>>
>> Hi All,
>>
>> /There are two separate issues when using: |IF EXIST ?:\NUL| /
>>
>> /I'm lazy and wrote up a info text file over at > 
>> https://fd.lod.bz/redist/testing/devNUL/ and /
>>
>> /bug //report at //https://github.com/FDOS/freecom //that I will just > 
>> copy/paste here. /
>>
>> /Additional testing would be required to determine the cause of these > 
>> problems. Since /
>>
>> /the same problem exists for Issue #1 under MS-DOS, an argument could > be 
>> made to /
>>
>> /not fix that problem./
>>
> I am not sure why you would think this is a bug at all. 

because it differs from MSDOS.

> I am pretty sure that this test will not only fail for CD-ROM drives, but for 
> mapped network drives as well, as MSCDEX is nothing but a version of the 
> network redirector.

if exist D:\NUL

works for fixed and RAM disks in MSDOS.

this even worked in FreeDOS until it was broken in ~2003 n by PerditionC by 
some change in truename().

Tom



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

Re: [Freedos-devel] I want my 10K

[tom ehlert]

> This could look something like this. The system boots as normal. A CONFIG 
> option like ‘DOSMOVE=UMB’ could exist.
there exists already the DOS=UMB option, meaning "move as much as possible to 
UMB".

IIRC when Bart implemented this he only moved DATA (buffers, LASTDRIVE=, 
current directories, ...) to UMB (the easy stuff),
that's the 9K uppermemory that you see.

while it may be possible to move more up, it's a lot of non trivial work with 
fairly low payoff.

 

>  The first device driver could check for that setting and would verify the 
> kernel could still be relocated. If it can, it would relocate or reload that 
> portion of the kernel to an UMB. 

the first drivers are NUL, COM1, LPT, FAT, etc.
loaded way before JEMM


> A memory manager is probably the best choice to perform the relocation. 
a memory manager provides the UMB to move to, but has no information at all 
what stuff mujst be relocated.


> It is generally loaded before any other drivers. Since JEMM is the default 
> memory driver in FreeDOS, I suggest it would be the best choice to perform 
> the relocation when possible. 

currently after each DEVICE=XYZ executed the kernel searches for high memory 
and UMB. if found it relocates 
as much stuff to :0 and E000:0.

however locating every far pointer to devices, the ListOfLists and a couple of 
other (linked) lists in the kernel
would be a major - error prone - undertaking. forget just one location, and you 
have a broken kernel, because nobody will care to debug the kernel - again.

> JEMM already pulls of quite a few tricks with memory. For example, my i686 
> loads JEMM. Yet, it does not use any conventional or upper memory on that 
> machine. It doesn’t even show up with MEM. 

right. JEMM does impressive stuff :)


> Although it would be a lot of work and probably never happen, it is not an 
> impossible task.

that's a statement I could sign ;)

Tom



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

Re: [Freedos-devel] Logger v0.1 (beta)

[tom ehlert]

Hi Jerome,

if you make it a logger.exe (rather tehn .com), UPX should be able to compress 
dual mode programs.

Tom



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

Re: [Freedos-devel] Extension proposal

[tom ehlert]

Hi ecm,


> [1]: 
> https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267

this got me looking into this 'too slow' detection method.
and it is indeed slow. as in molasse. let me explain.


a) isn't

  %%Comparing:
inc di
lodsb
cmp al, [es:di]
jne %%Next
loop%%Comparing

more or less the definition of

repe cmpsw

??


b) decompiling the actual code, it's basically


  for (seg = 10; seg < 0xa000; seg++)
{
if (fmemcmp(MK_FP(seg, 9), "LOGGER", DriverLength))
{
return found_our_driver_at(seg);
}
}
   return failure;

that's indeed slow as it compares all memory up to 0xa000 to lookup the driver,
or up to the drivers address (which is much better most of the time.

when I mentioned microseconds, I had the DOS memory chain in mind where you 
would have 
to compare 20-50 locations to your drivers name.









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

Re: [Freedos-devel] Extension proposal

[tom ehlert]

Hi,


> At present, the interface program for Logger just performs a slightly 
> optimized brute force search for the Logger device driver. Although reliable, 
> it is very slow compared to providing a simple interrupt call to test for 
> installation.

given that this detection will be done once per program start: how many 
microseconds do you expect to save?

>  Looking at the different interrupts, I think I have come up with a solution 
> that will work well for Logger and any other driver or program that needs 
> such a check. So, I’d like to propose a “standard” we could use. I’d like to 
> get your feedback on what I’m thinking…

setting a "standard" which is used probably exactly once ? we write year 2023 ;)

https://xkcd.com/927/

INT 2D has been mentioned by others



> Looking at RBIL, interrupt 0x2b is barely used by anything. Under MS-DOS and 
> FreeDOS, this simply points to an IRET. Under IBM ROM-DOS, AH functions 
> 0x00-0x03 do some things. But, all other calls do nothing. 

>  https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html 
> 

> An install check issuing this interrupt would be simple to perform. A program 
> could set the Carry Flag, load AH/AX with “check for install” function and 
> set DS:BX to point to an identifier string (minimum 8 characters, no 
> maximum). Then call the interrupt. On return, if the Carry Flag is still set, 
> then the install check failed. If the Carry Flag is clear, it succeeded and 
> other register would be modified to according to the needs of the programs. 

> Implementation for Logger (as an example) could be:

> 
> CHECK:
> push cs
> pop  ds ; set DS to our code segment
> stc ; set the carry flag
> mov  ax, 0xfd00 ; set AX to install check function
> mov  bx, LOGGER_ID  ; offset to LOGGER device driver ID
> int  0x2b   ; call install check interrupt
> jc   NOT_INSTALLED  ; nothing changed, driver is not 
> loaded

   ;you should add 
  cmp ax, MAGIC_VALUE
  jne   NOT_INSTALLED

your proposed INT2B might be used by some other software that for some crazy 
reasons 
clears the carry flag.

anyway, INT2D is probably the better choice anyway.



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

Re: [Freedos-devel] Bug 0x5801/41

[tom ehlert]

Hi,

> Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 
> (5.83) or My Head.

it's in the Kernel - or in your head.

to decide between these two alternatives it's always helpful to send your 
actual sources - not
an english description of what you had intended to do.
and of course autoexec.bat/config.sys


and - well I understand that kernel version control is a complete
mess - but Kernel 0.85a seems a bit unlikely given that
https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to
0.42.



Tom




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

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker be nchmark

[tom ehlert]

Dear Bret,

> The article is found at
>> https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison

> I mostly agree with you and your article, but:

fine that you agree,  but at most 50% of the article is even close to
'right'.



>>> Conclusion
>>>
>>> CPU-bound benchmarks are much faster on a modern machine than they
>>> are on older ones.
>>> The frequency increase does not actually suffice to explain the
>>> speedup.
>>> Some things, like doing I/O, were not sped up nearly as much
>>> however.

> I tried posting a much longer response to this, but it was
> apparently rejected by the moderators.  Here's a shorter one.

>> I/O has also vastly speedup (we have SSD speeds of up to 6 GB/sec).
>> Just not by doing IN/OUT, but by using memory mapped PCI devices.

> I think you're confusing two different things -- MMIO and DMA/Bus-Mastering.

He is NOT.

> Whether I/O is PMIO or MMIO is pretty much irrelevant to the speed.
> For example, I/O port 201h (the analog joystick) and I/O port 92h
> (which controls A20 on some computers) are both VERY slow and would
> not be any faster if they were MMIO instead of PMIO.

this is plain bullshit.

> The speed depends on the I/O device, not the type of I/O mapping.
which is nonsense.

>  Plus, I/O
> _can't_ be cached, whether PMIO or MMIO, so the cache(s) are irrelevant to 
> I/O.

yes. I/O device data can't be cached. you are such a clever person to
discover this fact. WOW.


> SSD speeds are fast because they use bus-mastering, not because
> they use MMIO.  The I/O ports are used to "control" the device, but
> the data from the SSD is transferred in and out of RAM using
> bus-mastering (which is fast because it doesn't use the CPU at all).

I understand that you don't have the faintest clue how modern PCI devices
work. Just go ahead with undertaining us ...


Tom



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

Re: [Freedos-devel] I wish I had a boot.log file

[tom ehlert]

> For
> instance, vecho (which displays many user messages, like “Welcome to
> FreeDOS”) don’t output text the same way as other programs and do not get 
> captured at present.

I don't know how and why vecho displays text different. However it
could "display" the text twice: once in the complicated way, and once
in a "do nothing" way intercepted by your logger.


> There is a lot of other stuff that I’d like to get done with Logger
> for the T2304 Interim Build. But, those are not critical functionality.

cool would be a single logger.exe, useful both as

  device=logger.exe

and
  c:>logger.exe
later

Tom



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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Dear Mike,

I almost always agree with; not so in this case.

it's not only the (performance per core) x (number of cores).

the i5 is also far more capable then a K6-2 in single threaded/core mode - as 
it would
be in any xxDOS setting.

Tom





am Donnerstag, 23. März 2023 um 20:42 schrieben Sie:

> Your measurement methodology needs help?


> The i5 is capable of far more work than the K6-2-350.  What you are
> doing is comparing a bus to a passenger car and stating that they
> both are effective at carrying one person, and therefore the bus has no 
> additional value.


> When running a simple single-threaded workload sure, the i5 might
> not look like it's worth the extra silicon.  Now go run 8 or 16 or
> 32 copies of the same workload in parallel, and tell me how that
> goes for the K6-2.  Modern chips are designed for very different
> things than chips from 20+ years ago, so the comparison is kind of 
> meaningless.


> You're effectively measuring the clock speed, not what the chip is
> capable of.  And this isn't a surprise, but a 10x faster clock on a
> single threaded benchmark results in 10x performance.  While
> completely ignoring the rest of the chip.    We don't benchmark buses against 
> passenger cars.




> On Thu, Mar 23, 2023 at 12:33 PM Bret Johnson  wrote:

>>> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5?  And
 >>> again, I know it doesn't make any sense, but it's still true.
 >>>
 >>> As far as I can tell, the Emperor has no Clothes.
 >>
 >> I'm confused by this.  You are claiming that a 350 Mhz K6-2 is "WAY" faster 
 >> than a 3.3 GHz i5?  In what respect?

>  My K6-2-350 runs about 15 times faster than a 33 MHz 386, while my
> 3.3 GHz i5 runs only about 10 times faster, in both cases with the
> caches enabled.  What do you not understand?

>  You can try to claim that the SLOWDOWN test I performed is somehow
> "tainted" or "unrealistic" or "unfair" or "sub-optimal" or something
> like that, but the results are very real and are simply what they
> are.  Also, as already stated, the purpose of SLOWDOWN is not to be
> a benchmark but you can indirectly use it as a benchmark.


>  ___
>  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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hallo Herr Bret Johnson,

am Donnerstag, 23. März 2023 um 20:31 schrieben Sie:

>>> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5?  And
>>> again, I know it doesn't make any sense, but it's still true.
>>>
>>> As far as I can tell, the Emperor has no Clothes.
>>
>> I'm confused by this.  You are claiming that a 350 Mhz K6-2 is "WAY" faster 
>> than a 3.3 GHz i5?  In what respect?

> My K6-2-350 runs about 15 times faster than a 33 MHz 386,

when executing your SLOWDOWN wasteloop

> while my 3.3 GHz i5 runs only about 10 times faster

when executing your SLOWDOWN wasteloop

> in both cases with the caches enabled.

of course. otherwise high clockspeed doesn't make any sense. at all.


> What do you not understand?
why you insist that your SLOWDOWN units are the only way (and a valid
way) to measure CPU performance.

a different way to measure the CPU performance would be to

compare the time to ZIP some big file with highest compression level
(which is mostly CPU limited) between your two mschines.

SORT  NUL

FIND "bsdhdfhd"  BIGFILE.TXT

compile something from RAM disk (to exclude disk performance)

many more possibilities.


I'm 100% certain that the i5 will do WAY better then the K6-2.

> You can try to claim that the SLOWDOWN test I performed is somehow
> "tainted" or "unrealistic" or "unfair" or "sub-optimal" or something
> like that, but the results are very real and are simply what they
> are.
no one accuses you of cheating/lying/whatever.
just your SLOWDOWN's wasteloop isn't representative for CPU performance.

>  Also, as already stated, the purpose of SLOWDOWN is not to be
> a benchmark but you can indirectly use it as a benchmark.

'benchmarks' are difficult enough. almost everybody knows this.
'indirect benchmarks' should go immediately to the trash (or to recycling 
center to
recycle precious bits).

Tom



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

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker benchmark

[tom ehlert]

Hi,

am Dienstag, 21. März 2023 um 23:26 schrieben Sie:

> Hello!

The article is found at
> https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison

I mostly agree with you and your article, but:


>Conclusion

>CPU-bound benchmarks are much faster on a modern machine than they are on 
>older ones.
>The frequency increase does not actually suffice to explain the speedup.
>Some things, like doing I/O, were not sped up nearly as much however.


I/O has also vastly speedup (we have SSD speeds of up to 6 GB/sec). Just not by 
doing IN/OUT, but by using
memory mapped PCI devices.

Tom




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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hallo Herr Rugxulo,

am Montag, 20. März 2023 um 23:20 schrieben Sie:

> Hi again,

> On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson  wrote:
>>
>> This is something much more serious than a "tradeoff" or a
>> "regression".  My new i5 CPU appears to be spending _at least_ 99%
>>  of its resources NOT processing OpCodes and NOT accessing the
>>  cache (because there isn't one).  And the problem is blamed on
>> "sub-optimal code".  I don't know what the CPU is doing with all
>> those resources it has, but I do know what it's NOT doing.  I do know
>> that what's going on inside a CPU is very complicated.  Call me naive,
>> but I always thought the primary purpose of a CPU was to process
>> OpCodes.  Silly me.
>>
>> >>  I think it probably
>> >> would be -- I certainly think it would be WAY faster than my 3.3 GHz
>> >> i5.
>>
>> > nope.
>>
>> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5?
>> And again, I know it doesn't make any sense, but it's still true.

> Self-modifying code??

no, it's not Self-modifying code.


Tom



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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hallo Herr Bret Johnson,

am Donnerstag, 9. März 2023 um 23:27 schrieben Sie:



> The computer I'm currently using is a few years old, old enough
> that I can boot DOS on the actual hardware.  The CPU is an Intel i5-4590 
> running at 3.30 GHz.

> I have a DOS program I wrote a long time ago, called SLOWDOWN (and
> hope to find time to "update" it in the future).  The purpose of
> SLOWDOWN is to slow the computer down so that DOS applications don't
> "blow up" because the computer is too fast.  It's not a perfect
> solution, but is useful in certain situations.

> One of the things SLOWDOWN needs to do is figure out how fast the
> computer is running so that it can slow it down the correct amount
> when you want to do that.  So, SLOWDOWN can sort of be used as a
> "benchmark" to see how fast your computer actually is.

> For my test, I compared how fast my current computer runs (with a
> 3.30 GHz clock speed) against a 33 MHz 386 CPU (which I measured way
> back when -- I don't have access to that computer any more).  At
> least in theory, because my current clock speed is 100 times as fast
> as the 386, my current computer should run _at least_ 100 times as
> fast as the 386 did.  Also, at least in theory, it should be even
> faster than that since the new computer has a cache and the 386
> didn't, modern CPU's take fewer clock cycles per CPU instruction, etc.

> In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the
> 33 MHz 386 did, not more than 100 times like you would expect.

this doesn't make sense AT ALL.
even in your own source,

DB   'º Generic º AMD ³ AM386DX ³   33 ³   334 
º',CR,LF
DB   'º Unknown º Intel   ³ Pentium-3   ³  650 ³  4611 
º',CR,LF
DB   'º Generic º AMD ³ K6-2³  350 ³  4780 
º',CR,LF

you document that an AMD k6-2 350 MHz is 15 times faster then a 33 MHz
386 CPU. And we all KNOW that an Intel i5-4590 running at 3.30 GHz is
faster then AMD K6-2.

for those who want to search themself, search the source for
'WasteLoop'.

it all boils down to some garbage (does nothing sensible) code,
including

  MOV  CX,2   ;Do two bits
  REPE CMPSB  ;Compare the string to itself
  ADD  AL,220 ;Give AL a number
  ADD  AX,3456;Give AX a number
  MOV  BX,DummyVar;BX=address of DummyVar
  MOV  DummyVar,AX;Store it in DummyVar
  SUB  AX,ES:DummyVar ;AX=0
  XLATB   ;AL=[BX+(unsigned)AL]
  SAL  BX,CL  ;Multiply BX by 2, CL times
  MOV  CL,3   ;Divide by 3
  SAR  DummyVar,CL;Signed divide DummyVar by 2, 3 times
  SBB  AX,8   ;Subtract with borrow
  AAM ;ASCII adjust after multiply (AL/10:AH=Quo,AL=Rem)
  DAS ;Decimal adjust after subtraction
  MOV  DX,21h ;Do an
  IN   AL,DX  ;  IN
  POP  CX ;Restore the loop counter
  DEC  CX ;Decrement it
  JZ   WasteExit  ;If it's 0, we're done
  JUMP WasteLoop  ;If it's not, do it all again

looks innocent enough. the problem child is
  IN   AL,DX  ;  IN

and the fact that the 'IN'-bus doesn't run significant faster then it
did in 386's days (there is a reason modern disks are accessed with
(U)DMA, not IN). the speed depends on the chipset and the actual port
address, but is more like 10 MHz then 3 GHz.


> I then ran a second test where I disabled the cache on the CPU (you
> can do this with my CPUCACHE program which is included with
> SLOWDOWN).  This is a more "apples-to-apples" comparison of the
> _actual_ CPU speed than the original test with the cache enabled.

it's not. almost EVERYBODY knows that GHz CPU's just don't make sense
without cache, because it is always waiting for the next instruction
coming from memory. and memory access times are basically unchanged for
the last 30 years at 60-100 ns. so a modern CPU without cache spends
all the time waiting for CPU instructions coming from memory.

> When I did this test, the computer ran almost exactly the same speed
> as the 33 MHz 386 (it was about 3% faster, not 10,000% faster as
> "logic" would dictate).
the is exactly no "logic" in your argument.

> There is something VERY wrong going on
> here.  I suspect you may not believe my results, but they are nonetheless 
> real.







> Let me ask you a few questions.  One of the things I said was that
> the main reason modern CPU's seem so fast is because of "tricks"
> like pipelining and caching,
and read ahead caching, write back buffering, and more

> and you seem to indicate that you don't
> think that is true.
no. that's true.


> Would you even _consider_ running a modern OS
> on a CPU with the cache disabled, when the actual, verifiable data
> shows it would run about the same speed as in the 386 days?
I'm not stupid.

> The next set of questions relate again to what I mentioned
> previously.  What if modern CPU's 

Re: [Freedos-devel] Booting and FDAPM

[tom ehlert]

> IDLEHALT=1 works for my machines and reduces the CPU load under
> VirtualBox to nearly zero at the command prompt.

:-)))


  FDAPM whatever

should be REMified.

OTOH this seems to be a problem between FDAPM,
VirtualBOX and Watcom Installer. Whoever wants to develop ON FreeDOS
...



>> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net:
>> 
>> On a side note… Why run the watcom installer at all? Installing the FreeDOS 
>> WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded 
>> takes about 1 minute inside VirtualBox. We could most likely just provide a 
>> WATCOM2C package and avoid the whole issue completely. 
+1

> If v2 is packaged would it be possible to continue shipping the 1.9
> branch in parallel?

NO.

Anyone who hasn't installed watcom so far won't be able to answer this
question.

and anyone able to answer this question will be able to download the
other version.

and, of course, developing ON FreeDOS is self flaggelation ...



> My impression is that the v2 fork focusses on
> adding new stuff: Linux support, 64-bit and so forth… And from time
> to time they seem to break older stuff. I at least under Win9x encountered 
> some regressions.

in that case: WHAT REGRESSIONS?


Tom



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

Re: [Freedos-devel] Booting and FDAPM

[tom ehlert]

Hallo Herr Bernd Boeckmann via Freedos-devel,

am Freitag, 17. März 2023 um 12:52 schrieben Sie:


>> Any thoughts?

> I have some additional data:

> 1) Pentium MMX 166,  T2303 default installation:

> Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes.
> After FDAPM OFF:  4:30 Minuten.

> 2) VirtualBox, activated APM: aborted after 2 minutes @ 10%

> 3) VirtualBox with LH FDAPM ADV:REG same as 2)

> 4) VirtualBox FDAPM deactivated: installation time 4 seconds :-)

> BUT!

> Disabling FDAPM under VirtualBox significantly increases the CPU
> load on the host system! It essentially maxes out one CPU core.

could you test also

CONFIG.SYS:

IDLEHALT 1


which might be still fast, but saves most of the energy.
Tom



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

Re: [Freedos-devel] FDISK: how to handle sector size != 512?

[tom ehlert]

Hi,

> while hacking on FDISK and having some thoughts about different
> sector sizes I stumbled upon the problem that the extended INT13
> function 48 may return a sector size != 512 while the INT13,0X
> functions always seem to operate on „virtual“ 512 sector sizes.

all INT13 functions operate (for a given hard disk) on the same sector
size as reported by INT13.48

> Unsure how to handle this case I tried to find some hints in the
> FreeDOS Kernel source. In INITDSK.C the sector size returned by
> INT13,48 is simply ignored and only the total sector count is used
> to determine the size of the disk.

the kernel *should* work with sector sizes != 512 (as MSDOS reportedly
does), but it simply doesn't. I Think PerditionC tried to make this
work, and was successful for 256, 512, 1024 and 2048. unfortunately he
didn't succeed for 4096 (I don't know the reason) so the FreeDOS
kernel is stuck at 512 byte. no need to support anything else (in the
context of freedos).


> This may be because in reality it
> is a non-existent problem (values other than 512 are not encountered
> „in the wild“).

there *are* 4096 byte sector disk out in the wild:
(a) 4kn  (4knative) disk export their 4k sector size to the OS and don't
emulate 512 byte sectors.

(b) some external USB disks export 4K sector size even when the
internal disk has 512 byte sectors. I think they do this to be able
to have 16 TB external disks, even with MBR partitioning.



> There is also a MAX_SEC_SIZE 512 definition leading
> me to the conclusion that sector sizes of > 512 are not supported at all?
right.

> My initial idea for how to handle this in FDISK until a better
> solution is found was to sort of work-around it by reverting to CHS
> functions - with all the drawbacks this has - if the sector size
> returned by INT13,48 is not 512. Then at least the first ~8GB could be 
> supported.

there is no point in this; CHS addresses the exact same sectors as
LBA.


> But I would be glad if someone with more knowledge in that area
> could point me in the right direction, especially under the assumption of 
> staying compatible.

I hope I could help.

Tom



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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Dear Bret ,

am Donnerstag, 9. März 2023 um 23:27 schrieben Sie:

>>> My terminology is compliant with that definition.
>>
>> *Sigh*
>>
>> I am aware of that. The general term "re-entrancy" is not synonymous
>> with the specific term "reentrant kernel".

> So re-entrancy is not synonymous with re-entrancy?  Or the
> definition of re-entrancy when applied to a kernel is different than
> the definition when it is applied to something else?  Or the
> definition you supplied doesn't apply to kernels?

This isn't going anywhere.

We should stop this thread, until you can provide an example of your
revolutionatry concept of 'Bring Your Own Memory' (which mere mortals
have difficulty to grasp).

Tom



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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

>> A Virtual Machine for the rest of us is something like VMWare, Qemu,
>> VirtualBox, etc. - something that simulates a real machine.  You
>> load a real operating system in it and the operating system
>> generally doesn't know or care that it's actually in a simulation.

> So "the rest of us" is _everybody_ but me?

Exactly.

> And you consider BIOS
> software that never existed in a real machine to be part of a
> "simulated real machine" but DOS software that never existed in a
> real machine to be something different?

I have no idea what you are trying to tell.

> Would you consider
> something like PTS-DOS (which in some ways is less compatible with
> MS-DOS than is DOSBox) a real DOS?

definitively. this is not about the number of bugs present, but about
the way this thing works.

...

>> I wouldn't even think to try to look for the InDOS flag on something
>> like DOSBox.

> Why would you _expect_ it to not be there?

I would expect it to be there (you don't write how you determine that
it does not exist. in the end it's a pointer), but I would expect it
to point to a location that is constant 0, as (at least potentially)
DosBOX could be completely reentrant, and never 'InDOS'.


Tom



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

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[tom ehlert]

> That depends.

whatever 'depends'.

> Besides poorly optimized system caches, is the
> installer doing things that blow the cache and increase the miss rate?

whatever the installer is doing: unless you find a valid 'this is
doing something in a stupid way' point this installer is as much a
valid benchmark point as any other. Possibly not the most relevant,
but still...


>  You noted a significantly increased download zip.  Is everything
> actually necessary?  Did you download a debug build that will have
> additional binary code or is the download zip an optimized build?

in what way this is related to 'FreeDOS install speed is slow' escapes
me.

Tom



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

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[tom ehlert]

> Over a month ago, I opened an issue on the FreeDOS project on
> GitLab about the Open Watcom v2 installer being extremely slow in
> FreeDOS. It takes an hour or more on FreeDOS, while the same
> installation completes on MS-DOS 7.1 within just a few minutes.

either you report your config.sys and autoexec.bat for both tests
or your report is basically useless.

write caching smartdrv (which freedos is known not to have) makes a
HUGE difference for installers, so you are comparing apples to oranges.

of course running both without autoexec/config.sys would place them on
an equal playing field.


Tom



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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

> The SDA of MS seems fairly well documented in RBIL, but I'd be
> pretty surprised if all DOS clones (particularly Virtual Machines
> like DOSBox) are compliant so it may not be a good idea to pursue. 
> I suspect FreeDOS would be pretty close to compliant, but I'm not even sure 
> about that.

After thinking a bit about this, I'm fairly certain that FreeDOS is
NOT (sufficiantly) SDA compliant.

Even assuming that all static state of the FreeDOS kernel is contained
in the SDA, there is more 'state' in a DOS machine then that. at least
5 problem cases come to mind:

(1) DOS_MEM_ALLOC()

is basically

   a) segment = find_first_free_segment(size_wanted)

   b) mark_segment_as_used(segment)
  build_mcb_chain(segment, size_wanted)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_MEM_ALLOC, both the TSR and the old instance
will get the same segment and treat it as their own to use. BAD things
will happen...



(2) DOS_FILE_OPEN(filename)
is basically

   a) file_number = find_first_closed_file()

   b) mark_file_as_used(file_number)
  initialize_file_table(file_number, filename, ...)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_FILE_OPEN, both the TSR and the old instance
will get the same filenumber and treat it as their own to use. BAD things
will happen...

(3,4) DOS_FILE_WRITE()
   the problem is with the internal (and /or some external) cache.

   basically

   a) buffer = locate_LRU_buffer()

   b) clean_buffer_if_dirty(buffer)
  init_buffer(buffer, sectornumber)

now if the normal processing gets interrupted between a) and b) by a
TSR, and the TSR also calls DOS_FILE_WRITE, both the TSR and the old instance
will use the same buffer for differenrt sectors. usually not a good
idea.


(5) INT_13_WRITE_SECTOR(LBA, buffer, count)

basically

  a)disk_controller_position(LBA)
disk_controller_initiate_write()
disk_controller_send_data(buffer,count)
disk_controller_wait_while_busy()
return disk_controller_status == STATUS_OK
  b)

  if the TSR interrupts anywhere and calls INT_13_WRITE (or
  INT_13_READ) between a) and b) data will be lost.


some of the problems above might be handled by placing CLI/STI at
proper locations. some are more difficult.

but I'm pretty certain that FreeDOS hasn't a lot of CLI/STI's
sprinkled at clever positions.


I have absolutely no idea how this situation is for MSDOS and DRDOS.
as MS 'invented' the SDA, they might have put some (and probably
more) into the proper places. at least I would think so.

Tom






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

Re: [Freedos-devel] 386MAX

[tom ehlert]

Hallo Herr Bret Johnson,

am Montag, 6. März 2023 um 19:43 schrieben Sie:

>>> 386MAX supports the Global EMM Import Specification (GEMMIS), which
>>> allows Windows 3.x to start in 386 Enhanced mode, even when the EMM
>>> manager is loaded. (The documentation in the 386MAX source code
>>> seems to refer to it as the "Global Paging Import Spec".)386MAX
>>> supports the same I/O port trapping API through INT 2fh that EMM386
>>> provides. This (at least in theory) should make it compatible with
>>> certain emulation TSRs such as SoftMPU and VSB, which currently
>>> don't support JEMM, and would require separate non-trivial ports
>>> to work with JEMM's JLOAD feature.
>>
>> so there would be indeed some point to have 386MAX running.
>> unfortunately  it seems not not work on current real hardware.
>>
>> not sure if it's worth the trouble to debug this.

> Or just take some of the important stuff that Bob Smith and
> Qualitas discovered about Windows/GEMMIS/EMM386 and import it into
> something like JEMM.  There's some knowledge embedded in 386MAX
> about what MS did that you will never directly get out of MS. 

as Jerome said:

"But, that probably won’t happen. A volunteer to work on resolving
the issues that need fixing with 386MAX is unlikely to happen anytime soon. If 
ever.

:-) "


same for extraction of old wisdom and insertion into EMM386

Tom



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

Re: [Freedos-devel] 386MAX

[tom ehlert]

Hallo Herr tom ehlert,

am Montag, 6. März 2023 um 10:14 schrieben Sie:

> Hallo Herr jer...@shidel.net,


>> Any volunteers?

> to start first: what would be the point to have 386MAX in freedos
> distribution (after 20 years without it)?

> I know that it was somewhat important in the middle ages, but now?

answering my own question,

Volkert via Freedos-devel, am Samstag, 2. Juli 2022 um 00:02 schrieben Sie:

> Hello FreeDOS developer community!


> Bob Smith of Sudley Place Software has released the source code of
> 386MAX and related tools under the GPLv3 license!



> He'd like this news to be passed on to whomever would be interested
> in this source code, but he does add that the project has little to
> no documentation available. See his comment at
> https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414


> The reason why this is of particular importance to the FreeDOS
> project, is because it provides the following two features that JEMM currenty 
> lacks:


> 386MAX supports the Global EMM Import Specification (GEMMIS), which
> allows Windows 3.x to start in 386 Enhanced mode, even when the EMM
> manager is loaded. (The documentation in the 386MAX source code
> seems to refer to it as the "Global Paging Import Spec".)386MAX
> supports the same I/O port trapping API through INT 2fh that EMM386
> provides. This (at least in theory) should make it compatible with
> certain emulation TSRs such as SoftMPU and VSB, which currently
> don't support JEMM, and would require separate non-trivial ports to work with 
> JEMM's JLOAD feature.

so there would be indeed some point to have 386MAX running.
unfortunately  it seems not not work on current real hardware.

not sure if it's worth the trouble to debug this.

Tom










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

Re: [Freedos-devel] 386MAX

[tom ehlert]

Hallo Herr jer...@shidel.net,

am Sonntag, 5. März 2023 um 22:43 schrieben Sie:

> Hi all, 

> I spent a few minutes looking at 386MAX. 

> Unfortunately, it is going to take at least a some work by someone
> (not me) before it could even be considered for inclusion.

> First, it cannot even be run at present. The precompiled
> executables and even diskette versions are present along with the
> sources. However, the executables must be installed by it’s setup
> program which writes an user/serial number into the executables.
> Those executables will not run without that being done. The setup
> program (and source) are present as well. However apparently, serial
> numbers are not pre-generated and were created when producing the
> media. So, that is all the further I got during testing. 

> Someone who has access to old MS C and Assemblers laying around
> will need to work on this to get it functional. Thankfully, it looks
> like there are numerous batch files to automate the building
> process.  It is a large codebase and porting it to open source
> compilers would take someone a very long time. Again, neither will be done be 
> me.

> As far as I could tell in my limited testing, the following would need done…

> 1) Update Company/License/Copyright information to reflect the
> project was released to the public under GNUv3 by the author. 
> 2) Remove or at least disable the user/serial number stuff in the executables.
> 3) Possibly, forego the requirement of using the setup program. 

> Since 386 is large, complicated and can be used under DOS with or
> without windows, it may be best that if we ever include a package
> for it, that the package binaries include the installer. This would
> permit installing the program and having it perform all the required
> steps based on the end users system.

> Any volunteers?

to start first: what would be the point to have 386MAX in freedos
distribution (after 20 years without it)?

I know that it was somewhat important in the middle ages, but now?


Tom




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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hallo Herr Bret Johnson,

am Freitag, 3. März 2023 um 23:40 schrieben Sie:

>>> But I was still wondering if anybody has seen it done before since
>>> I don't think I've ever seen an actual implementation.
>>
>> neither did I.

> Probably not worth pursuing.  But even just the idea of a
> re-entrant Operating System (rather than just a re-entrant
> sub-function) is a pretty interesting concept.

> Even modern OS's don't do anything like that.

duh? have you ANY idea what you are talking about? just a tiny bit?

Tom




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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hi,

> I'm wondering if anybody has any experience, or has seen any source
> code, related to manipulating the DOS Swappable Data Area (SDA) to
> make DOS re-entrant.  I working on at least one TSR program right
> now where I think something like that might be useful but I've never seen it 
> done before.

I think it was sort of documented in "Undocumented DOS 2nd edition",
AFAIR even with some (demo) code.

I needed something like that in ~1992, and spend quite some time to
get it running. In the end, I got it mostly running, but not really
stable in a sense that it worked pretty well unless I ran some
testprograms in the foreground intended to stress this interface.

It probably can be made to work, but I failed to do that, and finally
gave up and used other ways with the same effect (for my TSR's
purpose).


> The SDA of MS seems fairly well documented in RBIL, but I'd be
> pretty surprised if all DOS clones (particularly Virtual Machines
> like DOSBox) are compliant so it may not be a good idea to pursue.

probably right.

> I suspect FreeDOS would be pretty close to compliant, but I'm not even sure 
> about that.

I would be absolutely surprised as it never came up as a thing to do,
and would be 100% untested as nobody uses the SDA to multitask the
last 20 years.


> But I was still wondering if anybody has seen it done before since
> I don't think I've ever seen an actual implementation.

neither did I.

Tom



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

Re: [Freedos-devel] Free FDISK interim builds

[tom ehlert]

>>> The reason why partition boundaries are aligned on cylinder boundaries
>>> is that a lot of other OSes also rely on that.
>> any example of this? I don't any (not completely braindead) operating
>> system would rely on that; it's just the way that FDISK and friends
>> place partitions on the disk.
> Well, Linux might do this, I am pretty sure older DOS versions do, OS/2
> and Windows 9x is likely to do this as well.

what "this"?

placing partitions on a cylinder boundary? well, FDISK did this as
well until now.

> This was a very common  problem

what kind of "problem"?

> and I know that I was talking with Brian  about this when he was
> still the maintainer of FDISK, but my current emails for this (and other
> FreeDOS related  ones) are only going back until 2013 and this was 
> discussed before that.

Sorry, Brian (in the ~2004 timeframe)
was completely, utter clueless about just everything. that's why FDISK
is such a mess. citing him as kind of expert doesn't support your case.

> A quick Google search before heading out of the office found for example
> this:

> https://www.linuxquestions.org/questions/ubuntu-63/how-to-fix-%27partition-not-end-on-cylinder-boundary%27-768635/

"Not a problem - ignore it."

> or this

> https://www.veritas.com/support/en_US/article.100025188

??

again: what kind of problem?

not ending on a cylinder boundary is NOT a problem.

however it shouldn't be a alignment problem if it would always do.


Tom



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

Re: [Freedos-devel] Free FDISK interim builds

[tom ehlert]

Hallo Herr Ralf Quint,

am Mittwoch, 1. März 2023 um 18:08 schrieben Sie:

> On 3/1/2023 8:22 AM, Bernd Boeckmann via Freedos-devel wrote:
>> Hello,
>>
>> I am now reaching a state where I think that FDISK not any longer breaks the 
>> partition layouts created by itself.
>>
>> However, there is at least still one MAJOR flaw when dealing with partition 
>> layouts created by other partition managers:
>>
>> If there exists an extended partition with a start address not aligned to 
>> cylinder boundaries, the position and size determination for logical drives 
>> is completely messed up.
>>
>> For example: While continuing to cylinder-align the logical partitions, this 
>> is only reflected by the CHS values and not by the corresponding LBA sector 
>> numbers. CHS and LBA sectors get out of sync because of some wired mix of 
>> doing LBA and CHS calculation. A problematic line is for example:
>>
>> https://github.com/boeckmann/fdisk/blob/2c7da2178c097792c3642e73eeb319330e122c71/SOURCE/FDISK/PCOMPUTE.C#L189
>>
>> Here the relative starting sector gets set unconditionally. But that is 
>> wrong in case the extended partition does not start on a cylinder boundary 
>> while the logical still gets aligned to it.
>>
>> I must confess that I do not really know how to solve this issue without 
>> being in danger to completely break everything and want to ask:
>>
>> a) If someone has an idea of a clever solution without rewriting the (sadly 
>> large) calculation routines.
>>
>> b) If it would be ok (at least as an interim solution) to make FDISK refuse 
>> handling disks with such type of partition layout, because the user must 
>> have another partition manager to create such layouts anyway. While not 
>> being optimal, I think this is better than letting FDISK break things.
>>
>> Greetings, Bernd


> The reason why partition boundaries are aligned on cylinder boundaries
> is that a lot of other OSes also rely on that.

any example of this? I don't any (not completely braindead) operating
system would rely on that; it's just the way that FDISK and friends
place partitions on the disk.

I don't think FORMAT or file systems ever relied on cylinder boundary
alignment; at least they shouldn't.

Tom



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

Re: [Freedos-devel] MS-DOG (was Re: [Freedos-user] FSF)

[tom ehlert]

Hallo Herr Rugxulo,

am Mittwoch, 1. März 2023 um 10:22 schrieben Sie:

 Hi again,

> It's entirely possible that Richard dislikes DOS that much.

I also dislike Richard. we can leave it at that.

Tom



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

Re: [Freedos-devel] IFS API

[tom ehlert]

 Hey!


> As a matter of curiosity, given that we were unable to find a
> precise answer to why Microsoft dropped IFS after MS-DOS 5.0

to start with, your question is pretty much nonsense. IFS or the
"networking redirector" was definitively there in MSDOS 6.2 and most
likely in 7 (aka Win95).

it just  just that's  the LANMAN and MSCDEX part
was implemented in the protected mode part of the OS.

but I'm pretty sure that NTFSDOS,
NTFS4DOS and friends would work on msdos 7 as well, allthough I never
tried that.

I don't even know where this idea even originated. it's pure BS, at
least for MSDOS 6.2.



> (although we had speculations),

yes. speculations.

>  I thought, why not ask ChatGPT (Bing) about that?

in the meantime everybody should know that ChatGPT has a very
convinced attitude telling nonsense. I think asking it to find new
pointers is legitimate. Taking the answer for truth is not.







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

Re: [Freedos-devel] Free FDISK interim builds

[tom ehlert]

Hallo Herr Bernd Boeckmann via Freedos-devel,

am Montag, 27. Februar 2023 um 13:07 schrieben Sie:


>> Am 27.02.2023 um 07:26 schrieb Deposite Pirate :
>> 
>> I'm not sure if this fdisk can already do that, but additionally it
>> would also be very useful if it could align partitions to 4k rather than
>> 63 sectors to lower wear on flash drives (SSD, CompactFlash).

> The current behaviour is to always align partitions to cylinder
> boundaries. This may be a multiple of 63 sectors if it corresponds to the 
> disk geometry.

> I did not find any option in the source code to force FDISK to use
> other alignment options . All the calculations are done on a
> cylinder basis, and the sector size is hardcoded to 512 bytes.

> Can it be modified with reasonable effort to at least support 4k
> alignment without rewriting 50% of the code? I think yes. One
> solution could be that within the calculated cylinder boundaries one
> could increase the starting sector by at most 7 to force an
> alignment to 4k. That would make the partition start on a 4k
> boundary.

that sounds like a really good idea, and old versions of anyDOS should
also handlethis well.

>  I am not sure if it is also necessary to decrease the end
> sector by at most 7 to make the partition size a multiple of 4k, but
> for safety reasons one should consider doing that.

I don't think this would be necessary; I don't think any reasonable
formatter that allows for a starting sector != 0 but not respecting
endsector!= maxsec-1


> This method would have the shortcoming that there can be little
> gaps of at most 15 sectors between the partitions. And I am not sure
> what that change would mean to the compatibility with older DOS
> versions in general, so that should better be hidden behind a feature flag.

I hate feature flags as they must be decovered first.

hiding it behind

   if lba_supported_by_disk and
  total_disk_size > 8,4 GB // max total size for CHS addressing
  {
  place partitions on 4K boundary
  }

Tom














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

Re: [Freedos-devel] IFS API

[tom ehlert]

Hallo Herr Ralf Quint,

am Dienstag, 21. Februar 2023 um 01:17 schrieben Sie:

>
> Don't recall when MSCDEX first showed up, but I think it was  
> after the networking redirector stuff (for both Novell and   LanManager) 
> in MS-DOS 3.0.

early version of Novell hooked a couple of interrupts (INT 21 beneath
them) to implement another filesystem on top of DOS.

when MSCDEX and the related 'networking interface' appeared Novell
reengineered the redirector to use this interface below DOS.

I dont know if long filenames where available on Novell on Win95, but
they were certainly not available on DOS.



Tom



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

Re: [Freedos-devel] IFS API

[tom ehlert]

Hallo Herr Ralf Quint,

am Montag, 20. Februar 2023 um 18:18 schrieben Sie:

> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
>> Hello,
>>
>> Does anyone know if the IFS (Installable File System) API is 
>> documented anywhere?

> There is no such thing for DOS. For DOS, things like this, for example
> for the CD-ROM (which is the only "file system" beside FAT that was ever
> implemented officially in DOS), the applicable interface is that of the
> "network redirector" introduced with DOS 3.0.
> I had a link to a Microsoft MSDN  web page about this, but that is 
> giving a 404 these days. I think Microsoft removed all that stuff years
> ago.

I don't know about MSDN specifically, but most stuff survives on 
https://web.archive.org

Tom




___
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

[tom ehlert]

> And to be clear: I don't plan to delete these from the FreeDOS Files
> Archive at Ibiblio. My proposal is just to not include them in the
> next FreeDOS distribution.
+1


> If people want to keep using, say, SEAL -
> they can download it and install it themselves.
as of many other packages.

Tom



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

Re: [Freedos-devel] DOS File Sharing- was: UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[tom ehlert]

> The main difference between using VBADOS and EtherDFS would come
> down to the DOS machine. If running DOS inside VirtualBox, VBADOS
> would most likely be the easiest to setup and use. However, using
> EtherDFS works under other Virtual Machines and with real hardware. 

EtherDFS should work for any (at least most) Virtual machines which s
good.

However it requires a linux machine to connect to which is bad.

VBADOS should work with any VirtualBox on whatever OS which is good.

Tom



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

Re: [Freedos-devel] DOS File Sharing- was: UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[tom ehlert]

https://forums.virtualbox.org/viewtopic.php?f=4=105823


I haven't tested this, but there seems to exist "VBSF.EXE -- a client
for Shared Folders. This allows shared folders to be mounted as drives
 inside MS-DOS (and Windows 3.x) directly, without any network stack."

which is more or less what you are searching.

Tom



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

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

>>> whatever EMM386 and friends was and is, it is definitively not what
>>> people think when they hear 'DOS VM'. you are abusing words to make a
>>> point. not good.

>> I don't really care. I am talking about how existing DOS 386 memory
>> managers have worked for 35+ years now.

>> The 80386 has hardware support for multiple concurrent DOS VMs. This
>> is called V86 mode. How *ALL* DOS 386 memory managers work is using
>> this features.

>> We cannot change the historical language now.

> I - as grandfather of FreeDOS EMM386 - may say that you are abusing
> 'DOS VM' when referring to what EMM386 does.

after rereading (and rethinking), I concede that 'DOS VM' is probably
correct.

I was just irritated because EMM386 actually does nothing beyond a
little memory mapping and implement DPMI, while a 'virtual machine'
like virtualPC, virtualBox, etc. does ininitively more.

but I think the black box with the command prompt in Windows is indead
often called the DOS VM or DosBox.

Tom





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

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

> I know. I am a professional in this field and have been since 1988.
> Please do me the courtesy of imagining that I know what I am talking
> about.

according to https://cz.linkedin.com/in/liamproven
FOSS and cloud reporter · Freelance writer and English teacher · Technical 
writer/editor ·
Software director · Customer Care Escalation Specialist · Technical Writer.


me, a professional *programmer* since 1983.

that's simply not the same level of experience.

Tom



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

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

>> 3. Develop embedded systems.

> Not sure that's important in 2023. Any citations?

http://wiki.freedos.org/wiki/index.php/Main_Page

>> whatever EMM386 and friends was and is, it is definitively not what
>> people think when they hear 'DOS VM'. you are abusing words to make a
>> point. not good.

> I don't really care. I am talking about how existing DOS 386 memory
> managers have worked for 35+ years now.

> The 80386 has hardware support for multiple concurrent DOS VMs. This
> is called V86 mode. How *ALL* DOS 386 memory managers work is using
> this features.

> We cannot change the historical language now.

I - as grandfather of FreeDOS EMM386 - may say that you are abusing
'DOS VM' when referring to what EMM386 does.




> That use case is already covered and so is irrelevant to this
> discussion, which I remind you is about how to boot DOS on a UEFI
> computer. You seem to have forgotten this.

according to your taste, install windows or linux.
then install DosBox.
start DosBox.
problem solved.

Tom




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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

[tom ehlert]

Hallo Herr Ben Collver,

am Freitag, 27. Januar 2023 um 18:23 schrieben Sie:

> On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:

>> any reason you don't download VirtualBox for your platform, select   
>>
>> proper devices (there is even a Soundblaster16 emulated), install DOS
>>
>> on it and go.

> VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.
> VirtualBox developers have gaslit DOS users about this in their
> forum.  It is a known problem and VirtualBox developers rejected
> fixes for it.  For technical details, see the following support ticket.

> https://www.virtualbox.org/ticket/14883

this is probably true. but fixing the VirtualBox SoundBlaster16 emulation
is several orders of magnitude easier then building your own SoundBlaster16 
emulation
on top of UEFI.

Tom




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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

[tom ehlert]

Hi,

most people around here already have a working machine, most likely
Windows or Linux.

any reason you don't download VirtualBox for your platform, select
proper devices (there is even a Soundblaster16 emulated), install DOS
on it and go.

VirtualBox isn't perfect, but probably much better then 'UEFI, virtual
BIOS and virtual hardware' will ever dream to be.
And it's probably getting better over time.

Tom




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

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

Hallo Herr Liam Proven,


> I suppose my first suggestion would be: sod Windows.

> A suggestion of a justification:
> If people want a FOSS DOS then they must use a FOSS GUI, and if they
> want a proprietary GUI then they must accept that also means a
> proprietary DOS underneath.

this argument is nonsense. many/most people don't care about the 'open source'
part as long as it's free.

most care more if this OS supports big disks or much memory.

after all, an OS is not an end target:
people need the OS to run their applications like

1. Play classic DOS games.

2. Run legacy software.

3. Develop embedded systems.

none of this is open source.

> A BIOS:

> Well there is already at least one FOSS BIOS out there -- SeaBIOS.

> https://www.seabios.org/SeaBIOS
> https://en.wikipedia.org/wiki/SeaBIOS

> Surely that's a start?

I can't see many users to reprogram their motherboard (even if it
would be supported) just to play a casual round of Doom or
Wolfenstein.

> In other words, from EMM386 to JEMM to QEMM, they were already, 30
> years ago, 32-bit code that set up a hardware DOS VM and ran DOS in
> it.

whatever EMM386 and friends was and is, it is definitively not what
people think when they hear 'DOS VM'. you are abusing words to make a
point. not good.

> Yes, I know that how they got there was different. They didn't cold boot.

> What I am saying is that if UEFI can only load 32-bit (or 64-bit but
> that's irrelevant to DOS) payloads, well, if we're running DOS on a
> 32-bit machine, we more or less need one of those anyway. So, is there
> a way to use it?

> Write a special 32-bit payload that can only do one thing:
> 1. load into RAM
> 2. load a generic BIOS emulation which only emulates a few fixed
> devices that are supported by DOS
> 3. set up a single V86 session
> 4. boot FreeDOS into that

and would be so completely useless that it hurts.

no network card.
no mouse.
no USB devices.
(no memory at b8000 or a)?
no sound.
nothing with interrupts.

congratulations.

> Then FreeDOS loads some kind of shim that talks to the memory manager
> that is already resident. The DOS sessions in Windows NT and OS/2 ≥2
> both do this already. It is, or was, a thing.

actually still is; however you need a 32 bit installation of windows.

certainly good enough to Run legacy software. playing games very much
depends on the game.

Tom



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

Re: [Freedos-devel] Re: Re: Google Summer of Code?

[tom ehlert]

Hallo Herr Wilhelm Spiegl,


> fdisk, chkdsk, dosfsck,  defrag and scandisk (not in distribution, empty gui).
> I have no problems to send you screenshots.
> fdisk, : https://gitlab.com/FreeDOS/base/fdisk/-/issues

fdisk has problems, yes.
none of these is related to fat32, but all to big disks.

and yes, the quality of chkdsk, dosfsck for fat32 is less then
optimal.

fdisk just needs a volunteer to bugfix it.

but nothing of this deserves a 'google summer of code' which is
IMO intended to support something *new* or *interesting* like reactos
would have been.



> willi


> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.comMail 
> gesendet.
> Am 22.01.23, 17:56 schrieb tom ehlert :Hi,  
>> the proposal was from me. Maybe some of you know that I work on the text for 
>> a new help version.  
>> To do so, I use different sources, depending on what I can get.  
>> Sometimes documentation is very good, sometimes there is none,  
>> sometimes even command/? gives no information and I have to guess, read 
>> books or run tests.  
>> So I have to run each command in a virtual machine and test it. And  
>> when doing this, I noticed that some programs are really good but some...  
>> Among others, all programs that have to do with creating a file  
>> system have problems with fat32 support.  

> there are exactly 2 (maybe 3) commands thatb deal with fat32 at all:  
> format, chkdsk (and friends) and maybe defrag, while I have no idea  
> about defrag status.  

> now it would be cool if you gave at least examples of what  
> 'programs', and what 'problems'  

> none other 'commands' should be even aware of what filesystem they are
> dealing with. or are you confounding 'fat32' with 'LFN'?  

>> One of them is an empty GUI.  
> name please. if that were true it tuely shouldn't be distributed.  



>> So I had the idea with summer of code.  
>> Well, what can happen?  

> given that for the last 10+ years exactly 2 FreeDOS programs have made
> any progress (ignoring any internationalisation stuff), I see expect the 
> chances by +-0%.

> by the way, the 2 programs are the setup stuff and edlin. hardly  
> rocket science.  

> Tom  




> ___  
> 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

Re: [Freedos-devel] Re: Google Summer of Code?

[tom ehlert]

 Hi,
> the proposal was from me. Maybe some of you know that I work on the text for 
> a new help version.
> To do so, I use different sources, depending on what I can get.
> Sometimes documentation is very good, sometimes there is none,
> sometimes even command/? gives no information and I have to guess, read books 
> or run tests.
> So I have to run each command in a virtual machine and test it. And
> when doing this, I noticed that some programs are really good but some...
> Among others, all programs that have to do with creating a file
> system have problems with fat32 support.

there are exactly 2 (maybe 3) commands thatb deal with fat32 at all:
format, chkdsk (and friends) and maybe defrag, while I have no idea
about defrag status.

now  it would be cool if you gave at least examples of what
'programs', and what 'problems'

none other 'commands' should be even aware of what filesystem they are
dealing with. or are you confounding 'fat32' with 'LFN'?

> One of them is an empty GUI.
name please. if that were true it tuely shouldn't be distributed.



> So I had the idea with summer of code.
> Well, what can happen?

given that for the last 10+ years exactly 2 FreeDOS programs have made
any progress (ignoring any internationalisation stuff), I see expect the 
chances by +-0%.

by the way, the 2 programs are the setup stuff and edlin. hardly
rocket science.

Tom




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

Re: [Freedos-devel] Re: Where to start and continue?

[tom ehlert]

Hallo Herr Knedlik,

am Sonntag, 15. Januar 2023 um 15:17 schrieben Sie:

> Okay, I’m still even a few days after very confused. I came into
> DOS with my only programming knowledge being on modern 64-bit
> systems and I didn’t even go lower-level than C++.
> I have no idea where to start - I would love to learn how to do all
> the cool stuff like graphics and then extending the base stuff with
> more bits (a bit theoretical, but would a 64-bit extender be
> possible?) and a GUI desktop, but where do I learn this stuff? What should I 
> learn as a prerequisite?

learn to search. maybe

https://open-watcom.github.io/open-watcom-v2-wikidocs/clib.html#Graphics_Library

Tom



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

Re: [Freedos-devel] Re: Where to start and continue?

[tom ehlert]

> Okay, I’m still even a few days after very confused. I came into
> DOS with my only programming knowledge being on modern 64-bit
> systems and I didn’t even go lower-level than C++.
> I have no idea where to start - I would love to learn how to do all
> the cool stuff like graphics and then extending the base stuff with
> more bits (a bit theoretical, but would a 64-bit extender be
> possible?) and a GUI desktop, but where do I learn this stuff? What should I 
> learn as a prerequisite?

even in the dark times of MSDOS, there was these things called
'books'.

you may also learn by looking at how other people have done this; look
at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/gui/
there is plenty software drwaing lines and other stuff.

last not least, google. there are still bazillion resources out there.


Tom





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

Re: [Freedos-devel] Linking asm with C

[tom ehlert]

> Okay, this is just weird.
> I can’t for the love of god figure out why this is throwing the divide by 
> zero interrupt.

a) learn to use a debugger. single step  this stuff. you will likely see
that 'ret' is not a good idea in inline assembly in general.

also

   WDIS graphic.obj > graphic.txt

shows you why some instructions in inline assembly are usually
forbidden.


b) don't use assembly for this.

#include 

 int setMCGA() {
  _REGS r;

  r.h.ah = 0x13;
  _int86(0x10, , );

  if (r.flags & _CARRY)
 {
 printf("setting MCGA failed because %x\n", r.h.al);
 return 1;
 }
return 0;
 }

does the same, works with every compiler around and avoids this
trouble.


last not least,

INT 10 - VIDEO - SET VIDEO MODE
AH = 00h
AL = desired video mode (see #00010)






> 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





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

Re: [Freedos-devel] Linking asm with C

[tom ehlert]

> I’m currently trying to make a function in a separate assembly
> file, but I’m having problems linking it with a C program.

it always helps to take the time to describe the problem you are
facing, like


what compiler, assembler, linker

WHAT KIND OF PROBLEMS

Tom



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

Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?

[tom ehlert]

> You really don't want a 160 kb editor on a floppy (unless you copy it
> to a RAM disk).

copying it to a RAM disk will require 1 or 2 seconds every time you
boot this floppy.

starting this from floppy requires 1 or 2 seconds every time you use
the editor - usually less often then you use to boot this very floppy
- remember we are about editing CONFIG.SYS/AUTOEXEC.BAT.

YMMV

of course for editing CONFIG.SYS/AUTOEXEC.BAT some 3-10KB editor
should probably do as well.

Tom



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

Re: [Freedos-devel] Toggling directories

[tom ehlert]

> In general, I find that toggling options are a bad idea.  Things
> just get too confusing, especially if you have multiple "sources"
> for the options (like combinations of internal/compile-time default
> settings, environment variables, options entered through a batch
> file, options entered via a command-line, etc.).  It just gets too
> confusing to keep track of whether in total you've entered an even or odd 
> number of "toggles".

> I usually set up my programs so that there is a +/- or yes/no
> "sub-option".  Rather than toggling, there is an "override" or
> "priority" process of which option to use.  For example, an option
> provided through an environment variable takes priority over a
> default/internal option -- it does not "toggle" the internal option
> but rather completely overrides it.  Similarly, an option entered on
> the command-line takes priority over an option provided through an
> environment variable.  I find this approach much less confusing than toggling.

I agree with your reasoning, but the reasoning is pretty much
irrelevant.

The rules are made by MS COMMAND.COM, and are most likely (most of the
times?) set, not toggle.

now I wonder who will verify this, and why did the original author
even implement toggling instead of setting.

maybe even one of our assembler gurus looks at published sources of msdos 2.01

Tom




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

Re: [Freedos-devel] Toggling directories

[tom ehlert]

Hallo Herr Jerome Shidel,

am Mittwoch, 9. November 2022 um 16:26 schrieben Sie:


> Not all options perform toggling. For example:


> dir /p  - pauses per page
> dir /p /p   - pauses per page


> I don’t think the toggling is very important. But, it does deviant from 
> MS-DOS.
> I do think that consistency across the options is important.

as Aitor said:"To me this is a bug. Not a major one, but a bug."

if you look at the source (cmd\dir.c)

...

optScanFct(opt_dir)
{
  (void)arg;
  switch(ch) {
  case 'S': return optScanBool(optS);
  case 'P': return optScanBool2(optP);  /* multiple uses, /P /P, do not cancel, 
only /-P */
  case 'W': return optScanBool(optW);
  case 'B': return optScanBool(optB);



virtually all options toggle, but someone probably noted that /P
should not toggle, because even after

  set DIRCMD=/P

  DIR /P

should still pause.

MSDOS probably has not toggling at all (I'm not sure; someone who is not
named Tom should test this), and optScanBool() should be replaced by
optScanBool2() all over FreeCOM.

Tom





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

[Freedos-devel] GPT disk detection in FreeDOS kernel

[tom ehlert]

to make myself a better mailing list citizen, I created a new topic
for this different issue ;)

I have INITDISK.C that will detect and
mount GPT partitions if available.
FAT partitions on GPT disks are fully 'normal' drives.

to be discussed, and I have no strong opinion here:

shall FreeDOS kernel detect and mount

  a) all partitions on GPT disks, or

  b) mount only partitions on GPT disks, that are 'basic data
 partitions'

  c) make this behaviour patchable using SYS CONFIG GPT_MOUNT_ALL=1

the current implementation only allows partitions that fir entirely
below 2TB, but it's no big deal to allow >2TB. max. partitionsize
remains at 2TB though as this is a filesystem limitation.



additionally: as the patch is almost trivial, this could also be
installed (and uninstalled)  similar to a RAM disk, i.e. by an external device 
or TSR
and be even used in MSDOS/DRDOS.


Tom



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

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

[tom ehlert]

Hi all,

it seems this case is not as dramatic as it seemed first (to me).

to repeat my earlier steps, I downloaded and installed
kernel-master.zip and country.zip; edited config.bat to
COMPILER=OWWIN, compiled and the resulting kernel.sys booted as it
should.

BUT: when I edited config.c, and again BUILD the kernel, UPX throws
some errors and the resulting kernel.sys does not boot.

after
 del*.obj /s
and
 BUILD

the resulting kernel works again.



2 more things:

in config.sys,

  !screen=0x12

is ignored (other options not tested)


I have INITDISK.C that will detect and
mount GPT partitions if available.
FAT partitions on GPT disks are fully 'normal' drives.

to be discussed, and I have no strong opinion here:

shall FreeDOS kernel detect and mount

  a) all partitions on GPT disks, or

  b) mount only partitions on GPT disks, that are 'basic data
 partitions'

  c) make this behaviour patchable using SYS CONFIG GPT_MOUNT_ALL=1

Tom





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

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

[tom ehlert]

> Does it make a difference on your computer if the kernel is
> compiled for 386+ vs 86+  ?  Was this on real computer or virtual? 

it was a VirtualBox machine.

I only changed in build.bat from build.b the compiler setting, using
OCWIN, so it probably was 8086

of course I have a very specific floppy, RAM setup aso.

however at this point ("GO!") almost all of this is irrelevant.



if that helps, I can upload the contents of the resulting
freedos-master\* directory.




Tom



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

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

[tom ehlert]

>  correcting for this, the the boooting kernel goes as far as

> I'm looking into this, seems to be some sort of memory corruption. 
> On my test VirtualBox vm it works fine, on my laptop I get a halt
> but much later than you, where FreeCom is loading.  The gcc compiled
> kernel works in all my tests.  Testing on my laptop is a pain as
> it's my primary computer and I have to go into UEFI enable/disable
> BIOS boot for each test and then boot back into my primary OS to
> make changes and repeat.  I am going to try and see if I can
> replicate the boot issue on one of my older computers this weekend
> so I can find and fix the problem quicker. 

I did my tests on a virtual machine on top of VirtualBox 5.2.44
running on top of WindowsXP.

I can send you the virtual machine by PM or FTP

Tom



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

Re: [Freedos-devel] Bonus/Devel CD

[tom ehlert]

> One of the main things that started me down this rabbit trail was
> the need to know which Ethernet card is being virtualized in a
> particular VM so I can load the correct packet driver.

> I have a
> single ETHERNET.BAT file I run to install the packet driver, and
> since detecting which network card is installed is a tricky
> proposition I do it indirectly by detecting the VM (or lack of VM if I'm 
> running on real hardware).

VirtualBox gives you the chance to have 5 different network cards;
other virtualizers probably similar.

how does detecting VirtualBox help you decide to use which adapter is
present?

as said before, PCI detection is used by everybody else, and should
also be good enough for you

Tom




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

Re: [Freedos-devel] Bonus/Devel CD

[tom ehlert]

> One of the main things that started me down this rabbit trail was
> the need to know which Ethernet card is being virtualized in a
> particular VM so I can load the correct packet driver.

ca. 30 years ago PCI enumerating has been invented.


>  I have a
> single ETHERNET.BAT file I run to install the packet driver, and
> since detecting which network card is installed is a tricky
> proposition

it's not at all tricky (if you avoid machines without PCI Bios).

it's pretty much straight forward, and there are a couple of programs
(even somewhere in FreeDOS) implementing 'what network card is
present'. works in VMs and real hardware.

Tom



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

[Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

[tom ehlert]

Sorry,

I posted this under the wrong topic.

so:

when downloading https://github.com/FDOS/kernel via

[code] downnload ZIP

the downloaded kernel-master\country directory is empty, and the
project does not build.

correcting for this, the the boooting kernel goes as far as


FreeDOS boot FAT kernel GO!

and halts.


 the compiler is watcom C

Tom




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

Re: [Freedos-devel] Bonus/Devel CD

[tom ehlert]

when downloading https://github.com/FDOS/kernel via

[code] downnload ZIP

the downloaded kernel-master\country directory is empty, and the
project does not build.

correcting for this, the the boooting kernel goes as far as


FreeDOS boot FAT kernel GO!

compiler watcom C

Tom



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

Re: [Freedos-devel] FreeDOS Interim Build T2210

[tom ehlert]

> I’ve just uploaded this months Interim Build to ibiblio. To test
> T2210, you can fetch it from
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/


> I’ve warned about this several times. But with the recent updates
> and few additions to the DJGPP packages, the BonusCD has blown way
> past the upper limits of a CD. At approximately 925mb, it will
> require a DVD to burn the image to disc. 


> I don’t think a 925mb “CD” is a good thing.


> As I see it, this leaves us with 3 choices:


> 1) Drop nearly 300mb of packages from the CD.
> 2) Do nothing and call it a DVD
> 3) Move all development related packages onto their own disc. Have DevelCD 
> and seperate BonusCD.

4) Split it into 2 CD's. it's a BONUS CD, to be used after install
anyway.

btw dowloading 900  MB .zip over a 4MB/s download link is a PITA; this
alone should recommend a split.

Tom



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

Re: [Freedos-devel] MKEYB layout suggestion

[tom ehlert]

> I do not know if you have either the time or interest in this. 
definitively neither.
just because some random guy on the internet proposes a new keyboard
layout doesn't mean it should be implemented anywhere. remeber the
Dvorak keyboard layout and it's phenomenal success?

> I just wanted to point it out in case you were not aware.



> A request for an additional MKEYB layout on the GitLab archive. 


> https://gitlab.com/FreeDOS/base/mkeyb/-/issues/1


> The request was for "Implement AI low finger displacement layout”. 


> :-)



:)

Tom



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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[tom ehlert]

Hi Robert,

>>> But there are many good (and free)
>>> text editors available for DOS that can edit large text.
>> 
>> True enough. and people have had time enough (it's 2022) to select one

> Not everbody is with DOS since the 1980s. There are still DOS newbies
> around from time to time.
welcome.

just remember that we had even the holy https://en.wikipedia.org/wiki/Editor_war

how would we be able to indoctrinate newbies into one single editor
religion?

I think even newbies should be given the chance to select from


https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-edit.html

and multiple other sources to change their own religion?


disclaimer: I'm probably no expert in DOS editors (anymore).
over the last 20 years of my freedos engagement I
haven't used an editor on my dos instances more then 20 times (quick
editing autoexec/config ).

everything else is edited on a multifile, multiwindow, multiscreen AND
multigigabyte machine and copied to the machine. takes <1s with a virtual
machine and <10 s with a physical floppy.

of course, if as a hobby you want to have a feel for 1980 XT developement pain 
you
should use edlin.

ok, nobody used edlin ever. but professional editors could be
pricey...

but still nobody used edlin. ever.

Tom






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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[tom ehlert]

Hallo Herr Paul Dufresne via Freedos-devel,

am Donnerstag, 25. August 2022 um 15:41 schrieben Sie:

>  
>>it's still beyond my understanding why you don't want to edit small 
>>files with edit32 
>>
>> Tom

> Well, because the full idea is more like:

> If file < 64k
>   then edit.exe the file
else (file >> 64k)
>   if processor 386+
> edit32 the file
>   else
> error "sorry, file to big!"
>   endif
> enfif

I think this should be

   if processor 386+
 edit32 the file
   else
 edit.exe the file
   endif


IMHO getting a different editor depending on filesize is not your best idea

and btw it's not necessary to have a 386+ CPU to edit a 500 KB+ file.
there were definitively (nonfree) editors around in 80286 times.

all that is required is a programmer that wants to implement this.

I wouldn't hold my breath though.


Tom



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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[tom ehlert]

> Besides the 64k limit, FreeDOS Edit is horrible to use on an XT.
> Compared to norton editor or edit.com, the drawing of the interface
> is so slow you can see it happening.

if you own an XT, you have probably become used to an editor for the last 30
years on it. I don't see the point chosing another one.

Tom



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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[tom ehlert]

> But there are many good (and free)
> text editors available for DOS that can edit large text.

True enough. and people have had time enough (it's 2022) to select one
of them that suits their needs. and there are multiple (of varying
taste and quality) in FreeDOS and elsewhere.

but none of them comes as close in behaviour (like shortcuts, menu
structure etc.) to MS Edit as the one that FreeDOS choses to call
'EDIT'.


> "edit.exe" is a simple and limited tool, but good enough for the intended use 
> case.

actually edit.exe was not the intended use case. EDIT was just the
first (and only ?) application using the DFLAT library. DFLAT was
decribed and implemented as multiple articles in Dr.Dobbs magazine,
demonstrating and implementing windows(tm) programming techniques.

so the intended use case was 'demonstrate windows programming
technique'. never to be a useful editor.

this happened more or less by chance.

Tom





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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[tom ehlert]

> Would it be possible to have edit.exe for 64k less files...
> edit32.exe for bigger files...

absolutely yes. just copy setedit.exe to edit32.exe. done.

> and edit.bat that would check fif the
> requested file to edit is bigger than 64k and then call edit32 on
> the file, else edit.exe on the file?

it's still beyond my understanding why you don't want to edit small
files with edit32

Tom





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

Re: [Freedos-devel] Interim FreeDOS Build T2208

[tom ehlert]

Hallo Herr Jim Hall,

am Montag, 1. August 2022 um 16:08 schrieben Sie:

>> Hi! I agree it would be good to have a changelog visible before
>> downloading those 100s of megabytes
> [..]

>> > I think it's pretty rude behaviour wrt the testers to throw once per
>> > month 500 MB with a bazillion of subprojects at the testers, with only
>> > 'please test this' without any mentioning of
> [..]


> I think folks may have missed that there's a changelog in the Interim
> Test Build directory:

> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log

> From my reading of the changelog, almost all of the changes in this
> Interim Test Build from FreeDOS 1.3 are NLS updates, plus some version
> updates of other packages like dojs, jemm, gopherus, and a few others.

so we should test the version numbers?

2022-02-25 06:46:13 gopherus (Shidel): v1.2.1
2022-03-02 13:54:44 utf8tocp (Shidel): v0.9.4

is not a changelog. a changelog explains the what and why of the
change. not that the change resulted in a new version number.

version numbers of the packages contained should be possible to obtain somewhere
else, even if the package didn't change.

Tom




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