Re: [Freedos-kernel] How do I compile just the bootsector and kernel?

[Louis Santillan]

See the FreeDOS Spec [0].  OpenWatcom C/C++ (1.9?) (and by extension
WASM/JWASM? for ASM??) and NASM (no version either though many are
based on 0.98.x) are the reference compilers/assemblers/linker.

I was able to able to compile a recent kernel version with the
non-reference compiler Borland C/C++ 4.5.2 (the last Borland C/C++
compiler to support DOS compiling executables).  I had to make minor
changes to the Makefiles to successfully compile the kernel.  See the
mailing list archives for my notes.

[0] http://wiki.freedos.org/wiki/index.php/FreeDOS_Spec#Programming_tools

On Wed, Jan 4, 2017 at 11:17 PM, Mateusz Viste  wrote:
> On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote:
>> Of all the many files in the FreeDOS sourcecode, which files will I need
>> if I just want to compile the bootsector and the kernel?
>
> You'll need the source files present in the "KERNEL" package,
> unsurprisingly. You can also fetch these sources on-line here:
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/
>
>> And also, what is the recommended free compiler (I'm
>> not about to spend money to buy one) for use in compiling the FreeDOS
>> bootsector and kernel?
>
> The FreeDOS kernel can supposedly be compiled with the following
> compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C.
> >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both
> are free (no cost). Using Turbo C requires to change a few lines of
> comments though, as I wrote here the 26th November of last year (still
> not fixed on SVN).
>
> Mateusz
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

[Louis Santillan]

Method 1 is the traditional DOS way of installing software.

Maybe some advanced usage of JOIN & SUBST is what you are looking for?

Another alternative (though slightly messy) would be to combine
Methods 1 & 4.  By that, I mean, leave the *.bats in C:\DOS.  The
*.bats will temporarily create a new Environment & PATH extended as
the application expects and then remove the adjustment.  This will
slow down many types of computing, as HPA mentioned, SW builds come to
mind

-L.

On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste  wrote:
> On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
>> But why the batch file in the first place?  It truly makes no sense: it
>> pollutes the namespace equally, and can just cause problems (e.g. in the
>> case of more than 9 arguments.)  Not to mention slowing down a make.
>
> Here's the thing: I, as a user, store lots of useful software on my PC.
> Many of these programs are so useful that I like to have them available
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
>
> To achieve this, I know of four ways. Each comes with some limitations.
>
> Method 1: Store every program in its own directory, and add each
> directory to the %PATH%. Problem: obviously the environment will get very
> bloated, very fast. Besides, some programs come with add-on tools that I
> do not want to be available from within my path.
>
> Method 2: Trim out the programs from everything besides a single exe, and
> put them all in a single directory declared in my %PATH%. But this poses
> two problems that I cannot live with: first, not every program can be
> trimmed out to a single executable file (data files, config files, etc),
> and second - almost all programs come with their respective README files
> and other valuable documentation that I really want to keep within the
> vicinity of the executable (ie. in the same directory).
>
> Method 3: Store each tool in its own directory, and place a COPY of its
> executable inside a directory in the %PATH%. Well, this is just messy -
> upgrading the program needs to think about replacing the executable each
> time in both places, and it's simply a waste of disk space.
>
> Method 4: Keep each program in its own directory with all its original
> files, and only store *.bat "links" in a single directory somewhere in
> the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
> unfortunately, of *.bat's own limitations (max 9 args and '=' processing
> weirdness).
>
> The method 4 is what I started doing back in the nineties, and as of
> today I still didn't find a better (or let's say, less worse) way. That's
> a lifetime project it would seem.
>
> The method 4 is also something that I implemented last year inside FDNPKG
> (the FreeDOS package manager), but since I discovered recently how oddly
> the '=' character is processed in %1-like arguments (there's a separate
> thread about that on freedos-devel), I will have to figure out some
> improved method... first thought pointed to computing some COM loader
> relying on INT21,4Bh but that's far less trivial than the current batch
> method, and hobby time is scarce.
>
> Mateusz
>
>
> --
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

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

Re: [Freedos-kernel] EXT3 support

[Louis Santillan]

Hiren's BootCD has had something called Paragon Mount Everything 3.0.
Or are you interested in writing a new driver?

On Fri, Aug 14, 2015 at 1:28 PM, Ralf Quint freedos...@gmail.com wrote:
 On 8/14/2015 12:38 AM, Daniel G. wrote:
 Greetings,

 I was reading the FreeDOS development wish-list and adding ext3
 support to the FreeDOS kernel is on the list.  Is anyone working on
 this at this time?

 Doubtful. It's more likely just wishful thinking from someone who
 doesn't know what all might be involved in actually implementing this...

 Ralf

 ---
 This email has been checked for viruses by Avast antivirus software.
 https://www.avast.com/antivirus


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

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

Re: [Freedos-kernel] EXT3 support

[Louis Santillan]

Maybe, but ext3 was designed as a multithreading FS.  The
multithreading becomes single threading so performance would far
worse, and possibly even worse than FAT16/32 or ext3 over redirector.

On Fri, Aug 14, 2015 at 3:00 PM, Till oran...@mygrande.net wrote:

 Quoting João Jerónimo j_j_b_o_de...@yahoo.com:

 Wouldn't it be better to use a redirector? This can be done with a TSR.

 João Jerónimo



 A TSR redirector would be great for assigning an EXT3 drive to a drive
 letter for standard I/O operations.  However a kernel driver would
 allow freeDOS to boot and run from an EXT3 journaling partition, I can
 only imagine that the benefits from this would be huge.



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

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

Re: [Freedos-kernel] [Freedos-devel] Regarding Issue with FreeDOS.

[Louis Santillan]

Autoexec.bat and config.sys would likely be useful here, especially to
understand the value of LASTDRIVE and to know if any other disk drive
drivers are installed (CDROM, SATA, USB, Zip, etc.).

Ideally, everyone matches MS-DOS, so knowing what functest returns there
might help.

On Sunday, September 14, 2014, Anil Nair anilcol...@gmail.com wrote:

 Hello All,

 We were working on PDOS development particularly interrupt number Int
 21/AH=0Eh(Select Default Drive). While testing the PDOS function i came
 across a particular behaviour in FreeDOS, according to the description
 given in the documentation http://www.ctyme.com/intr/rb-2570.htm;

 Return: AL = number of potentially valid drive letters.

 When tested using a function PDOS returns,

 Booting from Hard Disk...
 welcome to PDOS-16
 welcome to pcomm

 C:\functest

 The return value is x 4 x

 C:\

 While testing the same behaviour in FreeDOS,

 C:\DEVEL\PDOS\SRCfunctest

 The return value is x 5 x

 C:\DEVEL\PDOS\SRC

 Is this expected? Please let me know if anybody needs more details.

 --
 Regards,
 Anil Nair

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

I apologize for mis-posting to fd-user previously.

On Thu, May 16, 2013 at 10:47 AM, Tom Ehlert t...@drivesnapshot.de wrote:

 Dear Louis,

 a few points

 a) the FreeDOS project isn't very interested in a BC5 compiled
 kernel because BC5 isn't freely available/open source;
 I also doubt the output of BC5 will be significant better then the OW
 output.
 feel free to experiment, but don't expect us to be excited ;)


I'm not sure how you can say the FreeDOS project isn't interested in a BC5
kernel.  The BC5 makefiles I found in the kernel sources I didn't write.
 Bart last worked on them 9 years ago.  Bit rotten for sure and OW became
usable in that time.  So yes, priorities change, but I'm taking the posted
FreeDOS Roadmap, as goals and stretch goals for the project.  I read
(paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
 64-bit support, device driver imports, automated regression testing. I've
done a couple of simple tests and I am getting 32-bit register code from my
copy of BC5.  The Roadmap is reason enough for me, personally, to continue
to 'experiment' as you say.  There's no way of getting 32-bit real mode
code from OW.  So for now, until someone teaches OW some new tricks, I'll
work with BC5.



  So, something in the make files/build files is skipping building a
 concrete
  GLOBAL for ReturnAnyDosVersionExpected for BC5.  There's a MAIN define
  checked but the build process doesn't seem to get defined anywhere. :/

 b) when trying to port the kernel to a new compiler, you should be
 able to fix such issues yourself. generate assembler output, see what
 is wrong. you will need this as the FreeDOS uses the
  'interesting memory model (TM)'


Again, I'm not doing any porting.  And I do intend to work this issue.
 However, software development, like many human endeavors, is best done
collaboratively  socially, IMO.  If someone in the last 9 years has
compiled the kernel with BC5, they might have tips for me.  Heck, I
remember when the kernel was TASM/BC only, and only a select few could
afford to contribute.  I advocated back then (almost 15 years ago) for
porting to open tools.  I'm glad the early FreeCOM/Kernel developers had
made the effort to port to open tools.


  Need to do more digging.
 c) no need to write 'need more digging' type of mails. use your
 twitter account for that.


I don't have a twitter account.  Feel free to filter emails from me to your
spambox.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Fwd: [Freedos-user] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

Whoops, didn't realize that I replied to fd-user instead of kernel.

One other note, all kernels are slightly bigger withe options I set.

-L

-- Forwarded message --
From: Louis Santillan lpsan...@gmail.com
Date: Sun, May 5, 2013 at 9:01 AM
Subject: Re: [Freedos-user] Any interest in 486, 586, 686 kernels?
To: Discussion and general questions about FreeDOS. 
freedos-u...@lists.sourceforge.net


Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles.  Read (
ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
2.3.x  3.5.  Enlightening and disappointing.  There does not seem to be a
way to get 32-bit instructions out of wcc as Tom had mentioned.  3.5
recommends

The recommended options for generating the fastest 16-bit Intel code are:
Pentium Pro /onatx /oh /oi+ /ei /zp8 /6 /fpi87 /fp6
Pentium /onatx /oh /oi+ /ei /zp8 /5 /fpi87 /fp5
486 /onatx /oh /oi+ /ei /zp8 /4 /fpi87 /fp3
386 /onatx /oh /oi+ /ei /zp8 /3 /fpi87 /fp3
286 /onatx /oh /oi+ /ei /zp8 /2 /fpi87 /fp2
186 /onatx /oh /oi+ /ei /zp8 /1 /fpi87
8086 /onatx /oh /oi+ /ei /zp8 /0 /fpi87

-ot of -onatx  -zp8 contradict the original makefile's code -os  -zp1
(optimize execution time vs. executable size  align on byte vs. 8-byte,
respectively).  Also, the -fp*'s opts don't apply and wcc barfs on -oi+.

So in mkfiles\watcom.mk I added some code to add -6-onaxlkh-ei (for 686).
 This will reorder instruction significantly and replace some call nears
with jmps in a comparison of 386 timed code vs. 686 timed code.  Code is
larger on the 686 side.

So far, not very impressed with OW 1.9's optimizer. Rather minimal
improvements.  Anybody play with BCC 5.5  HX-DOS recently?

-L



On Sat, May 4, 2013 at 3:27 AM, Tom Ehlert t...@drivesnapshot.de wrote:

 Hallo Herr Louis Santillan,


  https://sites.google.com/site/lpsantil/Home/386DIS.ZIP
  https://sites.google.com/site/lpsantil/Home/686DIS.ZIP
  https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP
  https://sites.google.com/site/lpsantil/Home/kernels.zip

 the differenz is an empty memdisk.lst (for whatever reason)
 everything else is *identical*

 I'm not impressed

 Tom



 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Freedos-user mailing list
 freedos-u...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

Haha...I'd be interested if you ever developed a 586 core at 1GHz that
could utilize DDR-3 upto 4GB.


On Sat, May 4, 2013 at 1:43 AM, ht-lab han...@ht-lab.com wrote:

 On 03/05/2013 15:55, Tom Ehlert wrote:

  In the past, we compiled kernels for 8086, 186 and
  386 separately afair. I guess we got lazy and have
  dropped 186 because very few users have 186/286 as
  their CPU? They either have modern or REALLY old.
  this is not about 'lazy'
  it's easier for the user to select between 2 choices then between
  4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
 
  there's not much use for a 186 kernel as NOBODY has 186/286 machines
  these days,
 Really, NOBODY.

 Hans
 www.ht-lab.com





 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Freedos-kernel mailing list
 Freedos-kernel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-kernel

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote:


 Hi Louis,

 if I understand your patch correctly, you only changed the
 build configuration to check how it affects the size of
 the compiled kernel before UPX compression, which also is
 an indicator of RAM size of the kernel? You changed the
 config.b, build.bat, buildall.bat files and generic.mak
 and watcom.mak and the resulting kernel sizes give the
 impression that in fact you only have FOUR distinct CPU
 optimizations, rather than seven cases...

 Yes.  And just ran md5sum's against the kernels to verify this

3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
623498bd71a46d16bcef211e743a9bed  kwc38616.sys
c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

69eb7732f791db340632f722c9dbce16  kwc8632.sys
f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
1e4fd656603fd09171d9d85631e77045  kwc28632.sys
b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
know much about 586+ arch's but can use the instructions in special
situations.  And this makes sense when you consider when Watcom fell out of
favor commercially and probably saw it's last real optimizer work.


 Kernels without FAT32:

 086: 64158 bytes
 186: 63028 bytes (286 same)
 386: 62164 bytes
 486: 62068 bytes (586 and 686 same)

 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)

 [SNIP]

 Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
in the kernel now and possibly the string functions.  But just an idea
right now.

-L
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?

[Louis Santillan]

What's the difference between wcc  wcc386?  I noticed that wcc386 adds
-5s, -5r, -fp5 (-6 equivalents) for stack, register and fpu optimization.
 Does wcc386 generate code that could be used in the kernel?

-L


On Fri, May 3, 2013 at 5:57 AM, Louis Santillan lpsan...@gmail.com wrote:

 On Fri, May 3, 2013 at 4:02 AM, Eric Auer e.a...@jpberlin.de wrote:


 Hi Louis,

 if I understand your patch correctly, you only changed the
 build configuration to check how it affects the size of
 the compiled kernel before UPX compression, which also is
 an indicator of RAM size of the kernel? You changed the
 config.b, build.bat, buildall.bat files and generic.mak
 and watcom.mak and the resulting kernel sizes give the
 impression that in fact you only have FOUR distinct CPU
 optimizations, rather than seven cases...

 Yes.  And just ran md5sum's against the kernels to verify this

 3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
 40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
 2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
 623498bd71a46d16bcef211e743a9bed  kwc38616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
 c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

 69eb7732f791db340632f722c9dbce16  kwc8632.sys
 f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
 1e4fd656603fd09171d9d85631e77045  kwc28632.sys
 b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
 e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

 ...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for
 the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't
 know much about 586+ arch's but can use the instructions in special
 situations.  And this makes sense when you consider when Watcom fell out of
 favor commercially and probably saw it's last real optimizer work.


 Kernels without FAT32:

 086: 64158 bytes
 186: 63028 bytes (286 same)
 386: 62164 bytes
 486: 62068 bytes (586 and 686 same)

 Kernels with FAT32:

 086: 68358 bytes
 186: 67180 bytes (286 same)
 386: 66044 bytes
 486: 65948 bytes (586 and 686 same)

 [SNIP]

  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
 in the kernel now and possibly the string functions.  But just an idea
 right now.

 -L

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel