Re: [Freedos-devel] Package survey

[Antony Gordon]

 Hi,

I always thought it would be a good idea to model the FreeDOS install after
the MS-DOS 6.x or IBM Personal Computer DOS 6.x (or 7.x) and include the
actual core components of DOS. All the other stuff should be extra so a
fresh FreeDOS install would look exactly like what MS-DOS 6.x looked like
after installation. If you're using a ZIP file, that core install could be
unzipped to the :\DOS or :\FDOS.

-Tony

On Sun, Dec 13, 2020 at 4:22 PM Jerome Shidel  wrote:

> Hi all,
>
> Had a good time on the FreeDOS conference call. :-)
>
> We did spend a while going over some of the  current Survey statistic and
> some interesting trends.
>
> I just made a couple minor tweaks to it.
>
> Mostly, you can easily see the size of each package without hopping out to
> my repo.
>
> Obviously, no permanent decisions have been made regarding any packages.
>
> So, please. If you haven’t done so already, jump over to
> https://fd.lod.bz/survey and make your opinion known.
>
> Thanks again,
>
> Jerome
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Application to check DOS API compatibility

[Antony Gordon]

Hi,

There are some “unofficial” tests for genuine MS-DOS that can be used (within 
reason) to establish a “level” playing field for DOS. Microsoft used these 
methods as a part of the AARD code hidden in the Windows 3.1x startup program.

Undocumented DOS discusses the AARD code somewhat in detail. Generally 
speaking, the DOS API does experience some changes over it’s lifetime from 
about 2.0 until 6.22 although I believe after 5.0 it remained mostly unchanged.

-T

> On Jun 2, 2019, at 11:36 PM, Mercury Thirteen via Freedos-devel 
>  wrote:
> 
> Darn. I was hoping that, in light of the early MS-DOS clone market, there was 
> something maybe released by a third party to help users determine if their 
> DOS was MS-DOSsy enough. A reach, I know, but... oh, well. If I end up making 
> one, I'll certainly share! :)
> 
> Night is coming along well so far, and I'm trying my best to minimize 
> slipping the development schedule. Hopefully we'll be on track next year to 
> start test-running the first small .COM executables before later moving on to 
> EXE and even ELF binaries. 
> 
> 
> Sent with ProtonMail  Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Saturday, June 1, 2019 3:18 PM, Jim Hall  wrote:
> 
>> Not that I'm aware of. Such a thing has never really been needed, since 
>> MS-DOS was always the gold standard, and Microsoft set the goalposts for 
>> most of DOS history. A "compatibility check" tool would have had to come out 
>> of Microsoft, but I can't see they would have been motivated to create a 
>> product to help others create competing DOS implementations.
>> 
>> Would be neat, though. If you write a tool to do this, please share it. You 
>> can use the RBIL as the basis for DOS interrupts.
>> 
>> I assume the NightDOS kernel is doing well, then? 
>> https://groups.google.com/forum/#!topic/night-dos-kernel/PaPrNIvVWyo 
>> 
>> 
>> 
>> 
>> On Sat, Jun 1, 2019 at 2:08 PM Mercury Thirteen via Freedos-devel 
>> > > wrote:
>> Hello all,
>> 
>> Ultimately, I'm looking for an application which can probe the DOS function 
>> calls on a given system and report how "compatible" the current system is, 
>> perhaps presenting a list of what DOS functions have successfully returned 
>> legitimate output. E.g. "Your DOS implementation supports interrupt 
>> functions X and Y but not Z."
>> 
>> I understand that in reality there may be no application which does exactly 
>> this... but perhaps in all of the collective knowledge here someone knows of 
>> a program to do something close? Thanks in advance!
>> 
>> 
>> Sent with ProtonMail  Secure Email.
>> 
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel 
>> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Freedos-devel] C/C++ Compilers

[Antony Gordon]

Hi,

I’m still working on these compilers, Jim and I talked about another one that 
I’m playing with now, we’ll see what happens. 

Once I figure that part out, then I can work on the libraries…

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

Re: [Freedos-devel] FreeDOS Branded C/C++ Toolchain

[Antony Gordon]

Hi,

I did a build of OW 2.0 (it was rebranded) but nothing else was changed at this 
point. It turns out the best way to build it was on Windows. I tried Linux and 
failed and the path was too deep for MS-DOS to be used for building.

> On Jan 18, 2018, at 1:18 AM, Rugxulo <rugx...@gmail.com> wrote:
> 
> Hi,
> 
> On Wed, Jan 17, 2018 at 11:11 PM, Antony Gordon <cuzint...@gmail.com> wrote:
>> 
>> AFAIK no one on this project is interested in building a C compiler from 
>> scratch for
>> the purposes of developing FreeDOS.
> 
> Nobody's directly working on such, AFAIK, unless you count SmallerC
> (which is not DOS nor FreeDOS exclusive but does partially support
> it).
> 
>> DJGPP can’t reliably generate code for all the DOS modes which rules it out, 
>> MSC and the Borland compilers.
> 
> FreePascal's i8086-msdos can target all models, but that's TP and
> Delphi, not ISO C nor POSIX.
> 
>> The only 2 compilers that could possibly be customized would be Bruce’s C 
>> compiler
>> which I hear is missing some things and OpenWatcom.
> 
> DeSmet C or SmallerC both work, but they don't support all models. And
> the latter is always 386+ (which isn't that big a deal at this late
> date).
> 
> Actually, I think SmallerC is quite good, and I still want to make an
> official package one of these days.
> 
>> I guess it was/is a stupid idea anyway so there’s no real need to discuss it 
>> further.
> 
> The idea to have a slim or DOS-only build isn't stupid. But I guess
> most people don't have the motivation. I find it vaguely interesting,
> but even I would be overwhelmed trying to rebuild OpenWatcom. I still
> haven't tried the latest 2.0-pre builds:
> 
> https://sourceforge.net/projects/openwatcom/files/open-watcom-2.0-2017-11-01/
> 
> ("open-watcom-2_0-c-dos.exe" is 107.7 MB, presumably .ZIP sfx compressed 
> again.)
> 
> IIRC, the full OW 1.9 DOS install (only for DOS targets) was "only"
> like 45 MB or so.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Branded C/C++ Toolchain

[Antony Gordon]

Hi,

AFAIK no one on this project is interested in building a C compiler from 
scratch for 
the purposes of developing FreeDOS. DJGPP can’t reliably generate code for all 
the 
DOS modes which rules it out, MSC and the Borland compilers. Pacific C is free 
but 
we only have access to the binary build and I doubt we can make changes to the 
distribution (maybe we can).

The only 2 compilers that could possibly be customized would be Bruce’s C 
compiler
which I hear is missing some things and OpenWatcom. The OW modification with
the name change, in my mind was to identify a heavily customized build of OW 
that
while it maintains compatibility with the original source, things that we don’t 
need for 
FreeDOS development can be stripped out (to make a smaller package) and other 
customizations for the things we actually do use.

Think of it like Ubuntu. What is Ubuntu if you really think about it? Debian 
customized
with the things (mostly) that you have to optionally include from unstable and 
custom
repositories. 

If the name is a sticking point, we can leave it as OW, but it should be clear 
that 
the OS/2, Win32 support, Win64 support (in 2.0), Linux (2.0), and perhaps the 
Netware
things would be removed. It would contain everything else PLUS all the common 
libraries needed to build FreeDOS applications and tools. 

I guess it was/is a stupid idea anyway so there’s no real need to discuss it 
further.

-Tony

> On Jan 17, 2018, at 12:07 PM, Tom Ehlert  wrote:
> 
> 
> 
>> The OpenWatcom toolchain is the reference compiler for
>> FreeDOS.
> when I started with FreeDOS, MSC 6.x was the recommended compiler to
> use for FreeDOS. later this became TurboC (because it was free), then
> Watcom C (because it's free and open), and in not so far future people
> will be asking for GCC to be the reference compiler (because its even
> more free). naming them all 'freedos C++' is not such a good idea.
> 
> 
> 
>> I appreciate the effort, but I'm not sure I like the optics of
>> re-branding another project's work as "FreeDOS." That will seem like
>> we're trying to grab someone else's stuff and claim it as our own -
>> which we're not.
> 
> +1
> 
> Tom
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Branded C/C++ Toolchain

[Antony Gordon]

Hi,

I’m going to address all the emails at once instead of replying to multiple 
emails so it will be pretty easy to follow (I think). 

Jerome, it initially looks like that because I haven’t had the time to devote 
to fully building this idea out. Also, due to the amount of things involved in 
simply building OpenWatcom, i wanted to make sure it would compile and work 
before I did anything else major.

Jim and Steve, some of the reasons I am wanted to build a custom compiler 
toolchain based on OpenWatcom (kind of like what Microsoft did with Lattice C 
in 1983) is

The OpenWatcom toolchain is the reference compiler for FreeDOS.
Since the source is freely available with a license as such (instead of some of 
the abandoned but freely available compilers) it can be specifically customized 
for FreeDOS
Once completely built, all of the custom libraries that have been developed (or 
modified) for use with FreeDOS can be included with it, thereby making a 
customized toolchain.

 In the customized toolchain, all the non FreeDOS/DOS related stuff (Linux, 
Win32, Win64, and OS/2) would be removed. The OpenWatcom project MAY be 
interested in the custom libraries that we include specifically for FreeDOS 
development, and if so, I’d gladly send them over for inclusion, but I think 
the design goals of the OW project are different (at least for the C portion) 
which is making it compliant with the newer C/C++ standards and perhaps the 
Win32 and Win64 stuff.  

FreeDOS doesn’t have to be in the name, but I think having it there will 
signify while this is OpenWatcom, it will be a customized version tailored 
specifically for FreeDOS. 

-Tony

> On Jan 14, 2018, at 6:21 PM, Steve Nickolas  wrote:
> 
> On Sun, 14 Jan 2018, Jim Hall wrote:
> 
>> Hi Tony
>> 
>> I appreciate the effort, but I'm not sure I like the optics of
>> re-branding another project's work as "FreeDOS." That will seem like
>> we're trying to grab someone else's stuff and claim it as our own -
>> which we're not.
> 
> QFT.
> 
> Personal opinion: A "FreeDOS C" toolchain should really, IMO, if it should 
> even exist, be a scratch one, not a rebadging of another toolchain.
> 
> -uso.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] FreeDOS Branded C/C++ Toolchain

[Antony Gordon]

Hi all and Happy New Year,

I sent a screen shot, not knowing that there was a size limit on the emails, so 
I’m resending as a text only message.

I have been working on a project for FreeDOS for well over year and I think 
it’s about ready for prime time. I thought it would be cool if there was a 
FreeDOS branded toolchain, so I worked on the OpenWatcom code and re-branded it 
to FreeDOS. It still has all of the OpenWatcom copyright information, here’s an 
example from the WASM assembler.

[Output from WASM]
FreeDOS Assembler Version 2.0 beta Jan 13 2018 21:40:47 (32-bit)
Copyright (c) 2002-2017 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.

[Output from WCL]
FreeDOS C/C++ x86 16-bit Compile and Link Utility
Version 2.0 beta Jan 13 2018 22:29:44 (16-bit)
Copyright (c) 2002-2017 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.

The cool thing is that both the Watcom and FreeDOS toolchain can co-exist (as 
long as you set your paths properly. I am going to install it in FreeDOS and 
look for some code to compile in FreeDOS to see if it will work, especially 
since this is 2.0 and not the 1.x branch.

If anyone else would like to take it for a spin, let me know.

-Tony


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

Re: [Freedos-devel] Booting other O/Ses from FreeDOS

[Antony Gordon]

Try Loadlin with no memory managers installed.


> On Dec 29, 2016, at 11:49 PM, Ralf Quint  wrote:
> 
> On 12/29/2016 4:00 PM, Jose Antonio Senna wrote:
>> So no, it's not reasonable to expect FreeDOS to work under a
>>> running  Win95. It may be possible in theory (if someone
>>> fixed the bugs), but nobody has done it (yet, AFAIK).
>>   I did not say Win95, I said Win98SE, and I did not try to
>>  run FreeDos under Windows; I tried to start  Windows from
>>  FreeDOS.  This said,  I did not expect that to work, I just
>>  noted what did happen.
> NO version of Windows will start from FreeDOS, not 3.x nor any 9x...
>> 
>>> Dunno, try Gujin (DOS version) instead, it should work
>>> (although I likely only tried like once several years ago):
>>   The point was not how to boot Linux, it was to show another
>>  difference in behaviour between FreeDOS and MSDOS 7.
> There is no MS-DOS 7, despite what people are trying to tell. That "Boot 
> part" if Windows 9x will identify itself as DOS version 7, but never was 
> a standalone version of DOS. The last standalone version of MS-DOS was 
> 6.22 and that is as far as FreeDOS can reasonably take it...
>>  However, it would be nice if loadlin worked under FreeDOS.
> Have you tried to contact the maintainer of loadlin about this?
> 
> Ralf
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

[Freedos-devel] FDISK 1.3.1

[Antony Gordon]

Hi,

FDISK 1.3.1 won’t run in the following VMs for me at least

* VirtualBox 5.1.8-11374
* VMWare Fusion 7.0.0

I did get it to run under Parallels 11.0.

This leaves me confused as to what is going on here.

Brian is busy, I guess, so I haven’t talked with him in a while. If someone 
would like to help me out, please reach out.

Thanks,

-Tony


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

Re: [Freedos-devel] 1.2-RC1 Fdisk still does not write a valid mbr

[Antony Gordon]

Hi,

I think Brian got too busy, I still haven't figured out what causes 1.3.1
to break. I have reached out and even provided him with a copy of my VM as
maybe I'm missing something. The CATS portion works now, but I haven't
resolved my other error.

Regards,

T

On Sat, Nov 5, 2016, 11:32 PM Paul Dufresne  wrote:

> Oh! My mistake.
> I was trying to reboot on the installed disk, rather than reboot on
> installation disk:
> was passing -boot c rather -boot d again.
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
-- 

Clumsily typed on a mobile device
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Getting ready for FreeDOS 1.2

[Antony Gordon]

Hi,

Host OS should not matter. If the "gold standard" of MS-DOS works in that
configuration with the disk images, there is definitely something that
isn't right in this release. For those having a problem, what happens in
FreeDOS 1.1.

Tony

On Sat, Oct 22, 2016, 12:10 PM Jerome E. Shidel Jr. 
wrote:

> Hello Juan,
>
> > On Oct 22, 2016, at 7:55 AM, Juan Manuel Guerrero 
> wrote:
> >
> > OFYI: I have tried to format a floppy image with a VMware Player 5.0.2
> using
> > FreeDOS 1.2-pre23 and I have observed the same issue as described for
> VirtualBox.
>
> The FreeDOS 1.2 preview releases are built under FreeDOS 1.2 build
> environment (BE),
> The BE is running under VirtualBox and contains 2 floppy drive images and
> 3 hard disk
> drive images. The USB and CD releases of 1.2 contain a utility FDIDEV.BAT
> that
> will convert a (virtual) machine into a FreeDOS BE. Each preview release
> is built
> automatically using the mkFDI.bat utility that is installed and part of
> the BE. During the
> build process performed by mkFDI, this utility reformats both Floppy
> images and two
> of the hard disk images. It does this to zero out unused portions for
> better disk
> image compression at release time. I have seen no issues formatting any of
> these
> images from FreeDOS inside VirtualBox. Earlier builds (like preview 10 and
> earlier)
> were running inside VMware Fusion. But, VirtualBox performed the build
> many times
> faster. I saw no issues under VMware Fusion either.
>
> Now, just as a quick verification, I duplicated a 1.44 floppy image and
> booted a test
> install of Preview 23 inside VirtualBox 5.0.28. Format reported no
> problems with
> any of the various methods I used to reformat that floppy image.
>
> Other than the errors you are getting towards the end. I see only line
> that differs
> in my debug log.
>
> [DEBUG]  Sector buffer at 0E17:6770, track buffer at 0E17:6B70
>
> This is probably just due to the difference in the virtual machine BIOS.
> Or,
> possibly the booted configuration.
>
> > [..]
> > [DEBUG]  Sector buffer at 1A3F:6770, track buffer at 1A3F:6B70
> > [..]
> > [DEBUG]  FAT Sectors: 1 to 18 ->
> >   0% +**Drive_IO(WRITE 1, count 1 ) [FAT12/16] [drive A*]
> >
> >  Critical error during DOS disk access
> >  DOS driver error (hex): 01
> >Description: unknown unit for driver
> >  Program terminated.
> > [DEBUG]  DOS 7+, UNLOCKing drive (by one level)
> > [DEBUG]  DOS 7+, UNLOCKing drive (by one level)
>
> Just as verification, I have a couple simple questions that you have
> probably already checked.
>
> What host OS are you using?
>
> If you booted the CD under VMware and installed FreeDOS, are you still
> booting the
> El Torito CD?
>
> Are you running the latest Version of VirtualBox (5.0.28)?
>
> Have you made major changes from the default VirtualBox settings?
>
> Have you modified the boot configuration of FreeDOS and is something
> conflicting?
>
> Are you sure the actual floppy image is a valid size, exists and is
> writable by the host OS?
> (maybe download the FD12FLOPPY.zip and try formatting it’s image)
>
> Jerome
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
-- 

Clumsily typed on a mobile device
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] making himemx and jemmex more foolproof on old bios versions

[Antony Gordon]

Hi,

I think at this point a comparison should be done with Microsoft's version
on this machine to see if any differences can be detected. Also, I would
run Microsoft's OS in the emulator to see

On Wed, Jul 20, 2016, 3:34 PM Maarten Vermeulen  wrote:

> I looked at int 15h lately, int 15h is not supported on older BIOS
> versions but every BIOS has it in the time called now. :)
>
> Error code 86h means "function not supported" and if you get 80h it means
> "invalid command"
>
>
>
>
> Op woensdag 20 juli 2016 heeft Eric Auer  het
> volgende geschreven:
> >
> > Hi experts,
> >
> > some interesting observations about an old 486 PC in the thread
> > with Dimitris about "Which freedos on 486" on freedos-user...
> >
> > His BIOS answers with AH=86h, carry=UNCHANGED to int 15.e801,
> > also leaving AL unchanged. So it seems to be a good idea to
> > STC before INT 15 when doing the 15.e801 call :-) Note that
> > AH=86 is a common failure code for int 15 functions. I would
> > also suggest to, in addition, treat AH=UNCHANGED as failure.
> >
> > Another issue is that RBIL says for this call that if AX=BX=0,
> > one should use CX and DX as memory size info instead. However,
> > DOSEMU only sets AX and BX and returns CX=DX=0 while FreeDOS
> > HIMEMX and JEMMEX both look ONLY at CX and DX, without even
> > checking for AX and BX! Luckily DOSEMU also supports the two
> > other int 15 calls for memory info afair, but it seems tricky
> > that DOSEMU and FreeDOS disagree about 15.e801, no?
> >
> > Also, it is interesting that the FreeDOS drivers say that if
> > CX is not 3c00 (the max value) then DX must be treated as 0.
> >
> > This sounds like "memory hole below 16 MB means end of RAM"?
> >
> > Finally, JEMMEX and HIMEMX both say "if CX plus scaled DX < 64
> > then fall back to 15.88", which is a somewhat weird way to say
> > "if CX and DX are both 0".
> >
> > RBIL writes about int 15.88 versus the carry flag:
> >
> >> the standard BIOS only returns memory between 1MB and 16MB; use AH=C7h
> >> for memory beyond 16MB
> >
> >> not all BIOSes correctly return the carry flag, making this call
> >> unreliable unless one first checks whether it is supported through
> >> a mechanism other than calling the function and testing CF
> >
> > Interestingly, JEMMEX and HIMEMX decide to trust int 15.88
> > even if it leaves carry unchanged: They CLC before int 15.
> >
> > I think it would be a good idea to check if AH=80, 86 or 88
> > after the int 15 call even if carry is not set, as all those
> > values would be possible return values if int 15.88 failed.
> >
> > What is confusing: JEMMEX works on the mentioned 486, while
> > HIMEMX does not work, not even with /NOABOVE16 and /X, why?
> >
> > Regards, Eric
> >
> > PS: In theory, int 15.c7 would also be a possible call to get
> > info about memory beyond the first 16 MB without 15.e??? BIOS
> > support, but that would only help for a very specific group
> > of PS/2 machines identified by int 15.c0 - not very useful.
> >
> > PPS: The same PC also fails to boot from FAT32 with any SYS
> > newer than 2.6, so SYS apparently sees LBA support while it
> > does not really boot later? See freedos-user, still ongoing.
> > Unclear regarding SYS 3.6e /FORCE:LBA and /FORCE:CHS options.
> >
> >
> >
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> > reports.http://sdm.link/zohodev2dev
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
> --
> Project founder and developer of BirdOS by FeatherCode
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed 

Re: [Freedos-devel] Fwd: I'd like an absolute minimal version of FreeDOS.

[Antony Gordon]

Most of you missed the point on this.

Here's the clearer version, based upon me reading (and re-reading several
times). As a matter of fact, I'll use an example.

Install any version of MS/PC-DOS prior to 6.0 on a computer. It boots up,
tells you that you are running that particular version of DOS and gives you
a command prompt (until you start customizing CONFIG.SYS and AUTOEXEC.BAT).
DOS 6.0+ automatically detects that it can toss in HIMEM.SYS and typically
does so. What it does not do (that FreeDOS does) is run through the
copyright, the GPL license, and that it's based on a project started by Pat
Villani and mentioning DOS-C and such. Not minimizing the importance, but
that doesn't need to appear on the splash screen for MS-DOS. That
information can be in a text file.

On Wed, Jun 15, 2016 at 8:57 PM Jayden Charbonneau 
wrote:

> ​Time to program with the delete key then. (Pun)​
>
> On Wed, Jun 15, 2016 at 8:13 PM, Mercury Thirteen  > wrote:
>
>> Yep, the bootloader and a FreeDOS kernel with the boot message removed.
>> Problem solved. :)
>>
>> On 6/15/2016 6:57 PM, Jayden Charbonneau wrote:
>>
>> I may be wrong on this,but couldn't we just strip down the code used for
>> FreeDOS?Removing un-needed modules,drivers,and removing any COUT/PRINTF
>> statements to the point where it's just the kernel itself should do it.
>>
>> On Wed, Jun 15, 2016 at 4:25 AM, Maarten Vermeulen <
>> netraa...@gmail.com> wrote:
>>
>>> I think that can be done right? If we are finished with 1.2, then we (or
>>> some of us) can make it. Unless, nobody wants to do such thing. So, yeah I
>>> am volunteering. but it still needs an under layer right (for running
>>> programs)?
>>>
>>> Maarten
>>>
>>> --
>>>
>>> 2016-06-15 9:23 GMT+02:00 Eric Auer < 
>>> e.a...@jpberlin.de>:
>>>

 >From Ben Hutchinson < benh...@gmail.com>

 By minimal, I mean that the boot sector program, and the kernel
 (kernel.sys), don't do any displaying of text. All they need to do is
 set up the DOS interrupt vectors (so that they behave correctly just as
 with MS-DOS), and then load and execute the first file, command.com. No
 displaying text at all. The screen should remain blank until something
 in command.com causes text or graphics to display. Such an absolute
 minimal version of FreeDOS would be useful for me, because it would
 allow me to write my own program in assembly language, call it
 command.com, and then copy that file to the disk, and use it to boot
 another computer directly into the software I've written. This minimal
 version of FreeDOS would be just a boot-loader for my own OS-level
 software, a launch-point for my application (my application existing in
 place of an OS, rather than being run from an OS), that would then run
 upon booting.


>>> Project founder and developer of BirdOS by FeatherCode
>>>
>>>
>>>
>>> --
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols
>>> are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning
>>> reports.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>>
>>
>>
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity 
>> planning
>> reports. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
>>
>>
>>
>> ___
>> Freedos-devel mailing 
>> listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>> --
>> *This has been a Mercury Thirteen transmission.*
>> *"Why? Because FreeDOS, that's why."*
>>
>> Endorsements: AMD, ATI, BirdOS, eBid.net - A great eBay replacement which
>> doesn't habitually screw over its sellers, FreeDOS, Motorola - Maker of the
>> legendary 68K instruction sets architecture, MSI, Night DOS Kernel,
>> Samsung, Subaru - The most capable AWD ever!, Trump 2016 - Make America
>> great again!
>> I promote these things because awesomeness and excellence deserve
>> recognition, not for personal gain of any kind.
>>
>>
>> 

[Freedos-devel] FreeDOS Packaging

[Antony Gordon]

Hi,

Are source files going to still be packaged with the binary file in
FreeDOS, or will the source code be a separate optional install?

Granted, the whole core OS (what actually comprises DOS) isn't that big,
roughly 4.32MB before the other stuff (3rd party editors, a wide assortment
of GUI, development tools, and the like), so it's probably not much of a
difference, but if an end user has no plans of rebuilding from source, why
put it on their hard drive in the first place?

-Tony
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDISK Update

[Antony Gordon]

Hi,

There hasn’t been an update to FDISK yet that I have released because I am 
working with Brian to get CATS into 1.3.1.

You can still use what is presently on iBiblio. I will send out something once 
the update is done.

-Tony

> On Feb 5, 2016, at 10:06 AM, Paul Dufresne <dufres...@gmail.com> wrote:
> 
> I am a bit confused as to what is/should be the current version.
> 
> Antony Gordon said he made modifications to v. 1.2.1 and 1.3 but I
> don't know if the changes have been published and if so where.
> 
> Then there is (same code, two different categories):
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/spfdisk
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/fdisk/spfdisk/
> Is that linked to 1.2.1 version that I have in 'fdi-setup' USB image preview?
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Japheth's HX SRC files

[Antony Gordon]

Hi,

I dug into the wayback machine and grabbed what I could from Japheth's
site. I'm working on dumping it into a Git repository so that it remains
accessible.

So far, HXSRC is up at https://github.com/cuzintone/HXSRC. I am working on
JWASM and JWLINK as well and any additional code that I see on the site.

-T
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Japheth's HX SRC files

[Antony Gordon]

I'm not contributing code, just archiving bits and pieces from the old site.

If there are updated sites and sources, they should probably be mentioned
in this group as well as comp.os.msdos.programmer, as most people believe
that there is no activity and the HXDOS extended is, much like Japheth's
site, defunct.

-T

I have no problems directing to your repository.
On Feb 1, 2016 9:51 AM, "Антон Кочков" <anton.koch...@gmail.com> wrote:

> Hi!
> Please, consider contributing to this https://github.com/JWasm instead
> of setting up a new version of JWasm.
> We've added a few improvements and migrated issues as well.
> It does have AppVeyor and Travis-CI connected, as like as Coverity.
> Best regards,
> Anton Kochkov.
>
>
> On Mon, Feb 1, 2016 at 5:18 PM, Antony Gordon <cuzint...@gmail.com> wrote:
> > Hi,
> >
> > I dug into the wayback machine and grabbed what I could from Japheth's
> site.
> > I'm working on dumping it into a Git repository so that it remains
> > accessible.
> >
> > So far, HXSRC is up at https://github.com/cuzintone/HXSRC. I am working
> on
> > JWASM and JWLINK as well and any additional code that I see on the site.
> >
> > -T
> >
> >
> --
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI and FreeDOS 1.2

[Antony Gordon]

Things would be so much simpler if FreeDOS emulated the Microsoft and IBM
(and Caldera, Digital Research) counterparts and installed the base
operating system.

All these extra drivers for this, a compiler for that can just be on the CD
and can be installed later.

Jerome, if you could find a copy of DOS 5 or later just to see how the
install goes, actually I think a lot of you all need to revisit what the
default install of DOS gives you.

It would make things a lot more compatible across the myriad of platforms
(both virtual and real hardware).

Anyone using DOS at this point doesn't need their hand held with regard to
configuration.

On Sat, Jan 23, 2016, 7:31 PM Ralf Quint  wrote:

> On 1/23/2016 3:45 PM, Rugxulo wrote:
> > Hi again, quick reply,
> >
> > On Sat, Jan 23, 2016 at 5:43 PM, Rugxulo  wrote:
> >> On Sat, Jan 23, 2016 at 12:44 PM, Ralf Quint 
> wrote:
> >>> On 1/22/2016 3:36 PM, Eric Auer wrote:
> >>> BWBasic is an interpreter, which runs very well on FreeDOS, despite
> some
> >>> shortcomings, hence should be very well kept within ant FreeDOS
> "distro"...
> >> IMO, it was too buggy to use for much.
> >
> Well, fix it. It's Open Source
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI and FreeDOS 1.2

[Antony Gordon]

Hi,

Exactly. If you want networking, install it afterwards. The same for sound,
the myriad of development choices and memory managers. Despite wanting to
emulate DOS, it seems FreeDOS more closely emulates a Linux distribution
from the verbose initial boot to the "package" selection.

On Tue, Jan 26, 2016, 6:33 AM Mateusz Viste <mate...@viste.fr> wrote:

> On 26/01/2016 12:10, Antony Gordon wrote:
> > Things would be so much simpler if FreeDOS emulated the Microsoft and
> > IBM (and Caldera, Digital Research) counterparts and installed the base
> > operating system.
>
> I second that. But it would seem we are isolated in this opinion, since
> I see all the time people talking about multiple-choice packages,
> "advanced" modes, "FULL 400M+ install", etc...
>
> What I'd love, as a user, is to be able to put the FreeDOS install CD
> (or floppy) into my computer, select a single choice "Yes, I want to
> install FreeDOS even though it means all existing data will be wiped
> out", and get a FreeDOS shell seconds later. A shell that mimicks what
> MS-DOS 6.x provided. And only THEN, if I wish/need, I'd install
> additional stuff using FDNPKG and/or FDINST.
>
> Mateusz
>
>
>
>
> > On Sat, Jan 23, 2016, 7:31 PM Ralf Quint <freedos...@gmail.com
> > <mailto:freedos...@gmail.com>> wrote:
> >
> > On 1/23/2016 3:45 PM, Rugxulo wrote:
> >  > Hi again, quick reply,
> >  >
> >  > On Sat, Jan 23, 2016 at 5:43 PM, Rugxulo <rugx...@gmail.com
> > <mailto:rugx...@gmail.com>> wrote:
> >  >> On Sat, Jan 23, 2016 at 12:44 PM, Ralf Quint
> > <freedos...@gmail.com <mailto:freedos...@gmail.com>> wrote:
> >  >>> On 1/22/2016 3:36 PM, Eric Auer wrote:
> >  >>> BWBasic is an interpreter, which runs very well on FreeDOS,
> > despite some
> >  >>> shortcomings, hence should be very well kept within ant FreeDOS
> > "distro"...
> >  >> IMO, it was too buggy to use for much.
> >  >
> > Well, fix it. It's Open Source
> >
> > Ralf
> >
>
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI and FreeDOS 1.2

[Antony Gordon]

Hi,

For Maarten and Mercury, look into DOS versions prior to 5.0, they included
DEBUG and (GW-)BASIC.
That would complete the DOS experience... well that and some sample BASIC
programs like GORILLA.BAS and having LINK.EXE along with EXE2BIN.

-T
On Tue, Jan 26, 2016, 4:06 PM Jerome E. Shidel Jr. 
wrote:

> At present, BASE is fairly close to the 1.1 BASE. Of course, it no longer
> includes XMGR and UIDE.
> this is the current ALL packages that are installed. Pull rdisk? Anything
> else?
>
> https://github.com/shidel/FDI/blob/master/SETTINGS/PKG_BASE.LST
>
> Please note, that FDI’s floppy boot image needs a CD/DVD driver and it is
> currently using UDVD2.
>
> These are the current additions that are installed when ALL is selected:
>
> util\v8power
>
> net\mtcp
> util\4dos
> util\doslfn
> util\fdnpkg
> util\memtest
> util\bootfix
> util\shsufdrv
> util\cwsdpmi
> archiver\zip
> archiver\unzip
>
> util\grep
> util\tee
> util\touch
> util\which
> util\pg
>
> archiver\tar
> archiver\gzip
> archiver\bz2
>
> devel\nasm
> devel\fpc
> devel\ow
>
> net\wget
> net\rsync
> net\curl
>
> Add or remove anything else?
>
> Jerome
>
>
>
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Welcome to FreeDOS n.n

[Antony Gordon]

Hi,

Why is there a welcome anyway? MS-DOS (and PC-DOS for that matter) just
booted, loaded drivers and dropped you to a command prompt. Microsoft (or
IBM) never welcomed you to anything. If you wanted a welcome, check out
that nice 3-ring binder with the DOS reference pages (I go way back to 2.1).

It seems to me (before you get to FDCONFIG.SYS and FDAUTO.BAT) that FreeDOS
feels like a Unix distro with all the diag boot stuff.

Just my quarter of a cent.

On Mon, Jan 25, 2016, 10:21 AM Rugxulo  wrote:

> Hi,
>
> On Mon, Jan 25, 2016 at 5:38 AM, Jerome E. Shidel Jr. 
> wrote:
> >
> > I was thinking of pulling the “autoexec & config loaded", "Welcome to
> FreeDOS”
> > and "type help” messages out of the AUTOEXEC.BAT file and placing them
> in a
> > %DOSDIR%\BIN\WELCOME.BAT file with the language translation files in
> > %DOSDIR%\NLS\WELCOME.%LANG%. Also, installing them via a WELCOME.ZIP
> > package. At present, FDI embeds the required stuff into a newly created
> > AUTOEXEC.BAT.
>
> Not the worst idea (although it's not very much crucial info).
>
> > 1) This would make the AUTOEXEC.BAT file a little cleaner with just a:
> >
> > if exist %DOSDIR%\BIN\WELCOME.BAT CALL %DOSDIR%\BIN\WELCOME.BAT
>
> Okay, but just for the record, there are some (very minor) problems with
> this:
>
> Having the file name and path twice is redundant, thus harder to
> change, more error-prone, etc.
>
> A better solution would be something like "for %%a in
> (%DOSDIR%\BIN\welcome.bat) do if exist %%a call %%a".
>
> Of course, just "call %DOSDIR%\BIN\welcome.bat" isn't horrible either,
> just a mild error message if not found, which is benign, so you can
> just ignore it. It's not worth overthinking minor things like this,
> they don't need error checking.
>
> > 2) Easily remove the messages with a "fdinst remove welcome” command.
>
> It's probably not even obtrusive enough to even bother "removing".
>
> > Thoughts?
>
> That's all.  :-)
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDNPKG design issues

[Antony Gordon]

Hi,

Zip is the default format right? What kind of zip library is being used?
The program should assume that networking is configured and operational and
should only have to establish connections in my opinion.

Since I'm on baby ALERT (my wife is due soon) and I'm not working as much,
I'll take a look.

No promises though

-T

On Mon, Jan 18, 2016, 5:15 PM sparky4  wrote:

> anyone?? think that a more segmented design would be better?
>
>
>
> --
> View this message in context:
> http://freedos.10956.n7.nabble.com/FDNPKG-design-issues-tp24281p24300.html
> Sent from the FreeDOS - Dev mailing list archive at Nabble.com.
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Build Tools

[Antony Gordon]

Hi,

There are a lot of libraries that are used to BUILD FreeDOS from source. If
those libraries were all together, it would make the build process easier.
I also think that it would encourage some code re-use because the library
to do (x) function is readily available to be included instead of searching
for something.

FreeDOS would then provide "extensions" to the DOS API. For example, CATS
could be the standard internationalization library. When you download the
build tools, you automatically get this library and if you need to rebuild
FDISK, it's already there (as it's a build requirement for FDISK) and if
you wish to make a new application using CATS for internationalization,
it's readily available without having to search the web or dig through
FreeDOS source to find it.

I spend 8+ hours a day programming at my job. I know how crazy it can be
building something and one team used one library to build something and
another team uses a different library, but the output of the libraries are
the same, but the call requirements are different.

Case in point. I do Java development at work and some people use Jackson
for JSON processing and others use GSON to process JSON. The resulting
output is the same, but calling the two and how classes are setup to
interface with these APIs are different.

-T

On Mon, Jan 11, 2016, 5:48 PM Rugxulo <rugx...@gmail.com> wrote:

> Hi,
>
> On Mon, Jan 11, 2016 at 1:59 PM, Antony Gordon <cuzint...@gmail.com>
> wrote:
> >
> > If a package called FreeDOS Build Tools/Headers or whatever was built,
> what are
> > the common 3rd party libraries, such as internationalization, for
> example that we
> > could include to make building (re-building) things easier?
>
> I don't know how feasible that is (at least, for explicitly 16-bit DOS
> only stuff). There are some libs (e.g. msglib, suppl, d-flat ...
> probably many more that I forgot), but they are fairly scattered, so I
> don't know if they are much (re)use outside of one or two specific
> apps.
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FDISK Update

[Antony Gordon]

Hi,

I updated FDISK 1.2.1 and made some changes so that it would compile. I
also managed to get in contact with Brian and he's helping me resolve the
issues with the 1.3 code base that I'm having with compiling it.

Hopefully soon I will have something together and I can start on the rest
of CAT implementation and transitioning from Borland compilers to
OpenWatcom.

-T
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Build Tools

[Antony Gordon]

Hi,

Just thought I'd bring this back up as I am currently working on one of the
core components to transition it from Borland to OpenWatcom.

In looking at the code, I noticed that for internationalization, the CATS
library is used. One version of the FDISK source code didn't have the
source or the library file for CATS.

So in getting back to this developer studio, it appears obvious the
previous chain that there was no real agreement on an editor. However, we
do have a general agreement on the toolset, primarily because the spec says
so, that being OpenWatcom C (or C++) and NASM.

LIke I mentioned before, the DOS API is well represented, which makes this
easy. The next task is the supporting libraries, like CATS for example.

So to take a page from Linux, FreeDOS pretty much includes OpenWatcom. It
supports the core DOS functions. If a package called FreeDOS Build
Tools/Headers or whatever was built, what are the common 3rd party
libraries, such as internationalization, for example that we could include
to make building (re-building) things easier?
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FDISK Update

[Antony Gordon]

Hi,

I haven’t quite figured out whats wrong with the 1.3 branch of FDISK, but I did 
manage to get 1.2.1 to compile. I had to do some minor code tweaks to fix some 
errors.

I also fixed the makefile so it works better with Borland/Turbo C. As I use 
GitHub, I haven’t as of yet updated my repository. I will probably update this 
code base as is, and then start a new code base and work on integrating the 
other compilers.

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

Re: [Freedos-devel] FDISK issue

[Antony Gordon]

Hi,

'default' is a keyword. I am also reworking the makefile so that hopefully
it will rebuild outside of the environment, then I'll work on OW
compatibility and maybe even Pacific C as well.

On Mon, Jan 4, 2016 at 7:01 PM Rugxulo <rugx...@gmail.com> wrote:

> Hi,
>
> On Mon, Jan 4, 2016 at 9:54 AM, Antony Gordon <cuzint...@gmail.com> wrote:
> >
> > I’m attempting to recompile FDISK and apparently you need to assemble
> bootnorm.asm
> > and booteasy.asm and I’m getting this error when assembling booteasy.asm
> >
> > booteasy.asm:260: error: invalid parameter to [default] directive
> >  This is line 260 below.
> >
> > default db  '?',' '+80h
> >
> > Any thoughts?
>
> The two .ASM files are both dated 2002. Inside BOOTEASY.ASM, it says
> "Ported to NASM by Tom Ehlert". IIRC, the last of the pre-2.x series
> of NASM (i.e. 0.98.39, without AMD64 support) was released in 2005.
> Some older tools obviously used (or even still require) older versions
> of NASM. E.g. SHSURDRV requires 0.98.39 (32-bit for more RAM) and
> won't work in newer due to incompatible macros.
>
> So, worst case scenario, just use old 0.98.39 and don't worry about it:
>
> 1).
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/
>
> 2a).
> http://sourceforge.net/projects/nasm/files/DOS%2032-bit%20binaries/0.98.39/nasm-0.98.39-djgpp.zip/download
> 2b
> <http://sourceforge.net/projects/nasm/files/DOS%2032-bit%20binaries/0.98.39/nasm-0.98.39-djgpp.zip/download2b>).
>
> http://sourceforge.net/projects/nasm/files/DOS%2016-bit%20binaries%20%28OBSOLETE%29/0.98.39/nsm09839.zip/download
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FDISK issue

[Antony Gordon]

Hi,

I’m attempting to recompile FDISK and apparently you need to assemble 
bootnorm.asm and booteasy.asm and I’m getting this error when assembling 
booteasy.asm

booteasy.asm:260: error: invalid parameter to [default] directive
 This is line 260 below.

default db  '?',' '+80h

Any thoughts?

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

Re: [Freedos-devel] fdisk translation

[Antony Gordon]

Hi,

Since I still have the Borland Compilers in my VMs, I can take over FDISK
if needed. I can try to re-work it to work with OW. Let me know a time
frame for completion so if I take it, I don't drag the project out.

-T

On Wed, Dec 23, 2015 at 8:26 PM Paul Dufresne  wrote:

> I have encountered a little bit similar problem that is not really
> one, but looks like one.
> That was with testing the new installer floppy image, with a freshly
> created disk of 100Mb, and all_cd.iso under QEMU­.
> After fdisk had created the partition, the virtual system reboot.
> After reboot, the system BIOS (SeaBIOS) was telling me it could not
> start the system because the 0x55,0xAA signature of the MBR was not
> there.
> At first I considered it an error of the FDISK, but soon realized that
> if it was "fixed" the situation would be worst, because it would try
> to boot the MBR that was invalid. And indeed, adding a partition, I
> don't expect the MBR to be touched.
> So the real problem was me not giving the boot order... I need to tell
> it to boot the floppy disk in priority...which fixed the problem.
> Now it has come to my mind that the installer could install a MBR that
> would force to boot fhe floppy, but somehow it does not feels a so
> good idea.
>
> Later, reading fdisk history, I did read that fdisk was changed not to
> install a MBR by default and modified the 0x55, 0xAA signature. Which
> seems right to me after some thinking.
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 BASE packages

[Antony Gordon]

Hi,

Given the changes in DOS since 2.X until now, Edlin and EXE2BIN should be
optional. DOS 5 replaced Edlin with EDIT and EXE2BIN wasn't included with
DOS after 3.3 or 4.01.

Which memory manager offers the most compatibility? FDXMS or HIMEMX?

-T

On Sun, Dec 20, 2015, 4:53 PM Jerome E. Shidel Jr. 
wrote:

> This is the list of the BASE Packages for the FDI installer.
>
> Please note that I switched out UIDE for UDVD2. UIDE was causing strange
> disk errors with FDINST and with FreeCOM.
>
> Remember this is the Minimalist, MS-DOS functionality only BASE for
> FreeDOS 1.2.
>
> Please let me know if I left anything out or should remove something.
>
> Also, V8Power Tools is not installed when only BASE is selected.
>
> ; Package list for BASE only installation.
>
> base\append
> base\assign
> base\attrib
> base\chkdsk
> base\choice
> base\command
> base\comp
> base\cpidos
> base\ctmouse
> base\debug
> base\defrag
> base\deltree
> base\devload
> base\diskcomp
> base\diskcopy
> base\display
> base\dosfsck
> base\edit
> base\edlin
> base\exe2bin
> base\fc
> base\fdapm
> base\fdisk
> base\find
> base\format
> base\fdxms
> base\fdxms286
> base\help
> base\jemm
> base\himemx
> base\kernel
> base\keyb
> base\keyb_lay
> base\label
> base\lbacache
> base\mem
> base\mirror
> base\mkeyb
> base\mode
> base\more
> base\move
> base\nansi
> base\nlsfunc
> base\print
> base\rdisk
> base\recover
> base\replace
> base\share
> base\shsucdx
> base\sort
> base\swsubst
> base\tree
> base\undelete
> base\unformat
> base\xcopy
> base\xmgr
> util\udvd2
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 ALL packages

[Antony Gordon]

Hi,

An assembler and a Pascal compiler. Missing BASIC and C/C++.

That would make the programming languages complete. You should probably
mention sources for all packages in the "everything" install.

Base should just reference that the sources are on the install media. IIRC,
most Linux distributions don't specifically install the source code unless
requested by the end user.

-T

On Sun, Dec 20, 2015, 4:55 PM Jerome E. Shidel Jr. 
wrote:

> This is the list of the ALL package list for the FDI installer.
>
> Please let me know if I should anything else or remove something.
>
> Also, V8Power Tools is also installed when ALL is selected.
>
> This list includes all packages in the BASE. I just did not include them
> here to
> shorten the list.
>
> ; The remaining packages are only installed when ALL is chosen.
> net\mtcp
> util\4dos
> util\doslfn
> util\fdnpkg
> util\memtest
> util\bootfix
> util\shsufdrv
> util\cwsdpmi
> archiver\zip
> archiver\unzip
>
> ; Some packages I would like to see in ALL.
> util\grep
> archiver\tar
> archiver\gzip
> archiver\bz2
> devel\nasm
> devel\fpc
> net\wget
> net\rsync
>
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI

[Antony Gordon]

Well, there is always the DOS 3.3/4.0 way of doing things - Using SELECT.COM
and REPLACE.EXE

I am willing to bet no one remembers updating DOS using REPLACE.EXE or
installing DOS 4.0(1) using SELECT.COM

-Tony

On Thu, Dec 17, 2015 at 11:33 AM Jim Hall  wrote:

> I worry that the new FreeDOS installer is becoming too complex, trying to
> do all things for every use case and every user.
>
>
> On Sat, Dec 12, 2015 at 11:49 AM, Jerome E. Shidel Jr. 
> wrote:
>
>> Tying to decide what to do about a specific upgrade situation regarding
>> package files.
>>
>> At present:
>>
>> DOSDIR is backed up.
>>
>>  All packages that are going to be installed are removed before
>> installation.
>>
>> Package data files are backed up.
>>
>> The the DOSDIR is purged.
>>
>> Package data files are restored.
>>
>> New packages are installed.
>>
>> Issue:
>>
>> Packages that have files in the DOSDIR, will lose those files.
>>
>> Solution 1: (Present behavior)
>>
>> Let the user worry about it, and let them do a remove/install of
>> those packages later.
>>
>> Solution 2:
>>
>> Also, uninstall any packages that have any files that reside in
>> the DOSDIR.
>>
>> Solution 3:
>>
>> Restore the missing files from the backup.
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2

[Antony Gordon]

Or ...

FORMAT A: /F:720

On Tue, Nov 17, 2015 at 10:51 AM Antony Gordon <cuzint...@gmail.com> wrote:

> CONFIG.SYS entry
> DEVICE=[drive:][path]DRIVER.SYS /D:0 /F:2
>
> may work
> http://www.vfrazee.com/ms-dos/6.22/help/driver.sys.htm
>
>
> On Tue, Nov 17, 2015 at 10:48 AM Antony Gordon <cuzint...@gmail.com>
> wrote:
>
>> Those are 720K floppy disks. 9 sectors/track 80 tracks double sided =
>> 737,280 bytes
>>
>> On Tue, Nov 17, 2015 at 10:15 AM JAYDEN CHARBONNEAU <
>> jcharbonnea...@cpsge.org> wrote:
>>
>>> The disks are the size of a standard floppy but they are also double
>>> sided. They are made by the company NASHUA,and the style number is MF-2DD.
>>> In general:
>>> 1.0 MB storage
>>> Double Density
>>> Double sided
>>> I hope this  helps find the problem.
>>>
>>> On Tue, Nov 17, 2015 at 9:24 AM, Steve Nickolas <usots...@buric.co>
>>> wrote:
>>>
>>>> On Tue, 17 Nov 2015, Eric Auer wrote:
>>>>
>>>> >> got my hands on a lot of unopened micro floppy disks, with a 1 MB
>>>> storage
>>>> >
>>>> > That is an unusual size for a floppy, I would say. How many inch?
>>>>
>>>> Prolly means unformatted 3.5" 720K disks, which are sold as "1 MB".
>>>>
>>>> -uso.
>>>>
>>>>
>>>> --
>>>> ___
>>>> Freedos-devel mailing list
>>>> Freedos-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>>
>>>
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2

[Antony Gordon]

CONFIG.SYS entry
DEVICE=[drive:][path]DRIVER.SYS /D:0 /F:2

may work
http://www.vfrazee.com/ms-dos/6.22/help/driver.sys.htm


On Tue, Nov 17, 2015 at 10:48 AM Antony Gordon <cuzint...@gmail.com> wrote:

> Those are 720K floppy disks. 9 sectors/track 80 tracks double sided =
> 737,280 bytes
>
> On Tue, Nov 17, 2015 at 10:15 AM JAYDEN CHARBONNEAU <
> jcharbonnea...@cpsge.org> wrote:
>
>> The disks are the size of a standard floppy but they are also double
>> sided. They are made by the company NASHUA,and the style number is MF-2DD.
>> In general:
>> 1.0 MB storage
>> Double Density
>> Double sided
>> I hope this  helps find the problem.
>>
>> On Tue, Nov 17, 2015 at 9:24 AM, Steve Nickolas <usots...@buric.co>
>> wrote:
>>
>>> On Tue, 17 Nov 2015, Eric Auer wrote:
>>>
>>> >> got my hands on a lot of unopened micro floppy disks, with a 1 MB
>>> storage
>>> >
>>> > That is an unusual size for a floppy, I would say. How many inch?
>>>
>>> Prolly means unformatted 3.5" 720K disks, which are sold as "1 MB".
>>>
>>> -uso.
>>>
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2

[Antony Gordon]

Those are 720K floppy disks. 9 sectors/track 80 tracks double sided =
737,280 bytes

On Tue, Nov 17, 2015 at 10:15 AM JAYDEN CHARBONNEAU <
jcharbonnea...@cpsge.org> wrote:

> The disks are the size of a standard floppy but they are also double
> sided. They are made by the company NASHUA,and the style number is MF-2DD.
> In general:
> 1.0 MB storage
> Double Density
> Double sided
> I hope this  helps find the problem.
>
> On Tue, Nov 17, 2015 at 9:24 AM, Steve Nickolas  wrote:
>
>> On Tue, 17 Nov 2015, Eric Auer wrote:
>>
>> >> got my hands on a lot of unopened micro floppy disks, with a 1 MB
>> storage
>> >
>> > That is an unusual size for a floppy, I would say. How many inch?
>>
>> Prolly means unformatted 3.5" 720K disks, which are sold as "1 MB".
>>
>> -uso.
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDNPKG16 port!

[Antony Gordon]

Where is the code? You probably just need some #defines

On Mon, Oct 12, 2015, 5:07 PM sparky4  wrote:

> i got the wattcp 16 version and...
>
> it is borland C ...
>
>
> crap!!
>
> so much problems!!
>
> please help!
>
> i need the makefiles to do their jobs!
>
>
>
> --
> View this message in context:
> http://freedos.10956.n7.nabble.com/FDNPKG16-port-tp23398p23604.html
> Sent from the FreeDOS - Dev mailing list archive at Nabble.com.
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

Hi,

Sometimes doing the "needful" exceeds the "requested". Jim has a vision of
what he wants, basically a batch file based simplified install. You
(Jerome) have created some very useful utilities for managing the screen
and such.

My thought was basically to incorporate your V8 tools as a part of FreeCOM
to make an "fdinstall.com" (or setup.com) which runs as a shell. The added
advantage is that the custom command shell retains the batch and
environment functionality, which can ultimately be expanded for other
install processes or even package management.

-T

On Tue, Oct 6, 2015 at 8:55 AM, Eric Auer  wrote:

>
> Hi Jerome, for clarification: I was referring to
> the specific case where your tools are used as a
> part of the install process of FreeDOS :-)
>
> In your given "pick a file and unzip" example, it
> would be possible to do alternative tricks like:
>
> VASK-PRO /F *.zip "Pick a file to unzip" "unzip $F"
>
> The proposed VASK-PRO tool would display a file picker
> (another option could select a directory picker) for
> all files called "*.zip" together with the question
> text in the next option. Once the user picks a file
> (if the user aborts, VASK-PRO just exists) then the
> command "unzip THATFILENAME" will be invoked. Voila,
> a solution without SET /P and without pipelines :-)
>
> My question was: Which variables do you set using the
> SET /P trick and is it really necessary to have them
> in environment variables? Could you use the values in
> other ways (as in the above example)? Or would it be
> sufficient to have a small RAM storage area to keep
> status of your tools? An obvious example would be the
> cursor case:
>
> VCURSORX /PUSH /SET=full
>
> could store the current cursor size in a V-specific
> RAM area and change the cursor to full block size.
>
> VCURSORX /POP /CLEAN
>
> could restore the cursor size from that RAM area (if
> none found, do nothing) and deallocate the RAM area
> as far as cursor data is concerned. Of course it is
> not necessary to make a real stack here, probably a
> single cursor size storage slot will be enough.
>
> Other variations of the same idea will apply to other
> uses of your tools for the installer. My question is:
>
> Are there installer actions which REQUIRE some SET /P
> support and if no SET /P is available, what is lost?
>
> > The only tools that will require set /p support for any usable
> functionality
> > will be vask (when I get around to making it) and vmath. There are
> advanced
> > functions in vcursor, vfdutil, vgotoxy, vmode, vstr and vchoice that can
> be
> > taken advantage of when set /p works. But, for the most part they are
> > not needed or required to accomplish most things.
> >
> > Let’s take vchoice for example. You can fairly easily have a area that
> > vchoice will use for selection. It will by default output your choice
> > as an exit code (errorlevel). No set /p required.
> >
> > However, if lets say you have displayed 20 file names, your batch file
> does not
> > know what the filenames are since you basically are just listing a
> directories
> > contents. You want the user to pick one. If you knew what the names were,
> > you could use 20 “if errorlevel n” instructions to set an environment
> variable
> > you want to pass as an archive name to the zip utility. If you use the
> /Q option
> > on vchoice that text will be sent to STDOUT. So, you could use basically
> > 1 line to achieve something that is not really possible otherwise. Just,
> > by doing “vchoice /Q | set /p ZARC=“
> >
> > But, like I said this is an advanced function and would not be needed
> most
> > of the time.
> >
> > Another example is vfdutil. You can go directly to a drive and path of a
> > filename. changing the current drive and directory by using “vfdutil
> /c/p %SOMETHING%”.
>
> You can simply change the active directory to do thisk :-) As there
> is directory stack support (PUSHD, POPD...) in FreeCOM command.com,
> things get even more convenient. Same example, without SET /P usage:
>
> pushd
> VFDUTIL /PATH /GO-THERE
> dir *.* > x:\filelist.txt
> popd
>
> Note that I explicitly store the resulting file list in X:, which in
> my example could be a small ramdisk. If the user later has to pick a
> file from that list and unzip it, the example near the beginning of
> my mail can be combined with this to do everything WITHOUT ramdisk.
>
> On the other hand, if you plan to unzip a file, you probably unzip
> it to the drive where you install DOS, so you can simply use that
> drive for temporary storage of the file list as well... :-)
>
> > vfdutil /p %SOMETHING% | set /p FPATH=“
> > dir %FPATH%\*.* >FILELIST.TXT
>
> Regarding mathematical and cursor processing: Are you sure that you
> have to do this with several tools which have to communicate using
> a memory area or environment variables? How about doing ALL steps
> for a single cursor move inside a SINGLE call to one of your tools?
>
> This could be for example: VCURSORX /GOTO 

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

If the Int 21h handler is available,  you can use INT 21 AX=3305. DL is
returned with an integer indicating the boot drive (1=A:, etc.). This works
for MS-DOS 4.0 and later. Given that FreeDOS aims for DOS 6+ compatibility
so that functionality should be there.

-T

On Mon, Oct 5, 2015 at 3:05 AM Joe Forster/STA  wrote:

> Hi guys,
>
> > set /p is a Windows NT feature of CMD.EXE. It was not available in
> > MS-DOS or Windows 9x.
>
> And even in Windows XP, it doesn't support capturing the output of a
> command. A small test batch:
> --- test.bat ---
> @echo off
> set X=
> echo Y | set /p X=
> echo %X%
> ---
> outputs:
> ---
> ECHO is off.
> ---
>
> It works only if the input comes actually from the user (standard
> input?):
> --- test.bat ---
> @echo off
> set X=
> set /p X=X?
> echo %X%
> ---
> outputs:
> ---
> X? <= enter "Y" here
> Y
> ---
>
> > Regarding finding the master environment, in order for FreeDOS to
> > maintain compatibility with MS-DOS and the all the abandoned DOS
> > software out there, FreeDOS has to implement SysVars, commonly called
> > the List of Lists. This list can?t change it?s structure because by
> > doing so, many DOS applications won?t be able to run because a lot of
> > them depend on this ?undocumented? (by Microsoft) structure.
>
> Yup, that would be very nice. I have a DOS program that can reassign
> drive letters: http://sta.c64.org/dlmanip.html which relies _heavily_ on
> these data strutures. I'm not sure if I managed to make it work under
> FreeDOS (new version is not released yet).
>
> Also, while executing config.sys (_not_ autoexec.bat yet), the (master)
> environment variable block is not pointed to anywhere. I've unable to
> finish another DOS program that would record the boot drive into an
> environment variable so that PATH can later be set in autoexec.bat to
> :\[...][;...] (where  can be A: for floppy, C:
> for hard disk etc.)
>
> Joe
> --
> KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
> Don't E-mail spam, HTML or uncompressed files! More contacts on
> homepage--
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

Hi,

set /p is a Windows NT feature of CMD.EXE. It was not available in MS-DOS or 
Windows 9x. 

I even double checked on my Win98 VM and my Win ME VM before I wrote this. 
(Don’t ask why I have those. Just don’t). I get “Syntax Error” in both Windows 
98 and Windows ME.

It was nice of whomever wrote FreeCOM to include that Windows NT command 
interpreter function. I never tested it, but did they also include Delayed 
Expansion and IF (…) ELSE (…) and stuff like %~dpn0?

If the utilities are small as you say, then building a custom FreeCOM with them 
built in would allow your programs to pass the information without necessarily 
using the environment. 

So assuming your install script always works under FreeCOM, you have guarantees 
that set /p is there. Assuming it is running under Microsoft’s COMMAND.COM 
 on MS-DOS, you won’t have set /p and your script will 
fail at stage 7.


If your installer, still using the same batch file, was spawned in a custom 
command shell, (or FreeCOM), than you can guarantee what you need will be 
there. 

Regarding finding the master environment, in order for FreeDOS to maintain 
compatibility with MS-DOS and the all the abandoned DOS software out there, 
FreeDOS has to implement SysVars, commonly called the List of Lists. This list 
can’t change it’s structure because by doing so, many DOS applications won’t be 
able to run because a lot of them depend on this “undocumented” (by Microsoft) 
structure.

I’m not trying to pick a part your program, just trying to point you to a 
hopefully better implementation. Jim wants a batch file, you have these power 
tools, why not build them into the interpreter as internal commands? You 
implement the same code minus the startup functions and you can probably create 
a “V8” area in DOS memory where the utilities communicate since they are a part 
of the command shell. 

This precludes using the environment as you can create an in memory “structure” 
that they can manipulate.


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

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

Hi,

What if you implemented V8 tools in a customized version of FreeCOM that starts 
the setup process?

The other option is to locate the master environment and write what you need 
there.
> On Oct 2, 2015, at 6:44 PM, Jerome Shidel <jer...@shidel.net> wrote:
> 
> 
> On Oct 2, 2015, at 6:26 PM, Antony Gordon <cuzint...@gmail.com 
> <mailto:cuzint...@gmail.com>> wrote:
> 
>> Hey,
>> 
>> Couldn't you use 4DOS as the command shell during the installation process?
>> 
> Unfortunately, no. 
> 
> Some of the things that need to be done require I/O redirection (pipes and 
> such) and using the output of some process to set the values of environment 
> variables. This does not work using the 4DOS shell. 
> 
> V8Power Tools work fine. However, there is no way to make any use of many of 
> their advanced features without this capability. 
> 
> For example, when using the standard command.com <http://command.com/> in 
> FreeDOS and with MS-DOS (I think 7, with XP), you can do smithing like this 
> to hide and restore the current cursor.
> 
> vcursor | set /p OldCursor=
> vcursor hide
> rem do stuff with hidden cursor
> vcursor %OldCursor%
> set OldCursor=
> 
> The cursor would be read, stored, hidden then restored to its original state. 
> 
>> On Oct 2, 2015 1:18 PM, "Jerome E. Shidel Jr." <jer...@shidel.net 
>> <mailto:jer...@shidel.net>> wrote:
>> Well, best guess. I’m 70% done with the installer.
>> 
>> Just need to port the backup creation code, the system files transfer stuff 
>> and example package/zip installer portion.
>> 
>> But, the readme on using it for the OS release is mostly done. 
>> 
>> https://github.com/shidel/FDI/blob/master/README.md 
>> <https://github.com/shidel/FDI/blob/master/README.md>
>> 
>> FreeDOS 1.2 Installer Prototype
>> 
>> This project is for creating the FreeDOS <http://freedos.org/> 1.2+ 
>> installation kit based on V8Power Tools <http://up.lod.bz/V8Power> batch 
>> file enhancement utilities.
>> 
>>  <https://github.com/shidel/FDI/blob/master/README.md#file-list>File List
>> 
>> README.md   - This file.
>> LICENSE - GNU GPL v2.
>> mkFDI.bat   - Create the Floppy installation media.
>>  
>> <https://github.com/shidel/FDI/blob/master/README.md#build-files-in-insfiles>Build
>>  files in INSFILES\
>> 
>> MKBIN.LSTList of files copyied from C:\FDOS\BIN\ to A:\FDSETUP\BIN\
>> MKHELP.LST   List of files copyied from C:\FDOS\HELP\ to A:\FDSETUP\HELP\
>> MKV8P.LSTList of files copyied from V8POWER\ to A:\FDSETUP\V8POWER\
>> MKSETUP.LST  List of files copyied from INSFILES\ to A:\FDSETUP\SETUP\
>> AUTOEXEC.BAT Copied as-is to A:\
>> FDCONFIG.SYS Copied as-is to A:\
>> SETUP.BATCopied as-is to A:\
>>  
>> <https://github.com/shidel/FDI/blob/master/README.md#what-the-installer-does>What
>>  the installer does.
>> 
>> AUTOEXEC.BAT calls SETUP.BAT RECOVERY
>> 
>> SETUP.BAT
>> 
>> Tests for presence of V8Power Tools.
>> Tests for I/O redirection support at present.
>> Does some basic settings initialization.
>> 
>> Loads configuration from STAGE000.BAT. This is where some of the
>> built-in default settings are stored. Things like New Volume Label,
>> OS Version and etc.
>> 
>> if RECOVERY option was present at launceh, tests if this version of
>> FreeDOS is already installed using STAGE001. If so, just exists to
>> prompt with a welcome message. Otherwise, proceeds with installer.
>> 
>> STAGE002, Loads current color scheme from either THEMENUL.BAT or
>> if THEMEADV.BAT (Advanced Mode).
>> 
>> STAGE003, Displays welcome to FreeDOS installer message. Offers to
>> continue or exit.
>> 
>> STAGE004, Checks if drive C exists. If not prompts user that C needs
>> partitioned and offers to run fdisk or exit. If user selects fdisk,
>> then offers to reboot or exit.
>> 
>> STAGE005, Checks if drive C is readble. If not prompts user that C
>> needs formatted and offers to format or exit. If user selects formats,
>> then rechecks if C is readble. If not, offers to reboot or exit.
>> 
>> STAGE006, Sets up temporary TEMP Directory so I/O redirection can
>> function and for storage of a couple temporary files. If I/O
>> redirection is still unavailable, it will abort the installation.
>> 
>> NOTE: Now that a TEMP directory exists,  FDIWIND.BAT and other
>> batch files 

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

Hey,

Couldn't you use 4DOS as the command shell during the installation process?
On Oct 2, 2015 1:18 PM, "Jerome E. Shidel Jr."  wrote:

> Well, best guess. I’m 70% done with the installer.
>
> Just need to port the backup creation code, the system files transfer
> stuff and example package/zip installer portion.
>
> But, the readme on using it for the OS release is mostly done.
>
> https://github.com/shidel/FDI/blob/master/README.md
>
> FreeDOS 1.2 Installer Prototype
>
> This project is for creating the FreeDOS  1.2+
> installation kit based on V8Power Tools  batch
> file enhancement utilities.
> --
> File List
>
> README.md   - This file.
> LICENSE - GNU GPL v2.
> mkFDI.bat   - Create the Floppy installation media.
>
>
> Build
> files in INSFILES\
>
> MKBIN.LSTList of files copyied from C:\FDOS\BIN\ to A:\FDSETUP\BIN\
> MKHELP.LST   List of files copyied from C:\FDOS\HELP\ to A:\FDSETUP\HELP\
> MKV8P.LSTList of files copyied from V8POWER\ to A:\FDSETUP\V8POWER\
> MKSETUP.LST  List of files copyied from INSFILES\ to A:\FDSETUP\SETUP\
> AUTOEXEC.BAT Copied as-is to A:\
> FDCONFIG.SYS Copied as-is to A:\
> SETUP.BATCopied as-is to A:\
>
>
> What
> the installer does.
>
> AUTOEXEC.BAT calls SETUP.BAT RECOVERY
>
> SETUP.BAT
>
> Tests for presence of V8Power Tools.
> Tests for I/O redirection support at present.
> Does some basic settings initialization.
>
> Loads configuration from STAGE000.BAT. This is where some of the
> built-in default settings are stored. Things like New Volume Label,
> OS Version and etc.
>
> if RECOVERY option was present at launceh, tests if this version of
> FreeDOS is already installed using STAGE001. If so, just exists to
> prompt with a welcome message. Otherwise, proceeds with installer.
>
> STAGE002, Loads current color scheme from either THEMENUL.BAT or
> if THEMEADV.BAT (Advanced Mode).
>
> STAGE003, Displays welcome to FreeDOS installer message. Offers to
> continue or exit.
>
> STAGE004, Checks if drive C exists. If not prompts user that C needs
> partitioned and offers to run fdisk or exit. If user selects fdisk,
> then offers to reboot or exit.
>
> STAGE005, Checks if drive C is readble. If not prompts user that C
> needs formatted and offers to format or exit. If user selects formats,
> then rechecks if C is readble. If not, offers to reboot or exit.
>
> STAGE006, Sets up temporary TEMP Directory so I/O redirection can
> function and for storage of a couple temporary files. If I/O
> redirection is still unavailable, it will abort the installation.
>
> NOTE: Now that a TEMP directory exists,  FDIWIND.BAT and other
> batch files that use I/O redirection for utilities like vmath can
> now be used.
>
> STAGE007, Calls all Installation configuration batch files named
> FDASK???.BAT located in the FDSETUP\SETUP directory.
>
> STAGE008, Prompts user that installation will now begin, Offers
> to continue or exit. Then, scans current FDSETUP\SETUP for all
> FDINS???.BAT files. The scans all other drives for
> \FDSETUP\SETUP\FDINS???.BAT files and calls them in that order to
> perform the installation.
>
> STAGE009, Informs user that instalation is complete offers reboot or
> exit.
>
> STAGE999, Performs cleanup and is always run. It is only not run
> if the STAGE001 test for existing OS installation passes and the
> batch script is exiting without running the installer.
>
> If user had selected reboot in STAGE009, it is done now.
>
>
> Some
> global environment variables.
>
> OS_NAME = Should always be "FreeDOS"
> OS_VERSION  = Current OS Version.
>
> FADV= "y" if running in advanced mode.
> FDIDFMT = "y" if during this execution the batch file formatted
> drive C.
> FWAIT   = If your going to use vpause, This is how many seconds you
> should pause. Example: vpause /t %FWAIT%
>
>
> Options
> configured by FDASK???.BAT files.
>
> OVOLIf drive is formatted, set its labal to this text
> (actually OVOL is set in STAGE000)
>
> OBAKSet in FDASK000. If an operating system is detected.
> and user selects backup it will be set to "y". In advanced
> mode user can select 'archive to zip' then it is set as
> "z". If no OS was detected, or uses selects no backup it
> will be 

Re: [Freedos-devel] FDI 1.2

[Antony Gordon]

For option 2, all you would need to do is execute a FreeDOS version function 
call. I don’t have the spec in front of me, however in the case of MS-DOS, and 
INT 21H/3306H and INT 21/30 returns the DOS version number.

Int 21/30 can be altered by SETVER, but INT 21/3306 should return BL as the 
major, BH as the minor. AL should be FFh if FreeDOS considers itself to be < 
MS-DOS 5.0

You may want to (in the case of someone wishing to install  FreeDOS over 
another DOS) use these functions I mentioned to determine the DOS that is 
running, i.e., DRDOS, OpenDOS, MSDOS 7.x. I’ll leave that up to your discretion.
Hopefully that helps you out a bit. 


> On Sep 30, 2015, at 10:32 AM, Jerome E. Shidel Jr.  wrote:
> 
> Did a little more restructuring. So now, the setup files make a little more 
> sense now for future updates to the installer.
> 
> So far this is what happens:
> 
>   1) boots from floppy or floppy image (like bottle CD)
> 
>   (Note: if user manually lauches installer, skip 2 and goto 3)
> 
>   2) Detects if latest FreeDOS version is installed (actual test not 
> written)
>   If it is the latest version, returns to prompt with welcome 
> message.
>   If not installer continues.
> 
>   3) Welcomes user to installer and asks if the want to continue.
>   If no, returns to prompt with install aborted message.
> 
>   4) Checks for drive C’s existence.
>   If it exists, skip to 7.
> 
>   5) Informs user they need to partition and offers to run partitioner.
>   if yes, runs fdisk.
>   If no, returns to prompt with abort message.
> 
>   6) Partitioner runs, then asked user to reboot.
>   if yes, reboots
>   If no, returns to prompt with abort message.
>   
>   7) Checks if C is formatted.
>   if yes, skip to 9.
>   
>   8) offers to format or exit to prompt.
> 
>   ——— to do ——— 
> 
>   9) Offer backup.
> 
>   10) install.
> 
> If user manually launches with "SETUP.BAT adv”, the installer will run in 
> advanced mode.
> 
> Also, at any choice box, if the User presses CTRL-C, they are provided with 
> choices to 
> either quit to DOS, go back to where they were or switch to and from Advanced 
> Mode.
> 
> 
> 
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

Hi,

So a cursory read of Wikipedia on this topic (ExFAT) and I stumbled across
this

Two experimental, unofficial solutions are available for DOS. The loadable
USBEXFAT driver requires Panasonic's USB stack for DOS and only works with
USB storage devices; the open-source EXFAT executable is an exFAT
filesystem reader, and requires the HX DOS

extender
to work.[48]  There are
no native exFAT real-mode DOS drivers, which would allow usage of, or
booting from exFAT volumes

Also Mac OS X 10.5 and later can read/write and repair exFAT, quite
possibly a solution there as well with minimal rewriting.

-T

On Sun, Sep 27, 2015 at 11:43 PM Eduardo Casino 
wrote:

> Hi Geraldo,
>
> > does freedos have any vfs-equivalent interface? which files are involved?
> > is Pat's book a valid/current reference to freedos kernel?
> > which books would you suggest me to read?
> > what is the easiest way to setup the compiler?
> >
> > i mean, should i setup a freedos vm with with openwatcom or freeware
> > version of tc
> > or do we have a way to 'cross-compile' freedos kernel on linux and use
> > the vm just to test the code?
>
> You can have a look at vmsmount sources. A lot of the generic network
> redirector code can be reused and it is written for Openwatcom. You can
> cross compile from Windows or Linux and, if you use vmware and vmsmount,
> you can share a folder with a FreeDOS vm, which will ease a lot your
> testing.
>
> http://sourceforge.net/projects/vmsmount/
>
> Good luck,
> Eduardo.
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

Hmmm,

Possibly, BUT the resultant code would still have to be brought back to FreeDOS 
on virtual or real floppy. Might as well develop in a VM under FreeDOS. 

OpenWatcom, like I mentioned earlier was too much for me, so I went back to my 
Borland tools and add defines to cover the bases.

-T

> On Sep 27, 2015, at 9:45 PM, Louis Santillan <lpsan...@gmail.com> wrote:
> 
> 
> 
> On Sunday, September 27, 2015, Antony Gordon <cuzint...@gmail.com 
> <mailto:cuzint...@gmail.com>> wrote:
> Hi,
> 
> Unfortunately, Linux doesn’t have a 16-bit C compiler (that I am aware of). 
> GCC has some fundamental differences in C dialect from OpenWatcom and Borland 
> which would require conditional defines (especially with regard to inline 
> assembly) and GCC doesn’t support 16-bit OBJ files as a target, mostly COFF 
> and ELF binaries which will not work on DOS (at least at the 8/16-bit level).
> 
> Can't openwatcom on Linux generate 16-bit dos binaries? 
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

Hi,

I don’t know too much about the innards of checking in and out code however, if 
you have the current version installed, you more than likely have the  source 
to the current kernel. 

I would advise you to go the route of MSCDEX and use the network redirector 
interface. You may want to read Chapter 8 of Undocumented DOS, 2nd edition to 
get a feel for the DOS File System and Network Redirector (assuming you have 
that book). If you don’t have that book, then Google the DOS redirector 
interface, which appeared in DOS at version 3.1

That will give you some useful tidbits and examples on understanding system 
file tables (SFT), the current directory structures (CDS), and how things like 
NETX, SHARE, and ASSIGN (for example) work.

With regard to the development environment, Jim has posted somewhere that the 
general development tools are OpenWatcom and NASM. I personally have found 
OpenWatcom a tad bit overwhelming because of all that it can do. If you are 
more familiar with the Borland C compilers, you can use those, however, I would 
STRONGLY suggest gratuitous use of conditional defines and such to make the 
code more compatible for the final OpenWatcom build.

Unfortunately, Linux doesn’t have a 16-bit C compiler (that I am aware of). GCC 
has some fundamental differences in C dialect from OpenWatcom and Borland which 
would require conditional defines (especially with regard to inline assembly) 
and GCC doesn’t support 16-bit OBJ files as a target, mostly COFF and ELF 
binaries which will not work on DOS (at least at the 8/16-bit level).

I have a VirtualBox VM with FreeDOS installed that I can zip up and throw in my 
Dropbox if you’d like.

-T
> On Sep 27, 2015, at 6:57 PM, Geraldo Netto  wrote:
> 
> Hi All,
> 
> I was talking to Eric a few days ago about this exfat thread
> and while we are worried with the license issues
> I would like to volunteer myself to port current exfat from linux
> kernel to freedos
> 
> Of course, once it's a no-trivial thing i would like to ask your support
> i cannot promise anything by now, once i know that talk is cheap as
> Mateusz and Tom reported :)
> 
> So, what do you think?
> what is the svn link to checkout the freedos kernel code?
> does freedos have any vfs-equivalent interface? which files are involved?
> is Pat's book a valid/current reference to freedos kernel?
> which books would you suggest me to read?
> what is the easiest way to setup the compiler?
> 
> i mean, should i setup a freedos vm with with openwatcom or freeware
> version of tc
> or do we have a way to 'cross-compile' freedos kernel on linux and use
> the vm just to test the code?
> 
> Suggestions are always very welcomed :P
> 
> 
> Kind Regards,
> 
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
> 
> On 25 September 2015 at 19:14, Ralf Quint  wrote:
>> On 9/24/2015 12:33 PM, Mercury Thirteen wrote:
>>> We could undercut the competition and make our own free FAT
>>> implementation which does fills the same niche as exFAT.
>>> 
>> Which will be extremely hard to do without interfering with those patents...
>> 
>> Ralf
>> 
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>> 
>> 
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FDNPKG16 port!

[Antony Gordon]

Does the TCP stack work in 16-bit? If not, you'd probably have to build it
to support loading packages from floppy disks or CDs.

On Mon, Sep 21, 2015, 3:08 PM Bruno Félix Rezende Ribeiro 
wrote:

> Hello, sparky4!
>
> Em Mon, 21 Sep 2015 08:07:17 -0700 (MST)
> sparky4  escreveu:
>
> > I am currently porting fdnpkg to 16 bit now~
>
> Thank you for this initiative!
>
>
> --
>  ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
> ((_/)o o(\_)) http://oitofelix.freeshell.org/
>  `-'(. .)`-'  irc://chat.freenode.org/oitofelix
>  \_/  xmpp:oitofe...@riseup.net
>
> GNU ccd2cue maintainer
> GNU Savannah hacker
> GNU web translation team coordinator (Brazilian Portuguese)
> GNU audio and video maintainer
> DMOZ free software editor (Portuguese)
> UFU FAMAT PET member
>
> [GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily
> match those of the GNU project.  Hereby I express my own opinion,
> style and perception, in good faith, aiming the betterment of GNU.
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI 1.2 Questions?

[Antony Gordon]

Hi,

Unlike MS-DOS proper, FreeDOS comes with custom configuration files to
optimize for different things, I have my personal opinion on this, but I
digress. Given that the user may have modified the configuration files and
there is no easy way to merge the changes of a vanilla FreeDOS config to a
custom end user config, I would suggest maintaining the users configuration
files. If there is an issue, of course they can boot, use F5 and use a
support utility to replace their configuration files with the system
default (creating backups of course)

On Wed, Sep 16, 2015 at 5:16 AM, Jerome Shidel  wrote:

>
> On Sep 15, 2015, at 9:27 PM, Mercury Thirteen 
> wrote:
>
> Could we just give the user the option?
>
>
> I could. But, Jim wants super simple. So, I guess I will have to see if he
> wants it to ask or not.
>
> But, I am really thinking purge the FDOS dir and install new config.sys
> and autoexec.bat is the best course.
>
>
> Also, you could call the backup FDOS folder *fdos.old* a'la Windows and
> its *windows.old* directory. At least that way some folks would know what
> it's for when they see it again months down the road.
>
>
> At present, it wraps all that stuff up into a zip file. And puts it under
> a dir called FDBackup. Enumerating the zip as next avail FDBAK0.zip (or 1,
> 2, 3)
>
> Easy to change to FDOS.OLD though.
>
> On 9/15/2015 8:53 PM, Jerome Shidel wrote:
>
> The installer is going well and is about 50% done. But, I have two questions.
>
> Situation:
> User is doing an upgrade install from FD1.1.
>
> FDI already prompts to backup. Then will backup config files and the c:\FDOS 
> directory.
>
> 1) should FDI purge the c:\fdos directory before it installs the new files. 
> Or, keep everything it doesn't overwrite?
>
> 2) should the installer keep the users current config files or install new 
> default ones.
>
> I see problems doing either of these, either way.
>
> The most reliable way would be to purge the c:\fdos directory and install 
> fresh config.sys and autoexec.bat files. But, that will force the user to 
> modify theirs post install. Not doing it, the system may be flakey or not 
> even boot completely.
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog 
> now!http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing 
> listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDI 1.2 Questions?

[Antony Gordon]

Hi,

I think the best solution would probably be two setup programs. A quick
setup like Jim wants and then a more advanced setup that provides all the
advanced tools, disk image creation that more technical users would want.

Simple version is the batch file, advanced version is C (or some other high
end language).

-T

On Sep 16, 2015 11:26 AM, "JAYDEN CHARBONNEAU" 
wrote:

> I prefer as many advanced options as possible.I keep a backup of my ENTIRE
> network in FreeDOS (I'm funny like that,I guess.FreeDOS can't be affected
> by windows viruses.).So if data were to be erased,I would have a mental
> breakdown (In a sarcastic sense.).So,yeah.
>
> On Wed, Sep 16, 2015 at 9:39 AM, Joe Forster/STA 
> wrote:
>
>> Hi guys,
>>
>> Unlike MS-DOS proper, FreeDOS comes with custom configuration files to
>>> optimize for different things, I have my personal opinion on this, but I
>>> digress. Given that the user may have modified the configuration files and
>>> there is no easy way to merge the changes of a vanilla FreeDOS config to a
>>> custom end user config, I would suggest maintaining the users configuration
>>> files.
>>>
>>
>> I agree; I'd really hate such a situation. Replacing configuration files
>> should be an installation option, like "reset to default/factory settings".
>> I'm not sure whether this option should be enabled or disabled by default;
>> rather disabled.
>>
>> Joe
>> --
>> KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
>> Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
>>
>> --
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 Installer Project

[Antony Gordon]

Eric, I just get ...?  LOL I guess you're not liking me again. (Just
kidding).

On Fri, Sep 11, 2015 at 10:31 AM Eric Auer  wrote:

>
> Hi Jayden (and Mateusz and Jim and...) :-)
>
> > Will we implement an "advanced" setup? [...]
>
> > The first would be the user friendly setup,and the second would allow the
> > user to manually choose packages,and even access the command line (I
> think
> > it has the prompt of X:\).This way,if the user wanted to conserve drive
> > space,or only wanted specific things installed,they could do so without
> > deleting directories AFTER installation.Just an idea,which I think would
> > make installation a bit more usable and convenient for both crowds.
>
> (PS: please do use whitespace after punctuation marks!)
>
> Of course it is good to be able to reach a prompt,
> but I would not put effort in extra magic. To let
> the user manually select packages, the user could
> do a BASE install and afterwards simply run FDNPKG
> to install more of the packages which are present
> on the CD anyway. I assume FDNPKG allows to do so
> in user friendly ways, for example selecting many
> packages first, then going for a coffee while the
> tool installs them all after you press "apply" :-)
>
> Cheers, Eric
>
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 Installer Project

[Antony Gordon]

HI,

How many of you remember the DOS 6.22 install process? If possible, it
should aim for that. It's simple and straight to the point. It worked
across all platforms and got DOS up and running with minimal fuss. Once the
setup is done, after a reboot, the FreeDOS package manager can run to add
additional software and system tweaks.

The package manager could be a 16-bit or 32-bit application. (I remember
PKZIP running perfectly fine on my Tandy 1000 EX before I had 640K RAM), so
FDPKG would have to work from a floppy disk/image on lower end systems (or
lower end in emulation)


On Thu, Sep 10, 2015 at 5:28 AM Mateusz Viste  wrote:

> On 10/09/2015 10:51, Eric Auer wrote:
> > My personal opinion is that on 8086, you should rather use a floppy
> > distro like RUFFIDEA or BREZEL which has the "base" category already
> > pre-installed on one or a few floppies and you just XCOPY that to a
> > disk of your choice manually. Imagine how many floppies and spanned
> > zip files across multiple floppies a full install on 8086 would be.
>
> I would tend to agree on that, but it's apparently not a common point of
> view. Not that long ago, I almost triggered an apocalypse on this very
> list by stating that 8086 machines probably do not need a package
> manager. I can only imagine that an installer will be perceived as even
> more fundamental.
>
> Without going into multi-floppies installations, it might be nice for
> the FreeDOS installer to be compatible with the lowest possible machine,
> if only to effectively present an intro screen, help to format the disk
> and copy the most basic stuff to C:\FREEDOS. Even on a full-blown
> Pentium PC there won't be more to do for the installer. Once the most
> basic system is up and running, then people can install any additional
> software via FDNPKG.
>
> Mateusz
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 Installer

[Antony Gordon]

Perhaps take a cue from Apple on this one.

The CD boots to an environment that can be used for recovery, diagnostics,
or an install.

For edge use cases where GPARTED would need to be used or some tweaking of
a GRUB boot loader could be performed prior to starting the install...
On Sep 10, 2015 9:46 PM, "Antony Gordon" <cuzint...@gmail.com> wrote:

> If you just want to do the EULA thing, you can put a generic, this
> contains free software based on several licenses, including GNU GPL, MIT,
> and BSD. By continuing with this install, you accept all applicable
> licenses. To view them in detail, view C:\FREEDOS\DOC.
> On Sep 10, 2015 9:34 PM, "Jerome Shidel" <jer...@shidel.net> wrote:
>
>>
>> > On Sep 10, 2015, at 9:22 PM, Jim Hall <jh...@freedos.org> wrote:
>> >
>> >> On Thu, Sep 10, 2015 at 8:05 PM, Jerome Shidel <jer...@shidel.net>
>> wrote:
>> >> [..]
>> >> I have the FDI 1.2 prototype installer about 30% done already.
>> >
>> > Excellent!
>> >
>> >
>> >> Next up:
>> >>
>> >> Locate packages to install. No sense going any farther if they can't
>> be found.
>> >>
>> >> To display Eula. Accept or quit? (Reminds me to finish vview utility
>> in V8PT)
>> >>
>> >> Give install options:
>> >> 1 basic
>> >> 2 full (default?)
>> >> 3 basic + sources
>> >> 4 full + sources
>> >> Quit
>> >>
>> >> Do sys c:
>> >> Do install packages.
>> >>
>> >> Do we are done thanks. Quit or reboot?
>> >
>> > I don't know about displaying the EULA. There are many free software /
>> > open source licenses used in the FreeDOS distribution. The kernel and
>> > many utilities in Base are under the GNU GPL, but many other programs
>> > are under the BSD license, or MIT license, etc. I don't think you want
>> > to display all of those for an EULA.
>> >
>> > I think a simple info screen will suffice. Something like:
>> >
>> >> Welcome to FreeDOS!
>> >>
>> >> FreeDOS is a free version of DOS, an operating system that you install
>> >> on your computer. FreeDOS is made up of many smaller programs, called
>> >> utilities.
>> >>
>> >> Most of FreeDOS is distributed to you under the GNU General Public
>> >> License, a free software license that guarantees you have access to
>> >> the source code. Other parts of FreeDOS are distributed under a
>> >> similar license that includes source code.
>> >>
>> >> For details on the specific licenses used in FreeDOS, refer to the
>> >> documentation. This is usually installed in C:\FDOS\DOC
>> >
>> >
>> > But I lack the time just now to make that shorter or clearer. :-)
>> >
>>
>> Yeah, your right. There is no "one Eula to rule them all"
>> No Eula page then.
>>
>> Hummm
>> How about on welcome page? Something like:
>>
>> 1 Continue to install
>> 2 More information
>> 3 Quit
>>
>> >
>> > Jim
>> >
>> >
>> --
>> > ___
>> > Freedos-devel mailing list
>> > Freedos-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>> >
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 Installer

[Antony Gordon]

If you just want to do the EULA thing, you can put a generic, this contains
free software based on several licenses, including GNU GPL, MIT, and BSD.
By continuing with this install, you accept all applicable licenses. To
view them in detail, view C:\FREEDOS\DOC.
On Sep 10, 2015 9:34 PM, "Jerome Shidel"  wrote:

>
> > On Sep 10, 2015, at 9:22 PM, Jim Hall  wrote:
> >
> >> On Thu, Sep 10, 2015 at 8:05 PM, Jerome Shidel 
> wrote:
> >> [..]
> >> I have the FDI 1.2 prototype installer about 30% done already.
> >
> > Excellent!
> >
> >
> >> Next up:
> >>
> >> Locate packages to install. No sense going any farther if they can't be
> found.
> >>
> >> To display Eula. Accept or quit? (Reminds me to finish vview utility in
> V8PT)
> >>
> >> Give install options:
> >> 1 basic
> >> 2 full (default?)
> >> 3 basic + sources
> >> 4 full + sources
> >> Quit
> >>
> >> Do sys c:
> >> Do install packages.
> >>
> >> Do we are done thanks. Quit or reboot?
> >
> > I don't know about displaying the EULA. There are many free software /
> > open source licenses used in the FreeDOS distribution. The kernel and
> > many utilities in Base are under the GNU GPL, but many other programs
> > are under the BSD license, or MIT license, etc. I don't think you want
> > to display all of those for an EULA.
> >
> > I think a simple info screen will suffice. Something like:
> >
> >> Welcome to FreeDOS!
> >>
> >> FreeDOS is a free version of DOS, an operating system that you install
> >> on your computer. FreeDOS is made up of many smaller programs, called
> >> utilities.
> >>
> >> Most of FreeDOS is distributed to you under the GNU General Public
> >> License, a free software license that guarantees you have access to
> >> the source code. Other parts of FreeDOS are distributed under a
> >> similar license that includes source code.
> >>
> >> For details on the specific licenses used in FreeDOS, refer to the
> >> documentation. This is usually installed in C:\FDOS\DOC
> >
> >
> > But I lack the time just now to make that shorter or clearer. :-)
> >
>
> Yeah, your right. There is no "one Eula to rule them all"
> No Eula page then.
>
> Hummm
> How about on welcome page? Something like:
>
> 1 Continue to install
> 2 More information
> 3 Quit
>
> >
> > Jim
> >
> >
> --
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] mTCP/IP stack by M Brutman is now closed source

[Antony Gordon]

Wow,

This is the most activity I've seen on this list in a while, and it's a
temper tantrum of sorts over whether someone has the right to close source
or open source something they wrote.

Talk about comedy. So how are those bugs looking on the bug list in
FreeDOS?

Yeah, I probably just got myself booted from this list, but honestly I
think (sans sarcasm) that there are bigger tasks to tackle in FreeDOS than
haggling and harassing someone over closed source versus open source.

It's really not that important, but I have a simple solution, it's a grand
waste of a cd image, but FreeDOS should ship like MS-DOS and PC-DOS with
just the operating system and let everyone else work out the other software
on their own.

This will eliminate all this back and forth about open source and closed
source and can you include my program in because...if it's not a DOS
command from 1981 until 1994 (DOS 1.0 - DOS 6.22/7.0) it's not there and
you just have to download and build/install yourself.

-T
On Sep 9, 2015 7:02 PM, "Ralf Quint"  wrote:

> On 9/9/2015 4:00 PM, JAYDEN CHARBONNEAU wrote:
> > Ralf,I would ask that you take a breather.It is his program,he may do
> > whatever he wishes with it.
> >
> Well, maybe you should actually read my reply, as that is exactly what I
> am saying...
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS 1.2 Installer Project.

[Antony Gordon]

Hi,

I'm curious as to why a batch file and DOS 6 setup automatically initiated
the format once the drive was selected.

On Wed, Sep 9, 2015, 9:28 PM Jerome E. Shidel Jr.  wrote:

>
> > On Sep 9, 2015, at 8:03 PM, Eric Auer  wrote:
> >
> >
> > Hi Jerome,
> >
> > if you want to store temp results in your batch, you could
> > work with errorlevels, the FreeCOM magic errorlevel variable
> > or indeed a ramdrive. In the past, we often used "memdisk",
> > which is a BOOTABLE RAMDRIVE. That way, the installer used
> > a virtual floppy to boot. As you cannot natively boot DOS
> > from network, CD, DVD or BluRay, you have to use a virtual
> > boot disk for those anyway. Memdisk gives you the advantage
> > that the virtual boot disk is a writeable ramdrive floppy.
>
> Most of how the FDI prototype passes data around with errorlevel
> processing.
>
> However, not having a functioning pipe will make some of the more advanced
> features of V8PT unusable in the installer.
>
> example: "vcursor | set /p START_CURSOR=“ would save the incoming cursor
> so when the batch exits, it can restore it to its previous state with
> “vcursor %START_CURSOR%". However, just doing a “vcursor small” will
> make the cursor visible again.
>
> (
> FYI, the default cursor for FreeDOS inside vmWare is 0x0607. Assuming you
> could actually get an errorlevel that high. Could you imagine having 1543
> if
> statements for that one?  :’-(
> )
>
> I can probably work around most or all of the issues caused by no pipe
> support.
>
> It’s just the installer won’t be quite as intelligent as it could be.
>
> At present, I’ve already added stuff to the installer batch that will
> automatically
> use the pipes if the TEMP var is set. If it is not set, it runs in dumb
> mode.
>
> This will give whoever actually makes the FD1.2 Distro Release the ability
> to either support it or not just by adding a ram disk or leaving it out.
>
> >
> > Memdisk is a bit more esotheric compared to using a floppy
> > image to directly make a CD or similar bootable, but both
> > methods work on most BIOS variants. As more and more users
> > have a BIOS which can boot from USB stick or SD cards, the
> > whole problem can be sidestepped with a bootable USB / SD.
>
> It would be nice if FD 1.2, “ships” with floppy, CD, USB and SD
> support.
>
> >
> > Disadvantage of both methods is that the files inside the
> > boot "floppy" are less visible and less editable to people
> > who want to tune the boot CD / DVD image to their needs,
> > they tend to overlook the floppy image and / or lack the
> > tools needed to edit it, although free tools are available
> > for all common operating systems :-)
>
> Yeah, they’re a pain. But, reliable.
>
> >
> > Cheers, Eric
>
> Thanks, Jerome
>
> >
> >
> >
> > PS: Why does FORMAT C: need pipes? You do not want to hide
> > messages and if you worry about confirmation requests, I
> > personally vote AGAINST automated saying yes to FORMAT C:
>
> Well, it was a suggestion/request that I mostly agree with.
> The installer asks “Do you want to format and erase this drive?”
> Just a little redundant for the formatter to ask again.
>
> > (also, our FORMAT has a command line option for that…).
>
> What is it? I don’t see one to have it format drive C without insisting on
> typing “YES”
>
> >
> >> If no writeable file system is present, DOS throws many errors
> >> and cannot redirect the data from one program to another.
> >
> > Many? Only if you try to explicitly use pipes ;-)
>
> One error message is way way way too many. :)
>
> >
> >
> >
> --
> > Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> > Get real-time metrics from all of your servers, apps and tools
> > in one place.
> > SourceForge users - Click here to start your Free Trial of Datadog now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog 

Re: [Freedos-devel] FreeDOS 1.2 package compilation

[Antony Gordon]

Perhaps it should take a cue from the MSDOS installer - prepare the drive
and copy over there core OS. Then at the end of the core install, prompt
for the additional stuff

On Sun, Jun 21, 2015, 12:47 PM JAYDEN CHARBONNEAU jcharbonnea...@cpsge.org
wrote:

 The installer.We should add a more...'friendly' interface to it.Mostof the
 installer is a bunch of keypresses and text on the screen after you select
 the packages to install.(I myself often forget which keys to press).

 On Thu, Jun 18, 2015 at 2:07 PM, Mercury Thirteen mercury0x0...@gmail.com
  wrote:

 I'm removing the Pegasus mail app due to it being closed source.


 --

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



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

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

Re: [Freedos-devel] FreeDOS 2.0

[Antony Gordon]

If there were only retail copies of FreeDOS.

On Fri, May 29, 2015, 10:25 AM JAYDEN CHARBONNEAU jcharbonnea...@cpsge.org
wrote:

 If only there was a holographic FreeDOS (Like for the Samsung SMart
 window,or Microsoft's hololense).If there was a holographic FreeDOS,I would
 throw a party.(Think how cool that would be!).

 On Thu, May 28, 2015 at 10:30 PM, Mercury Thirteen 
 mercury0x0...@gmail.com wrote:

 Correction... FreeDOS 1.2. Not 2.0.

 On Thu, May 28, 2015 at 4:40 PM, Antony Gordon cuzint...@gmail.com
 wrote:

 Hi,

 If I were building the FreeDOS distribution, the only thing that would
 be included as a part of the official FreeDOS install would be the
 components that make up the OS depending on the MS/PC DOS version
 distribution we wanted to emulate.

 I would also supply these files as one complete ZIP file instead of
 individual files as they make up the core of what you expect to have
 available when using DOS. I think that is all the FreeDOS installer should
 install. Everything else should be separate.

 All the other stuff would be fluff, like GEM, NDN, and the developer
 tools.

 If the final line in the sand is that without source it can’t be
 included, I think a list of where to find stuff would be useful to find the
 tools or applications needed.
  On May 28, 2015, at 3:52 PM, Mercury Thirteen mercury0x0...@gmail.com
 wrote:
 
  Although it is freeware, source code for NDN appears to be
 unavailable. Given this project's push towards 100% open software, I am
 inclined to exclude it from the FreeDOS 2.0 image.
 
  Any thoughts?
 
 --
  ___
  Freedos-devel mailing list
  Freedos-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-devel



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




 --

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



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

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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hi

snip
 Do ZM EXEs actually exist?
 

Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is 
full of them.

 I've also been curious as to what the format is for .TOS binaries (since 
 GEMDOS has such a similar API to MS-DOS).
 

Grab one and run it through a hex editor. 

The API has no bearing on the executable file format. In addition, Atari 
computers were using Motorola processors and not Intel processors with a 
segmented memory model. 


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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hi,

See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some 
point. They are typically called MZ executables.

 On Jun 8, 2015, at 8:55 PM, Steve Nickolas usots...@buric.co wrote:
 
 On Mon, 8 Jun 2015, Antony Gordon wrote:
 
 Hi
 
 snip
 Do ZM EXEs actually exist?
 
 
 Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is 
 full of them.
 
 I said ZM, not MZ.
 
 -uso.
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hi,

It’s all semantics. Most signatures are MZ, but some old linkers (not sure if 
they are even in use) used ZM according to RBIL

Values for the executable types understood by various environments:
 MZ old-style DOS executable (see #01594 
http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html)
 ZM used by some very early DOS linkers, and still supported as an
  alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS

-T

 On Jun 8, 2015, at 9:16 PM, Steve Nickolas usots...@buric.co wrote:
 
 On Mon, 8 Jun 2015, Antony Gordon wrote:
 
 Hi,
 
 See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at 
 some point. They are typically called MZ executables.
 
 I was specifically referring to the specific magic number that would show 
 up as ZM in a text editor.  All the files I've seen have the number in 
 the opposite order such that the magic number appears as MZ.
 
 -uso.
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hi

snip
 
  I'd suggest using 0xC3 0x00 as a magic number for any non-8086 executable.
 Or, for preference, using a 4-byte magic number: 0xC3 0x00 0x00 followed by
 a byte giving the supported CPU architecture. Then the logic in the loader 
 would be:
 
 0xC3 0x00 0x00 suitable architecture   - run as native EXE
 0xC3 0x00 0x00 unsuitable architecture - return an error
 0x4D 0x5A   (or 0x5A 0x4D)   - run in emulator as x86 EXE
 anything else- run in emulator as x86 COM
 

The only problem I see is that to make an executable file that DOS recognizes 
according to the API, it has to follow this structure (in C for clarity)

struct EXE {
  unsigned short signature; /* == 0x5a4D */
  unsigned short bytes_in_last_block;
  unsigned short blocks_in_file;
  unsigned short num_relocs;
  unsigned short header_paragraphs;
  unsigned short min_extra_paragraphs;
  unsigned short max_extra_paragraphs;
  unsigned short ss;
  unsigned short sp;
  unsigned short checksum;
  unsigned short ip;
  unsigned short cs;
  unsigned short reloc_table_offset;
  unsigned short overlay_number;
};

struct EXE_RELOC {
  unsigned short offset;
  unsigned short segment;
};
 To maintain compatibility with MS-DOS and FreeDOS, we are constrained by the 
loader.  The signature has to be first. Here are some additional signatures 
that can appear in a DOS .EXE file

Values for the executable types understood by various environments:
 MZ old-style DOS executable (see #01594 
http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html)
 ZM used by some very early DOS linkers, and still supported as an
  alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS
 NE Windows or OS/2 1.x segmented (new) executable (see #01596 
http://www.delorie.com/djgpp/doc/rbinter/it/96/15.html)
 LE Windows virtual device driver (VxD) linear executable (see #01609 
http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html)
 LX variant of LE used in OS/2 2.x (see #01609 
http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html)
 W3 Windows WIN386.EXE file; a collection of LE files
 W4 Windows95 VMM32.VXD file
 PE Win32 (Windows NT and Win32s) portable executable based on Unix COFF
 DL HP 100LX/200LX system manager compliant executable (.EXM)
 MP old PharLap .EXP (see #01619 
http://www.delorie.com/djgpp/doc/rbinter/it/19/16.html)
 P2 PharLap 286 .EXP (see #01620 
http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html)
 P3 PharLap 386 .EXP (see #01620 
http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html)
Retrieved from http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html 
http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html
Obviously we can add to the loader code in FreeDOS so it can recognize a 
FreeDOS non x86 architecture EXE file, or we can extend after offset 0x1C with 
architectural information as the EXE header is 512 bytes IIRC. This extension 
can be back ported to the 16-bit version, so at the very least it can say “This 
program requires FreeDOS 32” or something to that effect similar in function to 
the Windows PE executables. 

  The reason for using 0xC3 0x00 as the magic number is that no useful 
 DOS COM file will start with those bytes (0xC3 is x86 for RET). The extended
 sequence 0xC3 0x00 0x00 also rules out CP/M-80 COM files, which might start
 with 0xC3 but won't follow that with two zeroes.
 
 -- 
 John Elliott
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hi,

 On Jun 5, 2015, at 6:10 PM, Steve Nickolas usots...@buric.co wrote:
 
 A port of DOS to ARM would not be bound to any existing API and would not 
 need to be compatible with any existing DOS implementations, while still 
 being a port of DOS.
 

That’s technically incorrect. The reason that Linux (and UNIX) work on 
different architectures is that the API is the same, but the low level 
interface to the hardware is the difference. Since there is no BIOS to speak of 
on other processors, nor a concept of real and protected mode, a lot will have 
to go into the kernel, basically making a hardware abstraction layer that 
emulates the BIOS, that can process a DOS executable for Intel processors and 
make determinations on whether it is a 16-bit application or a 32-bit 
application and run it accordingly.

If you don’t keep the basic DOS API (via Int 21h) then it’s technically not 
DOS, but another operating system.

Microsoft attempted (for the x86 version) to keep a compatibility layer in the 
OS so that you could run DOS applications, even though these applications were 
written for a single task, 16-bit real mode OS that allowed direct hardware 
access, which unfortunately can cause issues in a 32-bit protected mode 
environment.

Fortunately, the benefit in our favor is some of this work has already been 
done. There is an open source BIOS implementation that can be grafted in to 
FreeDOS, it’s just a matter of figuring out which one to use and how to 
implement it.

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


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

Re: [Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

Eric,

 
 That mainly is because Apple is Apple ;-) In DOS, you get very
 far with a standard C library, good old OpenWatcom or DJGPP, in
 the latter case even similar enough to the Linux GCC and G++ C
 and C++ infrastructure to ease porting of things to DOS. As DOS
 does not provide GUI, networking or other fancy things as part
 of the operating system itself, you can use existing popular C
 and other libraries for that (Watt32, Wattcp, SDL, FLTK, ...)
 without being bound to a specific choice. The better libraries
 of course also come with sample code and documentation :-) Our
 distro could include some of the more popular libraries, giving
 people a nice starting point for their projects :-)
 

That is the whole idea behind the FreeDOS Developer Studio. I know as well as 
anyone that there are multiple ways to do anything in DOS. Including some of 
the popular libraries with documentation and sample code either from the 
library itself or written by us would be great.

In addition white papers or articles on best practices. When DOS was king, we 
had Peter Norton, Andrew Schulman, Jim Pyle, and a host of other great authors 
that provided information in books (some of which are out of print and most are 
hard to find) on how to do various things in DOS. I believe there are some very 
knowledgeable people on this list and we can recreate some of those resources 
in the form of bite sized articles. I consider you a great resource for 
example, but there are others on this list.

Let’s use long file name support as an example. We have included in FreeDOS, 
LFNDOS to support the long file names. Since it is open source and we have the 
code, why not include LFN as a library in the developer studio then someone who 
is writing an application using long file names can reference that code as a 
library. 

I know they can download it themselves and include what they need, but I think 
that as an example would bring a huge benefit to FreeDOS especially given all 
the updates made.

 Regarding OpenWatcom, NASM, RBIL, Japheth's HX (and JWASM!), I
 agree that those are nice things to include :-) Some are rather
 large, but I have seen people make compressed basic OpenWatcom
 install files that fit on one floppy. It is always hard to get
 a good balance in what to include. FreeBasic and FPC etc. are
 not very small, but e.g. the set of pre-ported things for DJGPP
 is outright huge. You could even have a distro just for DJGPP.
 

Since OpenWatcom is “open” I was thinking perhaps taking the source and 
branding it as FreeDOS C based on OpenWatcom, (to give credit) which is what 
Microsoft did initially with Lattice C via a licensing agreement. The same is 
true for Free Pascal (if we so desired) albeit with a different name since we 
can’t call it Free Pascal.

 I hope Rugxulo can help you getting that HX download uploaded
 to a place where it is easier to get than from the web archive.
 

The licensing for it (as it relates to FreeDOS) has me wondering if it is even 
worth the effort. Based on what I read, it sounds good, but if GPL is a factor, 
we may need to consider something else. I wouldn’t want any hang ups to prevent 
this from moving forward.

 Note that RBIL already tells quite a bit about XMS and EMS, so
 having the spec as separate document is just for added detail.
 

Yes RBIL covers EVERYTHING, but I think having the “official” specification 
lends more credence to the information we’re providing. If we find that it’s 
not as useful, it can be removed or referenced via a hyperlink.

 In particular, XMS is relatively easy to use even if you do not
 have a library for it. Using XMS or EMS with old (C) compilers
 can take some effort (memory models and low level stuff to get
 into the way, maybe) but to be honest, why take the effort for
 manual memory management at all? Simply use any protected mode
 aware compiler (DJGPP or a larger memory model in OpenWatcom)
 and DPMI and other DOS extender things will magically work for
 all your basic needs. Note that when you go that direction, it
 will mean that you have to avoid assumptions about direct raw
 memory access (screen buffers and such). If you do want that,
 you will have to take some explicit efforts, but there is some
 sample code on the web to help you out :-) Or just use one of
 the existing GUI toolkit libraries to do the work for you :-)
 

I’m glad we’re finally getting along. :) I was worried for a minute that you 
weren’t going to like me.

Have a wonderful day.

Tony


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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Hey,


 On Jun 5, 2015, at 6:49 PM, Chelson Aitcheson chelson.aitche...@gmail.com 
 wrote:
 
 Nothing is impossible if it was the case we would all still be using reel to 
 reel and tape decks lol.
 
 Lots of ideas and spit balling here but hey why not write it up and if people 
 wana contribute then they will if not keep using old trusty xt
 

Two thumbs up

 On 06/06/2015 8:39 am, Steve Nickolas usots...@buric.co 
 mailto:usots...@buric.co wrote:
 On Sat, 6 Jun 2015, Chelson Aitcheson wrote:
 
  Doesn't matter, Mac os power pc applications dont work on new Mac os but
  it's still the same os.
  (rosetta comparability layer aside)
 
  I see this as more of a chance for a new generation of dos. Freedos 1.x has
  accomplished the needs for the existing replacement or clone requirements
  of a dos with enhancements and still caters to the needs of its users.
 
  Yes it's lots of work to port stuff and to add compatibility layers etc..
  but where is your sense of adventure?
 
  Yeah merc I see doscore on arm in a few years.
 
 If you can mark the EXEs as something other than MZ, you could perhaps
 make a TSR loader stub that loads an x86 emulator on demand to run EXE
 files.
 
 COM... I think you're gonna be stuck with using only an EXE format because
 trying to detect a COM file by architecture is fraught with peril.
 
 -uso.
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net 
 mailto:Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel 
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

Hi.
 On Jun 3, 2015, at 3:55 PM, Rugxulo rugx...@gmail.com wrote:
 
 Hi,
 
 On Wed, Jun 3, 2015 at 1:12 PM, Eric Auer e.a...@jpberlin.de wrote:
 
 How about a FreeDOS Developer Studio?
 
 I don't want to be pessimistic or discourage anyone, but this sounds 
 difficult.
 

Not being pessimistic, being realistic.

Realistically speaking, there isn’t much else you can contribute to FreeDOS 
unless someone is planning on secretly recreating Central Point tools or Norton 
Utilities. Majority of the DOS commands are represented (maybe not well, but 
represented) there is a fair amount of what I would consider 3rd party software 
like OpenGEM, and such that is deemed open enough to include with FreeDOS.

 I think SETEDIT comes with some programmer support and
 there is some DJGPP IDE (RHIDE?) and maybe others.
 

Is there an IDE that’s included with FreeDOS that we can extend to read 
compiler messages and such?

 Neither has been maintained (for DOS/DJGPP, at least) in a decade.
 Well, RHIDE is more of a sore spot because it only works with ancient
 GCCs (3.3.6 or such), either being built itself or debugging (RHGDB,
 GDB 6.3?? COFF debug info only, which doesn't work well with newer GCC
 4.5+).
 
 I'm not saying RHIDE isn't good. Most people used to love it. But it's
 probably not a great idea (anymore) unless you just can't live without
 it. (IIRC, DJGPP GNU Emacs is still built with GCC 3.4.4 due to
 reliance on COFF debug info for unexec.)
 
 Anyways, IIRC, latest semi-official build (1.5c) is here (No more are
 are planed in near future.):
 
 http://ap1.pp.fi/djgpp/rhide/
 
 BTW, there are newer DJGPP GDB ports, but I'm not sure how (fully)
 well they work. There is still some commotion about them needing some
 fixes. Some also had --tui built-in, dunno, never heavily used it in
 recent years. Latest DJGPP GDB port is 7.7.1.
 
 While I myself do not use free open source IDE for DOS, but do
 remember that the Turbo C / Turbo Pascal IDE was not bad,
 I suggest that there could be a discussion in this thread
 about experiences that people have with existing DOS IDE,
 in particular the free open source ones :-)
 
 Some DOS editors can easily catch compiler error messages. Of course
 GNU Emacs (24.5) works with DJGPP. But you could also use (much
 smaller) JED, which (IIRC) supported several more error formats (even
 Watcom or Borland). Obviously others might work with DJGPP as well
 (e.g. FED, even TDE has very limited support, VILE might barely work
 too, not sure about VIM but presumably yes).
 
 I don't really use IDEs. Some people love them. Of course, FreePascal
 builds its own TUI IDE in itself (with built-in compiler), so that IDE
 is always included. (Usually also has GDB built-in as well.)
 
 Regarding the OTHER aspect of your idea - collecting new
 and classic tools which are nice for developers - I agree
 that it is good to have all things needed to compile all
 standard parts of the FreeDOS distro, but for some, there
 will be license issues in providing downloads. You should
 just point people to suitable official websites for such
 things as the free museum Borland compiler versions.
 

I wasn’t recommending the Borland stuff for this for that particular reason. 

 In other words ... forget Borland entirely. IIRC, Embarcadero still
 don't allow redistribution of their ancient DOS compilers. (You could
 email and plead nicely, but don't get your hopes up. And I don't
 honestly know if Jim Hall would want to mirror such things on iBiblio
 anymore.)
 
 It would be better to convert everything like that to OpenWatcom, but
 lots of stuff has been unmaintained for years, so it's unlikely to
 happen. (Some of it isn't really portable and uses old Borland-isms.)
 
 I do not know what the PC Game Programmer's Encyclopedia
 license is, but remember that various similar projects
 exist, so you could include one which is good and does
 have a free license. And of course include RBIL - Ralf
 Brown's Interrupt List :-)
 
 ftp://ftp.lanet.lv/pub/programming/mirror-x2ftp/gpe/00index.html
 
 It would combine all of the recommended build tools to build the
 operating from the source.
 
 This is a lot harder than it sounds.  :-/
 
 With that being said (theoretically), would it be a good idea?
 
 OpenWatcom, NASM, FreePascal, what else?
 
 These are already available in FDNPKG format, BTW.
 
 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/
 

Yes they are, but there is no environment setup, a la Visual Studio or Xcode. 
Just a bunch of tools and your wits. 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list

Re: [Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

Eric,

Finally I’m not irking your nerves :) I wasn’t thinking of even using the 
Borland Museum tools. What I actually envisioned was much like what Apple does 
with Xcode, they provide an IDE, LLVM (and GCC) and Swift along with sample 
code, an SDK and documentation.

Fortunately for FreeDOS, the MS-DOS API is included with every DOS based 
compiler, so we have the SDK covered. An HTML version of RBIL would be cool and 
as far as the toolchain, I was thinking OpenWatcom and NASM. I managed to pull 
Japheth’s source code from the web archive of his site, so perhaps we could 
include the HX DOS Extender along with the source he had…that’s a side bar for 
the maintainers though.

The XMS specification is publicly available as is the EMS specification. The 
Game Programmer’s Encyclopedia covered things like graphics modes, unreal mode, 
I think I may still have the disk set for the EMS specification (I definitely 
have the book - the pages were sent to be added to the IBM DOS reference 
binder).

If not, perhaps using the specification, we can build out a library in C or ASM 
that covers these specifications and include them.

Regards

 On Jun 3, 2015, at 2:12 PM, Eric Auer e.a...@jpberlin.de wrote:
 
 
 Hi!
 
 How about a FreeDOS Developer Studio?
 
 I think SETEDIT comes with some programmer support and
 there is some DJGPP IDE (RHIDE?) and maybe others. While
 I myself do not use free open source IDE for DOS, but do
 remember that the Turbo C / Turbo Pascal IDE was not bad,
 I suggest that there could be a discussion in this thread
 about experiences that people have with existing DOS IDE,
 in particular the free open source ones :-)
 
 Regarding the OTHER aspect of your idea - collecting new
 and classic tools which are nice for developers - I agree
 that it is good to have all things needed to compile all
 standard parts of the FreeDOS distro, but for some, there
 will be license issues in providing downloads. You should
 just point people to suitable official websites for such
 things as the free museum Borland compiler versions.
 
 I do not know what the PC Game Programmer's Encyclopedia
 license is, but remember that various similar projects
 exist, so you could include one which is good and does
 have a free license. And of course include RBIL - Ralf
 Brown's Interrupt List :-)
 
 It would combine all of the recommended build tools to build the
 operating from the source.
 
 I know a lot of the individual components that comprise FreeDOS
 commands are written using various tools, i.e., museum versions of
 Borland compilers, and they also use Turbo Vision (or the free
 representation thereof)
 
 With that being said (theoretically), would it be a good idea?
 
 OpenWatcom, NASM, FreePascal, what else?
 
 I have the PC Game Programmer’s Encyclopedia. Most of those articles
 were public domain documents (the XMS and EMS specifications are in
 there as text files), the GIF87 spec, etc. [...]
 
 
 
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

Why is that important?

On Wed, Jun 3, 2015, 6:14 PM Steve Nickolas usots...@buric.co wrote:

Keep in mind that OpenWatcom doesn't meet Debian or GNU's criteria to be
open source.



-uso.

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

Re: [Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

It could either be on the ISO or a package that's installed. The idea that
I had was to provide someone who wanted to develop for FreeDOS a collection
of pre configured tools, documentation and examples to get started.

Some of us know FreeDOS better than others as well as the internals of
MS-DOS. Most of the resources are out of print or hard to find in some
cases.

Templates for device drivers, templates for building FreeDOS compatible
packages.

On Wed, Jun 3, 2015, 5:40 PM Rugxulo rugx...@gmail.com wrote:

 Hi,

 On Jun 3, 2015 4:13 PM, Antony Gordon cuzint...@gmail.com wrote:
 
   On Wed, Jun 3, 2015 at 1:12 PM, Eric Auer e.a...@jpberlin.de wrote:
  

   I think SETEDIT comes with some programmer support and
   there is some DJGPP IDE (RHIDE?) and maybe others.
 
  Is there an IDE that’s included with FreeDOS that we can
  extend to read compiler messages and such?

 What do you mean? Included in the Software List or inside fd11src.iso or
 mirrored on iBiblio?

 I don't think FD EDIT was meant for that kind of thing, for instance.
 Can't remember if OpenWatcom's vi supports it.

 I haven't done it lately, but I've still got my script to rebuild JED with
 DJGPP. Wouldn't that be sufficient? Or do you have something more specific
 in mind?

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

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

[Freedos-devel] FreeDOS Developer Studio

[Antony Gordon]

Hi,

Since I’ve become the “bain of everyone’s existence” regarding the 32-bit 
extension to FreeDOS, I am going to attempt to offer an olive branch so I can 
stay on the list.

How about a FreeDOS Developer Studio?

It would combine all of the recommended build tools to build the operating from 
the source.

I know a lot of the individual components that comprise FreeDOS commands are 
written using various tools, i.e., museum versions of Borland compilers, and 
they also use Turbo Vision (or the free representation thereof)…

With that being said (theoretically), would it be a good idea?

OpenWatcom, NASM, FreePascal, what else?

I have the PC Game Programmer’s Encyclopedia. Most of those articles were 
public domain documents (the XMS and EMS specifications are in there as text 
files), the GIF87 spec, etc. I know a lot of these articles are easily 
accessible via the web, but perhaps by providing a centralized location where 
you can find code examples and documentation.


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

Re: [Freedos-devel] FreeDOS 1.2 package compilation

[Antony Gordon]

What I think would be useful would be an Xcode/Visual Studio type of 
environment that includes all of the recommended build tools setup with a batch 
file to set paths to have the tools work from any location on the hard drive.

This can be used to rebuild the OS or to develop new applications for the OS. 


 On Jun 3, 2015, at 12:42 AM, Antony Gordon cuzint...@gmail.com wrote:
 
 That was a HUGE zip file (once uncompressed).
 
 I’m just glad I use a sandbox for stuff like this, that zip file was like a 
 box of chocolates…
 
 That being said…that much stuff comes on the FreeDOS full CD image? It kind 
 of reminds me of the old Linux distributions that would ship a distribution 
 on one CD and then a separate CD that was a snapshot of the Linux parts of 
 various FTP sites.
 
 I guess when you have almost 700MB to fill, you gotta do something.
 
 
 
 
 On Jun 2, 2015, at 8:09 PM, Mercury Thirteen mercury0x0...@gmail.com 
 mailto:mercury0x0...@gmail.com wrote:
 
 Everyone take a look at this ZIP 
 http://mercurycoding.com/FreeDOS/FreeDOS-1.2.zip and let me know your 
 feedback. Anything which shouldn't be included? Anything which should but 
 wasn't? There's a few non-open source programs I didn't catch for removal.
 
 Let me know your input.
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net 
 mailto:Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
 

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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Eric,

It’s involved, but so was writing an MS-DOS clone almost 17 years ago that is 
able to run 98% of all DOS software natively factoring in the quirks and 
undocumented and partially documented structures that had to be clean room 
implemented to avoid infringement. 

You and I were around for the beginnings of FreeDOS (when Pat was involved) and 
it was looking shaky then. Now FreeDOS in places were there was nothing to fit 
the bill, such as BIOS update disks, disk recovery tools, and emergency boot 
disks.  What I am advocating is a next level inclusion. Version 1.2 of FreeDOS 
is what, pushing out things that don’t use the GPL license and/or is free but 
the source code is no where to be found. 

The idea I have isn’t to create DOS windows in Windows but rather to build, 
using the Windows kernel which we can pull portions from Wine and/or ReactOS, 
load Windows drivers, and create a hardware compatibility layer whereby you can 
map an onboard sound card to the Sound Blaster settings, i.e., SET BLASTER=A220 
I5 D1 T3 P330 H6 E620. USB game controllers can be mapped to the game port, USB 
printers to the parallel port, etc.

I’m not interested incorporating the GUI portion of Windows and given the open 
source nature of some of the other projects, I think having access to 
incorporate these pieces into a FreeDOS 32 project would be ideal. 

 

 On May 31, 2015, at 7:08 AM, Eric Auer e.a...@jpberlin.de wrote:
 
 
 Hi Antony,
 
 if the goal is only to use Windows driver, then writing
 a clone of Windows is a high price. Plus it already has
 been paid, by the ReactOS project. Note that DOS windows
 in Windows often do not gain from Windows drivers: For
 example if your soundcard comes with a Windows driver,
 your DOS games still can not use that, even in Windows.
 
 The exception would be dosemu and dosbox in Linux and,
 only the latter, in Windows: Those simulate a PC with
 DOS compatible hardware. They are not just DOS windows.
 
 So regarding the balance between gain and effort, the
 big question is: For WHICH (categories of) pieces of
 Windows hardware do you want better DOS support? You
 already say that mouse, keyboard and storage are not
 enough, so what else?
 
 You mention VMware, Parallels and VirtualBox: Those
 all simulate complete PC hardware, VM aware client
 drivers there are just to add features, such as the
 host / client drive sharing for which at least some
 VMware DOS driver already has been written afaik :-)
 
 I remember that the joystick category already is
 known to DOS USB drivers: The problem probably is
 that many games do NOT use the BIOS calls to query
 joystick status. Instead, they directly access the
 joystick port hardware, but that expects non-USB.
 
 Again, full hardware simulations can give your DOS
 game access to non-DOS sound and joystick, but DOS
 windows in Windows are not enough for that...
 
 And a full hardware simulation is not what you are
 looking for, apparently: You only want DOS which
 somehow at the same time is almost Windows, so it
 can use Windows drivers. To make that really work,
 you would end up having a lot of Windows plus some
 PC hardware simulator, which is much more than DOS.
 
 For thinking about how small a system could be to
 combine DOS and sufficient magic to support those
 pieces of Windows hardware you are intersted in,
 the main question is: WHICH Windows hardware driver
 categories are you interested in?
 
 Regards, Eric
 
 PS: Your intuition that using Windows drivers and
 not Linux drivers for DOS probably comes from DOS
 and Windows being from the same company. Yet BOTH
 modern driver ecosystems are totally DOS unrelated.
 There IS some DOS software with Linux sound drivers.
 
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Eric,

It’s simple. Every piece of computer hardware comes with a Windows driver. 
Depending on the age of the device, you may have the older Windows drivers, or 
the newer Windows Driver Model driver. The reality is that to the major 
manufacturers of hardware, DOS is dead. No one is using a 16-bit OS, especially 
DOS, excluding our demographic, or as an “emergency boot disk. The bare 
minimum is 32-bit and now the transition is to 64-bit operating systems. DOS is 
so “dead” that VMWare, Parallels, and VirtualBox (even though the latter is 
aware of FreeDOS/MS-DOS usage) do not provide integration services or support 
for DOS and Windows 3.x

USB support in DOS is limited to hard drives only, perhaps USB keyboards and 
mice as they can emulate their PS/2 counterparts. What about USB game 
controllers, if you weren’t fortunate enough to buy a game controller that runs 
off the game port of your sound card, you’re definitely not getting it to run 
on FreeDOS. Which means you have to play your favorite video games using the 
keyboard.

It’s true, you can install Linux or another OS, install the emulator of your 
choice, connect your game controller and have it emulate as a game port 
controller in FreeDOS, but what if you only want FreeDOS on your machine?

If we are able to graft the Windows API into FreeDOS (as FreeDOS 32) then we 
have access to thousands of drivers. If Windows is just so bad, then I guess 
we’re left to contemplate a way to graft the Linux driver model onto FreeDOS. 
Somehow, I think it would be much easier to do Windows.

Hope this helps,

 On May 29, 2015, at 11:31 AM, Eric Auer e.a...@jpberlin.de wrote:
 
 
 Hi Anthony,
 
 please explain in which way Windows WITHOUT a GUI would be
 something that we want to add to FreeDOS: There already are
 really good, free and open DPMI based DOS extenders for DOS.
 
 FreeDOS itself is not running in protected mode, but every
 EMM386 style software must use protected mode (not to be
 confused with EMS hardware solutions for old computers) and
 Windows in 386 enhanced mode is not compatible with normal
 EMM386. Instead, it uses an exotic interface called GEMMIS
 to REPLACE EMM386 on the fly. This only works with non-free
 versions, for example Microsoft EMM386. The solution is to
 use either the Microsoft version or simply not use EMM386.
 In some cases, HIMEM and similar drivers can cause similar
 problems, but again, you can use the Microsoft drivers :-)
 
 Microsoft mainly patches DOS when it tries to put it into
 a protected mode bubble to be able to run DOS windows in
 a Windows session. In standard mode, Windows is more like
 a normal program for DOS, which makes things easier :-)
 
 As described earlier in this thread, you do have to edit
 your Windows config AND you have to use special versions
 of the FreeDOS kernel to support that bubble wrapping or
 patching of FreeDOS for 386enh Windows compatibility. If
 Windows can not figure out how to patch DOS, it will give
 a similar error message to the already protected mode one.
 
 Microsoft demonstrated a means of providing multitasking and 32-bit
 functionality on top of a 16-bit OS through the development of Windows 3.x
 and Windows 9x. If we are able to build a 32-bit subsystem that can utilize
 the device drivers and other existing components of the 32-bit Microsoft
 subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that
 provides the backwards compatibility that is needed to meet spec.
 
 Everything that you mention in the previous paragraph is
 useful only for graphical Windows software: To summarize,
 you really should try Linux with Wine, or ReactOS for it.
 
 Regards, Eric
 
 PS: Even running only multiple DOS Windows in Windows is
 already something that does need the GUI of Windows, too.
 But you can work with DOS task swappers, as TriDOS :-)
 They swap between different (full screen) DOS sessions.
 This is not related to how many bits your Windows has.
 
 
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Eric,

I only mentioned the Windows portion because it would tie in compatibility
on the Microsoft side of things for classic software, not necessarily to
re-invent Windows 3.x or Windows 9x.

I'll try to elaborate more.

If you strip the GUI from MS Windows, you have 3 important parts that run
to implement 32-bit protected mode. KRNL386, DOSX (the DOS Extender) and a
virtual machine manager. If we were able to recreate those three components
and build them in such a way that they are compatible with Windows virtual
device drivers, we'd have a 32-bit extension to FreeDOS that we could use

At the core of it's existence, The portions of the Windows 3.x subsystem
that tie into DOS in 386 Enhanced mode consists of a DPMI server and a
virtual machine manager of sorts. Microsoft patches certain aspects of DOS
when Windows runs. In 1993, we were at best guessing (unless you had an OEM
NDA) what was going on and depending on Andrew Schulmann et. al. to provide
insight. Now, that we can clearly see what was done (more or less), we can
implement a similar concept, but a different way.

FreeDOS presently appears to run in protected mode (I found that out trying
to run Windows in enhanced mode). The error message that Windows gave was
that the processor was already in protected mode.

Microsoft demonstrated a means of providing multitasking and 32-bit
functionality on top of a 16-bit OS through the development of Windows 3.x
and Windows 9x. If we are able to build a 32-bit subsystem that can utilize
the device drivers and other existing components of the 32-bit Microsoft
subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that
provides the backwards compatibility that is needed to meet spec.

If, by doing that, running Windows applications becomes a possibility, that
is only a side benefit.

The other alternative is to find a way to implement the DOS API completely
in a 32-bit address space, which alienates the older applications.

On Thu, May 28, 2015 at 8:55 PM, Eric Auer e.a...@jpberlin.de wrote:


 Hi :-)

  1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate
  executable (it would only be installed if it detected a 32-bit
  capable processor), perhaps call it FD32. It would switch to
  protected mode and spawn a protected mode shell.

 http://freedos-32.sourceforge.net/ already exists. No news since 2011.

 FD32 runs more parts in 32-bit, but the advantages compared to using a
 classic DOS together with a DPMI compatible DOS extender are minimal.

  The other possibility During the install, determine if the computer
  can support 32-bit instruction set If so, install FreeDOS and install
  the FreeDOS 32-bit components (provide an option to only run the
  16-bit OS) FreeDOS 32 starts automatically by running the initial
  16-bit environment, then spawning the 32-bit environment to take
  over.

 We once pondered this as part of the ISO boot process. But because
 it is almost impossible to boot from CD on 8086 or 286 computers,
 we dropped the idea. Instead, just take a floppy with a special 16
 bit, 8086 compatible version of DOS if you have such old hardware.
 The ISO simply assumes that you have 386 or newer hardware anyway.

 Interestingly, 8086 or PC-XT compatible FreeDOS floppy distros are
 actively discussed here and even updated at this very moment :-)

  All existing drivers developed for FD16 would work. If we use the
  Windows SDK to clean build the 32-bit environment, then perhaps we
  can use Win9x drivers (if they are even still available).

 You cannot use Win9x drivers for DOS software. Also, you cannot use
 Windows for Workgroups 3.11 in 386 enhanced mode and expect it to
 behave well: It will use built-in 32 bit disk and FAT drivers which
 do not work well at all with modern things like FAT32, LBA, SATA.

 You can disable those drivers, but running WfW 3.11 in that mode is
 like running Win9x in safe mode: A lot of comfort gets lost. If you
 want to enjoy Windows 3 in FreeDOS, use Windows 3.0 or 3.1 and use
 standard mode, not WfW 3.11 - even 386enh mode of 3.0 / 3.1 is very
 fragile as all your drivers have to cooperate and let Windows take
 over as the boss of your protected mode infrastructure, locking the
 DOS kernel into a vm86 bubble with a task switching wrapper around
 it. FreeDOS tries to support that in newer kernels, but this stays
 really hard to do well because basically Microsoft Windows is only
 skilled in making bubbles around Microsoft DOS, so we can only try
 to be very similar in the parts to which the 386enh bubble sticks.

  Otherwise, we’d have to clean room Win NT to implement a 32-bit OS
  and ReactOS is still in alpha...

 If you want to use 32 bit Windows programs (beyond Win32s for 3.x),
 you do not have the option to use DOS for that. You must use either
 ReactOS or Linux with Wine or a closed source OS like OS/2 or actual
 Microsoft Windows. In some cases, Japheth's HX / HXRT for DOS will
 be able to run really lightweight Windows 

[Freedos-devel] Windows for Workgroups and FreeDOS

[Antony Gordon]

Hi,

So for the pure fun of it, I decided to install Windows 3.11 on FreeDOS knowing 
full well how well it would work. (Cue laugh track)

I don’t know how far anyone has gotten with this process but so far what I have 
found is that FreeDOS (unlike MS-DOS) in it’s default configuration ends up in 
protected mode. If you’re in protected mode, Windows is unable to use DOSX and 
switch to protected mode.

Fortunately, Microsoft includes HIMEM.SYS and EMM386.EXE with WfW. In 
VirtualBox, EMM386.EXE NOEMS appears to hang FreeDOS at boot, but HIMEM.SYS 
does work. Through process of elimination, I figured that DOSLFN is the culprit 
that is switching FreeDOS to protected mode.

Once I commented out the line, I got an error message that the DOS version is 
unsupported, at which point Windows returns to the command prompt. I think 
somewhere along the line the memory control blocks get mutilated because the 
next internal command I run (“dir”) bombs with a message regarding being unable 
to terminate the resident FreeCOM and then a message about invalid opcodes.

VirtualBox then hangs and I have to reboot.

I have a copy of Undocumented DOS 2nd Edition (complete with the source code) 
so I have been running some of the tools that they wrote to test DOS 
compatibility, and presently, there seems to be an issue with SHARE. The 
MSDETECT code that I fully expected to fail (after a reboot because of the 
invalid opcode) returned that FreeDOS is a legitimate Microsoft DOS (which we 
know isn’t true).



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

[Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

I was re-reading some emails and I think I have an idea of how this would work. 

The goal is existing compatibility so that older DOS applications will run. 
Obviously, moving to 32-bit will eliminate most of the older processors, 
HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to 
supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel 
to run each 16-bit application, as well as develop 32-bit applications.

The important pieces I believe that need to be figured out is the VMM (Virtual 
Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was 
still able to utilize real mode DOS drivers.

Thoughts?



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

Re: [Freedos-devel] 32-bit FreeDOS

[Antony Gordon]

Here’s one possibility:

1. Start FreeDOS (16-bit mode)
2. Start FreeDOS-32 via a separate executable (it would only be installed if it 
detected a 32-bit capable processor), perhaps call it FD32. It would switch to 
protected mode and spawn a protected mode shell.

The other possibility
During the install, determine if the computer can support 32-bit instruction set
If so, install FreeDOS and install the FreeDOS 32-bit components (provide an 
option to only run the 16-bit OS)
FreeDOS 32 starts automatically by running the initial 16-bit environment, then 
spawning the 32-bit environment to take over.

All existing drivers developed for FD16 would work. If we use the Windows SDK 
to clean build the 32-bit environment, then perhaps we can use Win9x drivers 
(if they are even still available).

Otherwise, we’d have to clean room Win NT to implement a 32-bit OS and ReactOS 
is still in alpha...


 On May 28, 2015, at 4:58 PM, Mercury Thirteen mercury0x0...@gmail.com wrote:
 
 Agreed, that was my exact line of thinking.
 
 However, the folks here seem to have come to the conclusion that FreeDOS will 
 not evolve into the 32-bit realm.
 
 On Thu, May 28, 2015 at 4:47 PM, Antony Gordon cuzint...@gmail.com 
 mailto:cuzint...@gmail.com wrote:
 I was re-reading some emails and I think I have an idea of how this would 
 work.
 
 The goal is existing compatibility so that older DOS applications will run. 
 Obviously, moving to 32-bit will eliminate most of the older processors, 
 HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to 
 supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel 
 to run each 16-bit application, as well as develop 32-bit applications.
 
 The important pieces I believe that need to be figured out is the VMM 
 (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x 
 because it was still able to utilize real mode DOS drivers.
 
 Thoughts?
 
 
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net 
 mailto:Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel 
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
 
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] FreeDOS 2.0

[Antony Gordon]

Hi,

If I were building the FreeDOS distribution, the only thing that would be 
included as a part of the official FreeDOS install would be the components that 
make up the OS depending on the MS/PC DOS version distribution we wanted to 
emulate.

I would also supply these files as one complete ZIP file instead of individual 
files as they make up the core of what you expect to have available when using 
DOS. I think that is all the FreeDOS installer should install. Everything else 
should be separate. 

All the other stuff would be fluff, like GEM, NDN, and the developer tools.

If the final line in the sand is that without source it can’t be included, I 
think a list of where to find stuff would be useful to find the tools or 
applications needed.
 On May 28, 2015, at 3:52 PM, Mercury Thirteen mercury0x0...@gmail.com wrote:
 
 Although it is freeware, source code for NDN appears to be unavailable. Given 
 this project's push towards 100% open software, I am inclined to exclude it 
 from the FreeDOS 2.0 image.
 
 Any thoughts?
 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] FreeDOS (ODIN) and 8086 compatibility

[Antony Gordon]

MORE and SORT typically work on files and console input. When piping a
temporary file is created. IIRC that is done even in UNIX from which the
file handle idea and pipes originated from.

I do believe MODE MONO was specifically for working with Hercules and
monochrome video cards, whereas working with CGA or better in B/W required
MODE BW80. However, there are idiosyncrasies across DOS versions (IBM DOS
vs MS OEM adapted DOS) that make this hard to track out.

IBM DOS 3.1  Compaq MS DOS 3.31  MS-DOS 5.0  MS-DOS 6.x in my opinion
represents the stable Microsoft compatible and stable versions of DOS.

On Mon, May 25, 2015 at 2:27 AM Mateusz Viste mate...@viste.fr wrote:

 On 25/05/2015 06:33, Ralf Quint wrote:
  MEMA: Prints out garbage to screen and quits.
  What is MEMA?

 No idea, only Steve knows probably :) I assumed it is some kind of
 replacement for MEM (since MEM is missing on ODIN), but because of its
 crashing, I couldn't check.

  KEYB: immediately crash with Runtime error 105 at :252F
  Do you use any country modifier? If so, it's bug in KEYB opening up the
  language/country file NOT in a read-only mode, showing up due to having
  the floppy disk write protected...

 No, no modifiers at all - bare FreeDOS without autoexec nor config.sys
 files.

  MORE: Exactly same symptoms as SORT.
  ditto.

 Why does MORE requires a temp file is beyond me. BUt of course if it
 does, that's life. Will see then to maybe write a replacement that
 wouldn't need to write to disk(ette), if I can't find any free
 alternatives.

  DIR: When using DIR/P, DIR seems to think that the screen is 1-row high,
  and asks for a keypress for every line (the screen is CGA-based, 25
 rows).
  That must be some issue with your PC, works fine for me and should not
  be related to 8086 code or not at all...

 Not related to 8086, but this might be related to CGA. Are you a proud
 owner of a CGA, too?

 I was recently fixing a bug in another software that was exhibiting
 exactly same behavior (1-line virtual screen on CGA). The bug was
 related to the fact that on a CGA the location 0040:0084 does not
 contain the screen's height (no need, since CGA can't be anything else
 than 25 rows anyway). The solution was to test for an EGA, if EGA or
 better found then fetch 0040:0084 for screen's height, otherwise assume
 25 rows.

  MODE: MODE MONO makes the screen blank. Had to type in blindly MODE
  BW80 to recover. Might not be a bug, but would be nice if MODE could
  check if a given mode is supported, before running it.
  Would have to test but that could be compatible behaviour with
 MS-DOS...

 Maybe. I have only MSDOS 3.3, and this one seem to lack MODE MONO
 entirely. It does understand MODE BW80, though - so maybe it's not
 'missing' MONO but simply not exposing it when running on MDA/HERC
 incompatible hardware.

 Mateusz



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS (ODIN) and 8086 compatibility

[Antony Gordon]

That is pretty old.

Is that something that is still needed or wanted?


 On May 24, 2015, at 5:29 AM, Mateusz Viste mate...@viste.fr wrote:
 
 Hi all,
 
 Not sure that anybody cares about this, but just in case - I recently 
 tested the 1-diskette FreeDOS distribution ODIN on an 8086 PC, and 
 spotted a few more or less serious problems.
 
 I got the ODIN image from odin.fdos.org, and more specifically this:
 http://odin.fdos.org/fdodin06.8088.zip
 
 Now, here goes the list.
 
 
 MEM: The command MEM is missing.
 
 MEMA: Prints out garbage to screen and quits.
 
 KEYB: immediately crash with Runtime error 105 at :252F
 
 DEFRAG: Blanks the entire screen, and freezes
 
 SORT: Freezes. When executed with DIR | SORT it tries to write 
 something to my diskette (!) that I had write protected, fortunately.
 
 MORE: Exactly same symptoms as SORT.
 
 DIR: When using DIR/P, DIR seems to think that the screen is 1-row high, 
 and asks for a keypress for every line (the screen is CGA-based, 25 rows).
 
 MODE: MODE MONO makes the screen blank. Had to type in blindly MODE 
 BW80 to recover. Might not be a bug, but would be nice if MODE could 
 check if a given mode is supported, before running it.
 
 
 cheers,
 Mateusz
 
 
 --
 One dashboard for servers and applications across Physical-Virtual-Cloud 
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Hello!

[Antony Gordon]

I think the original goal of FreeDOS has been met, based upon what I
remember from back in 2000 or so when I came across the project. I have
seen many posts back and forth about adding support for this and that
because Windows sucks and so forth and so on.

With that being said, here's what I see. Now I know opinions are like ...
and everyone has one...

The core FreeDOS aims to maintain compatibility with MS/PC DOS as it
pertains to in-memory data structures, like SysVars, Job File Tables,
memory control blocks, etc, documented (and undocumented API) based on DOS
6.22 such as the DOS routines (INT 21h), the multiplexer (INT 2FH),
Ctrl-Break (INT 23H), Critical Error handler (INT 24H), and although
superceded, absolute disk read and write (INT 25H, INT26H respectively).

DOS was designed in an extensible manner, so I believe rather than changing
the core of the OS, we need to EXTEND the OS. Obviously features such as
IPv4/IPv6, GPT, are not relevant to the class of users that are wishing to
still relive the glory days of the early x86 processors, i.e., 8086, 8086,
80186, 80286, etc.

There is a different class of user, mostly those commenting on this thread,
which would like to use DOS with newer machines. One alternative would be
to design and build a protected mode kernel that would map all of the real
mode calls and virtualize all hardware access. That would put us right
where OSes like Linux and Windows are. The other alternative is to develop
a platform that sits on top of DOS that runs and switches to protected mode
and virtualize all the hardware. That puts us where Windows 95/98 was.

To bring DOS into the future requires some parting with older
technologies, which isn't particularly a goal of this project. In
comparison, the issues that Microsoft has (and had) with Windows was in
part due to their attempts to bring along the past into the future. This is
why Microsoft let go of DOS in the Windows 9x code base and shifted to the
Windows NT code base. Even then, with 32-bit code, it was still possible to
run DOS applications (to an extent) but they were isolated to their own VM.

Basically, short of forking this project, I don't see a way to incorporate
the advanced features and still remain compatible with an OS that is over
20 years old.

On Sun, May 17, 2015 at 6:07 PM JK Benedict xenfomat...@outlook.com wrote:

 Excellent.

 Daily builds was just an example and I agree, daily builds would be
 overkill.

 The angle I was coming from is when core changes start to be made.  How
 will this affect the 100 packages when core, resource, and drivers are
 re-tooled?  DOS is heavily classic, solid... but some of the changes will
 affect the core.  I should have been more specific in unit testing and
 planning as various drivers, kernel, and kernel-deps change.

 Ah, Zip files -- the beauty of DOS.  I love Linux, but sometimes I just
 don't feel like writing code or compiling things :)

 Thanks for the reply and will research/download the wifi drivers as soon as
 possible.

 --jesse/jkbs

 -Original Message-
 From: Eric Auer [mailto:e.a...@jpberlin.de]
 Sent: Sunday, May 17, 2015 7:17 AM
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] Hello!


 Hi Jesse,

 Centralized documentation makes sense, but why would you put 100 packages
 in
 a centralized source code repository if 95 of them have not a single source
 code change in a whole year?

 And why do nightly builds of all 100 then? DOS heavily relies on classic
 software that simply is okay as it is and that no longer changes :-)

 As mentioned in the thread, there already is a considerable number of text
 and graphical web browsers. It probably is better to improve one of those
 instead of writing yet another browser.

 I agree that it is good to have a wishlist for shareware software that we
 would like to become free open source. Maybe the list could be done in wiki
 style?

 In general, if the hardware common for virtual machines is among the
 hardware for which there are drivers, there is no need to have separate
 development for virtualization and installation.

 We do already have a few VM-specific tools which are available :-) And
 there
 could be a download of a pre-installed VM, in case installation from ISO
 takes too much effort ;-)

 IPv6 is widely available already but is rarely required so I agree that DOS
 is not in a hurry.

 Regarding GPT, that is something that only needs some reasonably small
 amount of kernel code to support in passive scenarios. Having FDISK with
 GPT
 would be way more code, I guess. Most other tools never look at a partition
 table, so for them, this is not relevant.

 FileMaven basically does the LapLink thing, but it is closed source. It
 would be nice to have something open. On computers with network (LAN), it
 is
 better to use existing FTP, SCP, SMB or HTTP tools to copy files around.
 And
 there is a tool to copy files between VM and hypervisor.

 As mentioned elsewhere in this 

Re: [Freedos-devel] System Configuration Editor

[Antony Gordon]

I'm trying to build on what I've already done in the Pascal variant of
turbo vision.

Maybe I should learn the C++ variant instead.

On Wed, Apr 15, 2015, 2:53 PM Louis Santillan lpsan...@gmail.com wrote:

 As an FYI, many terminal/text-based editors (taking gnu nano as an
 example here) simply perform a regex match on the text and
 prefix/postfix the text with VT100/ANSI color codes matching the 16
 VT100/ANSI standard colors (which align to similar colors in the 16
 color EGA/VGA palette).  See examples of nano's regex's here [0][1].
 DOS doesn't do VT100/ANSI translation without something like
 ANSI.SYS/NANSI.SYS installed.

 This operation essentially does something like:

 REM Load Mouse=  GREYREM Load Mouse/GREY
 LH C:\DOS\DRIVER.EXE =  YELLOWLH/YELLOW C:\DOS

 [0]
 https://code.google.com/p/nanosyntax/source/browse/trunk/syntax-nanorc/php.nanorc
 [1]
 https://code.google.com/p/nanosyntax/source/browse/trunk/syntax-nanorc/js.nanorc

 On Wed, Apr 15, 2015 at 10:15 AM, Antony Gordon cuzint...@gmail.com
 wrote:
  In it's present version, it checks the system path and the boot drive and
  loads the following files:
AUTOEXEC.BAT
CONFIG.SYS
FDCONFIG.SYS
PROTOCOL.INI
WIN.INI
SYSTEM.INI
 
  FDCONFIG.SYS was added in 2003. I never added FDAUTO.BAT, although I
 could.
  I don't remember why either.
 
  I'll try to find someone on that project that may be willing to assist me
  with the syntax highlighting. I'm also looking at SETEDIT.
 
 
 
  On Wed, Apr 15, 2015 at 1:13 AM Rugxulo rugx...@gmail.com wrote:
 
  Hi,
 
  I was originally going to sit this one out because I didn't have
  anything worthwhile to mention, but 
 
  On Mon, Apr 13, 2015 at 10:41 AM, Antony Gordon cuzint...@gmail.com
  wrote:
  
   Jayden, I don't know if you have used Windows (I'm sure you have), but
   my
   program is essentially a DOS version of the System Configuration
 Editor
   that
   came with Windows 3.x.
 
  It's been many years since most of us used that. I don't even remember
  it, to be honest. I was weakly thinking of msconfig here.
 
   I wrote this program using TV on Turbo Pascal when I
   was working at CompUSA and customers would butcher Windows to the
 point
   of
   not booting. The program opened all the files at once so I could look
 at
   them all easily to see what was messed up.
 
  Okay, sounds good.
 
  A quick suggestion here would be to try to find more than just
  CONFIG.SYS and AUTOEXEC.BAT. Specifically, I'm thinking of
  FDCONFIG.SYS, FDAUTO.BAT, or similarly renamed files (e.g. DR-DOS
  7.03:  DCONFIG.SYS, AUTODOS7.BAT or whatever).
 
   At the time, the basic functionality was all I needed, so I didn't
 delve
   into the program more. Releasing it to the FreeDOS community in it's
   current
   form will probably get comments around the fact that it is a basic
 Turbo
   Vision app and I didn't do anything.
 
  Okay.
 
   I am looking for some examples on how to extend the Turbo Vision
 Editor
   (or
   FileEditor) object to include syntax highlighting. So far, I haven't
   been
   fruitful in my search.
 
  I've honestly never delved into TVision myself. I know you're using TP
  here, but IIRC even FreePascal has its own clone, FreeVision, which is
  used in their (TUI) IDE for DOS. They also have experimental 16-bit
  DOS target support, but I honestly don't know if FreeVision works
  there (yet). I'm not really in the loop on what's going on over there.
 
  But anyways, you may want to take a look at that. IIRC, their IDE
  supports syntax highlighting, so it may be something they added to FV.
 
  1). http://wiki.freepascal.org/Free_Vision
  2). http://www.freepascal.org/docs-html/user/usersu52.html
 
 
 
 --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
  Develop your own process in accordance with the BPMN 2 standard
  Learn Process modeling best practices with Bonita BPM through live
  exercises
  http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
  event?utm_
  source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
  ___
  Freedos-devel mailing list
  Freedos-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-devel
 
 
 
 --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
  Develop your own process in accordance with the BPMN 2 standard
  Learn Process modeling best practices with Bonita BPM through live
 exercises
  http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
  source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
  ___
  Freedos-devel mailing list
  Freedos-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] System Configuration Editor

[Antony Gordon]

In it's present version, it checks the system path and the boot drive and
loads the following files:
  AUTOEXEC.BAT
  CONFIG.SYS
  FDCONFIG.SYS
  PROTOCOL.INI
  WIN.INI
  SYSTEM.INI

FDCONFIG.SYS was added in 2003. I never added FDAUTO.BAT, although I could.
I don't remember why either.

I'll try to find someone on that project that may be willing to assist me
with the syntax highlighting. I'm also looking at SETEDIT.



On Wed, Apr 15, 2015 at 1:13 AM Rugxulo rugx...@gmail.com wrote:

 Hi,

 I was originally going to sit this one out because I didn't have
 anything worthwhile to mention, but 

 On Mon, Apr 13, 2015 at 10:41 AM, Antony Gordon cuzint...@gmail.com
 wrote:
 
  Jayden, I don't know if you have used Windows (I'm sure you have), but my
  program is essentially a DOS version of the System Configuration Editor
 that
  came with Windows 3.x.

 It's been many years since most of us used that. I don't even remember
 it, to be honest. I was weakly thinking of msconfig here.

  I wrote this program using TV on Turbo Pascal when I
  was working at CompUSA and customers would butcher Windows to the point
 of
  not booting. The program opened all the files at once so I could look at
  them all easily to see what was messed up.

 Okay, sounds good.

 A quick suggestion here would be to try to find more than just
 CONFIG.SYS and AUTOEXEC.BAT. Specifically, I'm thinking of
 FDCONFIG.SYS, FDAUTO.BAT, or similarly renamed files (e.g. DR-DOS
 7.03:  DCONFIG.SYS, AUTODOS7.BAT or whatever).

  At the time, the basic functionality was all I needed, so I didn't delve
  into the program more. Releasing it to the FreeDOS community in it's
 current
  form will probably get comments around the fact that it is a basic Turbo
  Vision app and I didn't do anything.

 Okay.

  I am looking for some examples on how to extend the Turbo Vision Editor
 (or
  FileEditor) object to include syntax highlighting. So far, I haven't been
  fruitful in my search.

 I've honestly never delved into TVision myself. I know you're using TP
 here, but IIRC even FreePascal has its own clone, FreeVision, which is
 used in their (TUI) IDE for DOS. They also have experimental 16-bit
 DOS target support, but I honestly don't know if FreeVision works
 there (yet). I'm not really in the loop on what's going on over there.

 But anyways, you may want to take a look at that. IIRC, their IDE
 supports syntax highlighting, so it may be something they added to FV.

 1). http://wiki.freepascal.org/Free_Vision
 2). http://www.freepascal.org/docs-html/user/usersu52.html


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] System Configuration Editor

[Antony Gordon]

Jayden, I don't know if you have used Windows (I'm sure you have), but my
program is essentially a DOS version of the System Configuration Editor
that came with Windows 3.x. I wrote this program using TV on Turbo Pascal
when I was working at CompUSA and customers would butcher Windows to the
point of not booting. The program opened all the files at once so I could
look at them all easily to see what was messed up.

At the time, the basic functionality was all I needed, so I didn't delve
into the program more. Releasing it to the FreeDOS community in it's
current form will probably get comments around the fact that it is a basic
Turbo Vision app and I didn't do anything.

I am looking for some examples on how to extend the Turbo Vision Editor (or
FileEditor) object to include syntax highlighting. So far, I haven't been
fruitful in my search.



On Mon, Apr 13, 2015 at 10:28 AM JAYDEN CHARBONNEAU 
jcharbonnea...@cpsge.org wrote:

 Editing configuration files is pretty straight forward when it comes to
 DOS,but,a GUI is nice.For syntax highlighting,I would do the following:
 Have a few default structures.Like function=[option] or function
 command [options]
 So when the user (I am not sure how your program works,so bear with me)
 types a FDCONFIG.SYS line,the program changes the text colors corresponding
 with the different values.The general syntax for FDCONFIG.SYS is
  function=[option].As for editing the AUTOEXEC.BAT file,it is basically
 a batch file,save the fact that it runs at the start.So if the user types
 LH program/exectuable,the function (LH) should be a specific color,and
 the option (executable) should be another.It is a matter of changing the
 colors of preset functions,using a general syntax.I hope this helps,as I
 have not programmed FreeDOS in at least a month/month and a half now.
 -Jayden


 On Sat, Apr 11, 2015 at 11:55 AM, Antony Gordon cuzint...@gmail.com
 wrote:

 I've dug up an old program that I used when I was a PC tech to edit
 configuration files (AUTOEXEC.BAT, CONFIG.SYS,  and the assortment of
 Windows 3.x config files).

 It's written in (Turbo) Pascal. Jim suggested I add syntax highlighting
 and features from MEM to it. I need some pointers on the syntax
 highlighting, however do you think this is good feature to have or tool?

 I'm open to suggestions for this.


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel



 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_

 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] System Configuration Editor

[Antony Gordon]

I've dug up an old program that I used when I was a PC tech to edit
configuration files (AUTOEXEC.BAT, CONFIG.SYS,  and the assortment of
Windows 3.x config files).

It's written in (Turbo) Pascal. Jim suggested I add syntax highlighting and
features from MEM to it. I need some pointers on the syntax highlighting,
however do you think this is good feature to have or tool?

I'm open to suggestions for this.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] New version of FreeDOS and backwards compatibility (RE: FreeDOS 1.2 and 2.0 roadmap discussion)

[Antony Gordon]

I was reading all the posts regarding the FreeDOS 2.0 roadmap and a
possible move to a 32-bit kernel.

So for the TL;DR crowd, I think the FreeDOS roadmap should include every
possiblity. Continue reading below if interested.

Now while my involvement has been pretty non-existent for nearly 5 years
(hotmail account hacked back in 2010), my opinion may or may not matter,
but this is what I think:

FreeDOS can, much like Linux exist in two flavors, possibly 3 if there is
enough interest and manpower:

  1. Classic 16-bit FreeDOS (current version)
  2. Hybrid 16-bit/32 bit FreeDOS can possibly implement the mode
switching done in Windows 95
  3. A Full 32-bit FreeDOS

When I think of DOS, especially within the scope of this project, I
envision being able to pull out my somewhat extensive collection of old
software, games, and development tools and relive a foregone era of (to me)
simplistic computer usage.

I see no need to end development of that current path. However, how much
real work is left on this current path? Most, if not all of the core DOS
commands are represented. There are several OSS and freeware utilities,
development tools, browsers, and add-ons that have added to the core
functionality of DOS. I've even downloaded some of these pieces when I was
using DOS 6.22 in VMWare a few years back and they work well there. This
team has done a great job.

I think options 2 and 3 offer some interesting alternatives that Microsoft
ad hoc'd into DOS. Imagine for example, on 386+ hardware being able to boot
directly into a flat memory mode and instead of kludging through XMS/EMS
and VCPI/DPMI? How about hardware virtualization and dynamic resource
allocation?

It's a big dream, and a coding nightmare, but even if it served no
additional purpose other than a PoC, sometimes building the next thing
can inspire something greater. I know there is presently 3rd party support
via Paragon for NTFS, but what if it was built-in to the OS? Imagine being
able to use FreeDOS (now a brand rather than just an OS) for emergency
recovery disks instead of the present method where the Emergency Disk does
some things in Linux and others in DOS?

Imagine FreeDOS as a VM that runs virtual 16-bit isolated instances of
FreeDOS? What can we achieve with that?
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] (no subject)

[Antony Gordon]

http://membres.multimania.fr/eaoyjpa/
  
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [RDA-L] Announcement of RDA publication date

[Antony Gordon]

Hi Diane,

Is there a mechanism for typo correction?  I was just casually looking
through the list and found RDA Form of Musical Notation  Tomic sol-fa

'Tomic' should read 'Tonic'

Best wishes,

Antony
-- 
Antony Gordon
Senior cataloguer/System administrator
British Library Sound Archive
96 Euston Road
London
NW1 2DB
United Kingdom

t: +44 20 7412 7412
f: +44 20 7412 7441
e: antony.gor...@bl.uk



On 4/12/09 14:14, Diane I. Hillmann d...@cornell.edu wrote:

 Folks:
 
 The vocabulary portions of RDA are essentially complete and available
 at: http://metadataregistry.org/rdabrowse.htm.  Updates to the
 vocabularies from the last JSC meeting in March have been integrated,
 and although we expect to see some minor editorial tweaks prior to the
 formal publication of the guidance text, what you see there is, we
 believe, ready for use and experimentation by those whose interest in
 RDA is in data rather than instruction.
 
 In addition, we are putting the finishing touches on an article about
 the process of building the RDF vocabularies which will appear in the
 January issue of DLib Magazine, due to be issued on January 15, when
 many of us will be in Boston for ALA Midwinter.  In the meantime, we
 encourage those who want to work with the vocabularies to feel free to
 contact us with questions or issues, either via email or the Registry
 feedback tab.
 
 Regards,
 Diane Hillmann
 Co-chair, DCMI/RDA Task Group
 
 Mary Ghikas wrote:
 
 RDA: Resource Description and Access will be published in June 2010.
 While we regret this delay in release of RDA, the transition from
 publication of AACR2 as a printed manual to release of RDA as a web
 based toolkit is a complex process with many interdependencies.
 
 The updated text of RDA incorporates recommendations from
 constituencies and other stakeholders approved at the JSC meeting
 earlier this year.  The revised text has been successfully loaded into
 the RDA database.  The product is currently undergoing thorough
 quality review and testing in preparation for release.
 
 We recognize that customers and prospective users of RDA need reliable
 and timely information for planning and budgeting.  We are confident
 that this revised deadline is a realistic target for publication of RDA.
 
  
 
 Pricing and purchasing information will be introduced at the time of
 the ALA Midwinter Meeting, 15-18 January 2010.
 
  
 
 Mary Ghikas,  Chair Committee of Principals
 Alan Danskin, Chair Joint Steering Committee for Development of RDA
 Don Chatham, Chair Co-publishers
 
  
 
  
 
  
 

[Freedos-devel] FreeDOS Installer

[Antony Gordon]

Who is currently working on this project? I have a couple of ideas I'd like to 
bounce off them.

 

 -Tony

_
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Rebooting without restarting the PC

[Antony Gordon]

You may have to take a page from the Win98 boot floppy, if possible. If you've 
ever watched it load, it cycles through several drivers trying to find the 
CD-ROM...especially in the SCSI territory.
 
 Date: Mon, 26 Mar 2007 12:35:38 +1000
 From: adam-nos...@servfire.net
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] Rebooting without restarting the PC
 
 I'm not sure why devload causes problems, shouldn't be running out of 
 memory (loading himem.exe and umbpci.sys), yeah, it's the MS Protocol 
 Manager (protman.dos), a slightly modified dis_pkt.dos from the original 
 boot disk, as well as whatever NDIS driver the card should use. All 
 loaded with classic DEVICE(HIGH) lines in config.sys and Ghost picks it 
 up. Do the same with DEVLOAD and it just doesn't detect them (can't 
 pick network options, only gives local).
 
 I'll play around with it a bit more, as well as looking at the NWDSK to 
 see how they're doing it. And yeah, I don't think METAKERN will do what 
 I want, but looks to be an interesting program in itself, so I'll keep 
 it in mind.
 
 Thanks
 
 Eric Auer wrote:
  Hi, you should have a look at how NWDSK does the
  network card detection and driver loading :-).
 
  One FreeDOS way to do it would be to use PCISLEEP
  to list all PCI devices of the network category
  and use the new SET /E (or so) feature to put the
  first output line of PCISLEEP into an environment
  variable. Then you would indeed use DEVLOAD... You
  did not say why devload caused problems. Do things
  work with classic DEVICE lines in config sys or
  does GHOST load things in a completely other way?
 
  To boot a kernel of your choice, you can have a
  look at METAKERN. You could modify it to make the
  choice depending on some PCI scan results. But I
  doubt that this is what you want. You always want
  the same kernel, just different config sys lines.
  As said, it should even be possible to figure out
  how to do all loading later with DEVLOAD. Do make
  sure that enough memory is free - it might be the
  case that using BASH for your which driver?
  decision takes too much memory, so DEVLOAD cannot
  give the driver enough memory to load properly.
 
  Eric
  
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

_
Rediscover Hotmail®: Get e-mail storage that grows with you. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage2_042009--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Projects in need of a maintainer?

[Antony Gordon]

Probably the best idea would be to have multiple script engines. Existing DOS 
apps use .BAT kinda like PowerShell in W2K. It would even be possible to use 
BASIC (or any other programming language). Default to .BAT, but the script 
engine could be swapped out...remember overlays?


-Original Message-
From: Alain M.
Sent: 4/15/2009 2:44:31 AM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] Projects in need of a maintainer?

lyricalnanoha escreveu:

 Though, a truly free 16-bit bash or ash would be nice.

Why do you need it to be 16 bit. DOS's programs can be 32 bits without
any problem.

How many 286 PC are there still around? Most are dead, but DOS in new
machines is alive just fine :)

Alain

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Projects in need of a maintainer?

[Antony Gordon]

I didn't think JP Software had 'abandoned' 4DOS...

 Date: Fri, 3 Apr 2009 18:01:13 +0200
 From: michael_reichenb...@freenet.de
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] Projects in need of a maintainer?
 
 Well, there is a list more or less up to date.
 http://www.freedos.org/freedos/software/
 
 There are many programs with no development ongoing.
 - DOSLFN
 - Arachne
 - FreeDOS installer
 - 4dos
 - freecom
 - tridos (multitasking, not a freedos packet but interesting, licence
 unclear (free?),
 http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.TripleDOS)
 - freedos kernel
 - ...
 
 Perhaps it's more easy to make a list where development is ongoing?
 
 -mr
 
 Bruce Axtens schrieb:
  G'day everyone,
  
  Is there a list of projects and maintainers anywhere? What projects are
  currently without a developer / maintainer?
  
  Kind regards,
  Bruce.
  
  P.S. If this has already been covered in that long thread about
  volunteering, my embarrassed apologies in advance.
  
  
  
  
  
  --
  
  
  
  
  ___
  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

_
Rediscover Hotmail®: Get quick friend updates right in your inbox. 
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: Please i need your help

[Antony Gordon]

Thanks. I spotted that and have emailed Marjorie to let her know that her
mail list has been compromised.

Best wishes,

Antony Gordon


On 19/3/09 10:08, Makx Dekkers m...@makxdekkers.com wrote:

 Please be aware this is a scam, identical to one that was posted here:
 http://419.bittenus.com/7/9/empoweringyouthtofightracismhivaidspovertyandlacko
 feducation.htm.
  
 Kind regards, Makx Dekkers.
 
  
  
 
  From: List for discussion on Resource Description and  Access (RDA)
 [mailto:dc-...@jiscmail.ac.uk] On Behalf Of Marjorie  Bloss
 Sent: Thursday, March 19, 2009 10:59 AM
 To:  DC-RDA@JISCMAIL.AC.UK
 Subject: [DC-RDA] Please i need your  help
 
  
 I am in a hurry writing you this message, i don't have much time on  the pc
 here, so i have to brief you my present situation which requires your  urgent
 response. Actually, I had a trip to Malaysia for a program called
 Empowering Youth to Fight Racism, HIV/AIDS, Poverty and Lack of Education,
 the program is taking place in three major countries in Asia which are
 Taiwan,  Singapore and Malaysia. But unfortunately for me, my little bag
 where my  money, passport, document's and other valuable things got stolen at
 the hotel  where i lodged due to a robbery incident that happened in the
 hotel. I have  been so restless since last night, the present condition that
 i found myself  is very hard for me to explain, I am really stranded here
 because i have been  without any money, i am even owing the hotel here as
 well, moreover the  Hotel's telephone lines here got disconnected by the
 robbers and they are  trying to get them fixed back. I have access to only
 emails at the library  because they also took my cell phone which i have all
 my contacts. I am now  owing a hotel bill of $1,400 and they wanted me to pay
 the bill soon. I need  this help from you urgently to help me back home, I
 need you to help me with  the hotel bill and i will also need $2,000 to feed
 and help myself back home.  So please can you help me with a sum of $3,400
 USD to sort out my problems  here. I am sending you this email from the city
 Library, I will appreciate  what so ever you can afford to send me for now
 and I promise to pay back your  money as soon as i return home. So please use
 the details of one of the hotel  managers below to send the money to me
 through Western Union money transfer  because that is the only way i could be
 able to get it fast and leave since he  has a valid ID to pick up the money
 for me from the western union office here.  These are the details below
   
 Name: Asantewaa Faustina  Adwoa
 Address: 29B Jalan Loke Yew, Bandar Melaka, Malaysia
 Text  question: To whom
 Answer: Marjorie Bloss
  
 After you have  send the money, email to me the western union money transfer
 control number or  you can attach and forward to me the western union money
 transfer receipt so  that i can pick up the money fast and leave.
  
 Thanks and get back  to me soon.
 
 Cordially,
  
 Marjorie 
 

Re: [Freedos-devel] compressed FAT filesystems

[Antony Gordon]

I've read all the posts, now lets look at what DriveSpace/DoubleSpace actually 
did...

You take a hard drive of x capacity, analyze the free space, a 'CVF' 
(Compressed Volume File) with variable cluster size, move the files on the disk 
into the newly created CVF file, compressing them in the process. once the 
files have been moved into the CVF, it is mounted as a drive letter,  and if 
the file extension is .000, the drive letter is swapped with the host drive. 
accessed through a block device that connects to a MRCI (Microsoft Realtime 
Compression Interface) server. 

When I read about CVF and MRCI in the DOS 6 Programmer's Reference (Microsoft), 
I thought that there had to be a much simpler way to implement this. Especially 
after the lawsuit between DOS 6.0 and DriveSpace's appearance in DOS 6.22. Of 
course, other things pressing I never really sat down to come up with 
something, by that time Windows 95 was on the horizon, and you could at least 
get up to an 800MB hard drive, and Disk Manager could help you use it all.

To effect the same principle in FreeDOS, a real-time compression interface 
would have to be clean room designed based on the known aspects of 
DBLSPACE/DRVSPACE integration with MS-DOS (or Stacker's integration with 
MS/PC-DOS), perhaps in the process figure out how we can improve the design,  
there is no need to be compatible, offer existing DBLSPACE/DRVSPACE users a 
reliable migrate path and go from there. 





 Date: Fri, 21 Mar 2008 14:08:34 -0430
 From: [EMAIL PROTECTED]
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] compressed FAT filesystems
 
 Would be OK something like a tar file, that includes time, date and 
 attributes for each file.
 And may be compressed if needed.
 
 +-+-+-+-+-+-+-+
 Marco A. Achury
 Tel: +58-(212)-6158777
 Cel: +58-(414)-3142282
 Fax: +58-(212)-2410828
 Skype: marcoachury
 www.geocities.com/marcoachury
 
 
 
 Imre Leber escribió:
  But then again,
 
  Do you realy need a file system if it is read only. You could just as well 
  use a table in the front that lists file names with path, and copy all data 
  after it. No need to have anything remotely like FAT and the like.
 
  Just:
 
  \temp\file1 start at 0
  \temp\file2 start at 1000
 
  0: data for \temp\file1
  1000: data for \temp\file2
 
  Not realy a file sytem, but should about the same.
 
  Imre
 

 
 
 
 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

_
Watch “Cause Effect,” a show about real people making a real difference.  Learn 
more.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] compressed FAT filesystems

[Antony Gordon]

So the next step is file system. Well we already know FAT, like Microsoft, we 
can  bitmap the CVF allocation table, 0 meaning unused and 1 meaning used. The 
largest capacity of the BitFAT (assuming a 512MB CVF) is 128K( following MS 
standard).

Now according to the MS-DOS programmers reference, the MDFAT (or DoubleSpace 
File Allocation Table) consists of a series of 4 byte entries. They map FAT 
clusters to sectors in the sector heap. There is one entry for each cluster on 
the compressed drive. The entries specify the location of the sectors in the 
heap that contain the data for the cluster and flags to indicate status (i.e., 
in use, compressed, and the size of the cluster). MDFAT is a function of the 
max capacity of the CVF, The largest capacity is 512MB for a CVF so the largest 
MDFAT size is 256K
   
So, 384K in accounting using the Microsoft method, assuming direct 
implementation.


 From: [EMAIL PROTECTED]
 To: freedos-devel@lists.sourceforge.net
 Date: Fri, 28 Mar 2008 12:13:48 +
 Subject: Re: [Freedos-devel] compressed FAT filesystems
 
 Actually the sources seem to already contain zlib. 
 
 So I assume we almost have a working doublespace already. But somebody ought 
 to have a look at it to make it complete/fix the bugs.
 
 Imre
 
 - Oorspronkelijk bericht -
 Van: Imre Leber [mailto:[EMAIL PROTECTED]
 Verzonden: vrijdag, maart 28, 2008 01:05 PM
 Aan: freedos-devel@lists.sourceforge.net
 Onderwerp: Re: [Freedos-devel] compressed FAT filesystems
 
 
 Actualy like Eric, privately, pointed out we already have a driver to treat 
 a file as a volume, nl. SHSUFDRV.
 
 However, the problem is not the driver, but what kind of file system should 
 be used by such driver to make it compressed.
 
 We might just take SHSUFDRV and, like doublespace, assume that anything that 
 is on it is compressed. Then add a compressor like LZO to 
 compress/decompress everything going in and out. That way the file system 
 does not even need to be changed.
 
 Imre 
 
 
 - Oorspronkelijk bericht -
 Van: Antony Gordon [mailto:[EMAIL PROTECTED]
 Verzonden: vrijdag, maart 28, 2008 10:11 AM
 Aan: freedos-devel@lists.sourceforge.net
 Onderwerp: Re: [Freedos-devel] compressed FAT filesystems
 
 I've read all the posts, now lets look at what DriveSpace/DoubleSpace 
 actually did...
 
 You take a hard drive of x capacity, analyze the free space, a 'CVF' 
 (Compressed Volume File) with variable cluster size, move the files on the 
 disk into the newly created CVF file, compressing them in the process. once 
 the files have been moved into the CVF, it is mounted as a drive letter,  
 and if the file extension is .000, the drive letter is swapped with the 
 host drive. accessed through a block device that connects to a MRCI 
 (Microsoft Realtime Compression Interface) server. 
 
 When I read about CVF and MRCI in the DOS 6 Programmer's Reference 
 (Microsoft), I thought that there had to be a much simpler way to implement 
 this. Especially after the lawsuit between DOS 6.0 and DriveSpace's 
 appearance in DOS 6.22. Of course, other things pressing I never really sat 
 down to come up with something, by that time Windows 95 was on the horizon, 
 and you could at least get up to an 800MB hard drive, and Disk Manager 
 could help you use it all.
 
 To effect the same principle in FreeDOS, a real-time compression interface 
 would have to be clean room designed based on the known aspects of 
 DBLSPACE/DRVSPACE integration with MS-DOS (or Stacker's integration with 
 MS/PC-DOS), perhaps in the process figure out how we can improve the 
 design,  there is no need to be compatible, offer existing 
 DBLSPACE/DRVSPACE users a reliable migrate path and go from there. 
 
 
 
 
 
  Date: Fri, 21 Mar 2008 14:08:34 -0430
  From: [EMAIL PROTECTED]
  To: freedos-devel@lists.sourceforge.net
  Subject: Re: [Freedos-devel] compressed FAT filesystems
  
  Would be OK something like a tar file, that includes time, date and 
  attributes for each file.
  And may be compressed if needed.
  
  +-+-+-+-+-+-+-+
  Marco A. Achury
  Tel: +58-(212)-6158777
  Cel: +58-(414)-3142282
  Fax: +58-(212)-2410828
  Skype: marcoachury
  www.geocities.com/marcoachury
  
  
  
  Imre Leber escribió:
   But then again,
  
   Do you realy need a file system if it is read only. You could just as 
   well use a table in the front that lists file names with path, and copy 
   all data after it. No need to have anything remotely like FAT and the 
   like.
  
   Just:
  
   \temp\file1 start at 0
   \temp\file2 start at 1000
  
   0: data for \temp\file1
   1000: data for \temp\file2
  
   Not realy a file sytem, but should about the same.
  
   Imre
  
 
  
  
  
  -
  This SF.net email is sponsored by: Microsoft
  Defy all challenges. Microsoft(R) Visual Studio 2008.
  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01

Re: [Freedos-devel] compressed FAT filesystems

[Antony Gordon]

I would think that the information contained in the MS-DOS 6 Programmers 
reference is free of any restrictions related to that lawsuit. 

An initial clean room design would allow us to imitate the core functionality 
of DoubleSpace. This would allow us to read the compressed volume files, if for 
no other purpose than compatibility. The next step would be to improve the 
design where it is lacking. 

As far as writing to the file system, DoubleSpace allocates the BitFAT, MDFAT 
and FAT to maximum capacity. The resulting CVF file is maxxed for the drive in 
question, even though in most cases, the CVF will not be large enough to 
require the maximum capacity of these structures. This preallocation allows for 
growing and shrinking the CVF file very quickly. 

The other alternative might involve some sort of GZIP done on each file, so 
there is an 'invisible' decompression each time a file is accessed, and a 
decompression when the file is moved from a volume designated 'compressed' to a 
volume designated 'not compressed'. We can then use the reserved field in the 
BPB to designate a compressed file system or add to the list of FileSystemTypes 
at the end of the BPB (i.e., FAT12C, FAT16C, FAT32C).

I don't see how writing to the CVF would be a problem, since all the 'disk' 
writes would go through the BLOCK device driver, and since the driver is in 
effect a 'TSR' of sorts, it can take over Int 13h, portions of Int 21h, Int 
25h, and Int 26h (which comprise most of how DOS applications access the disk).

-T


 Date: Fri, 28 Mar 2008 20:27:50 +0100
 From: [EMAIL PROTECTED]
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] compressed FAT filesystems
 
 
 Hi Antony,
 
 for now, I would not recommend to try to clone any MS
 compressed filesystem. Remember that they themselves
 have had licensing issues with their own compressed
 filesystem. One thing which makes doublespace and co
 complex is their ability to WRITE to the filesystem
 while it is mounted / in use. Let me explain my own
 suggestion for a simpler system:
 
 - replace the 2nd FAT by an array of cluster sizes (FAT16)
   or cluster offsets (FAT32). The latter has better speed
   but for the former, you can buffer some intermediate
   offsets in RAM (eg offset of every 256th cluster)
 
 - clusters which have same size as uncompressed ones, are
   uncompressed clusters. Simple. Compressed clusters should
   be stored at offsets which are multiples of the sector
   size, to keep access times low and to simplify access...
 
 - clusters which have size 0 are not in use. Simple.
 
 - either you allow no writing, or if you write, you only
   allow writes for which the compressed cluster must not
   grow. If a write violates both constraints, you have to
   change the FAT to use a fresh cluster at the current end
   of the compressed filesystem. Such clusters ARE allowed
   to grow, but only if there are no used clusters at any
   later offset in the compressed filesystem.
 
 - if you allow writing, do not actually shrink compressed
   clusters. Of course this can cause fragmentation. You
   can have a tool which collects all unused clusters of
   nonzero size and recycles the space they take, but this
   would happen while the filesystem is not active / mounted.
 
 - you could use heuristics on initial filesystem creation /
   compression, for example to avoid compression of directories
   (this makes it easier for the directories to grow later).
 
 
 
 I hope that such an implementation would be quite straigth-
 forward and have good performance for read-only access. It
 can be a FAT block device for DOS as output and can take
 a file, partition or other data source as input. It would
 do the following transformations:
 
 - first FAT and boot sector stay as they are
 
 - access to 2nd FAT is redirected to first FAT
 
 - access to clusters is redirected by reading the table
   explained above (which is stored at the location of the
   former 2nd FAT) to find out the actual starting sector /
   offset of the cluster in the compressed filesystem, and
   then reading and decompressing that cluster and returning
   the decompressed contents. Writing will be more complex
   but is not needed for a first implementation.
 
 - note that clusters are ALWAYS in strict linear order,
   even with the suggested method which would allow writes
   to the filesystem as described above. That avoids any
   need for extra redirections like cluster heaps :-).
 
 
 
 You also need a tool for initial compression / creation of
 such a compressed filesystem. Luckily it can operate in the
 same space as the uncompressed filesystem, replacing it...
 
 - walk through all clusters, and copy them from their normal
   version into their compressed version. As clusters never
   are bigger than in uncompressed state, this is as easy as
   successively overwriting all clusters with compressed data
   and filling the former 2nd FAT data area with the size info
   or 

Preferred title ???

[Antony Gordon]

I like the German expressions which prompts me to wonder if 'Devised title'
or 'Constructed title' would capture in English the essence of
Ansetzungsform ... and also convey what these titles really are.


Antony Gordon
British Library Sound Archive



On 5/2/08 09:12, Bernhard Eversberg [EMAIL PROTECTED] wrote:


 The newly invented preferred ... is also no good. Preferred by
 whom? You certainly can't use it in an OPAC help text. Preferred
 names are frequently artificial and therefore not preferred anywhere
 outside catalogdom. Say standard ... and non-standard (form of) ...
 instead, at least at the interface.
 In German, we have had Ansetzungsform (something like made-up form)
 for the catalog standard forms of names and titles, and
 Verweisungsform (reference form) for all the others. I'd much prefer
 to stick with our words for the impending RDA translation. Why don't
 we put them on offer as loanwords, at no charge? You also say things
 like Weltanschauung or Wanderlust and what not.

 B.Eversberg


**


Experience the British Library online at www.bl.uk


The British Library's new interactive Annual Report and Accounts 2006/07 : 
www.bl.uk/mylibrary


Help the British Library conserve the world's knowledge. Adopt a Book. 
www.bl.uk/adoptabook


The Library's St Pancras site is WiFi - enabled


*


The information contained in this e-mail is confidential and may be legally 
privileged. It is intended for the addressee(s) only. If you are not the 
intended recipient, please delete this e-mail and notify the [EMAIL PROTECTED] 
: The contents of this e-mail must not be disclosed or copied without the 
sender's consent.


The statements and opinions expressed in this message are those of the author 
and do not necessarily reflect those of the British Library. The British 
Library does not take any responsibility for the views of the author.


*

Re: [Freedos-devel] FreeDOS directory standard (1.1?)

[Antony Gordon]

Well, MSDOS.SYS (which some wierd DOS programs actually look for) could be an 
INI file repository of sorts that could store this information. FreeCOM could 
parse it as a 'default' environment ahead of AUTOEXEC.BAT and FDAUTO.BAT. So an 
F5 bootup would give you a basic DOS path and a SYSTEMROOT variable. 
 
-T



 Date: Wed, 9 Jan 2008 06:37:59 +0300 From: [EMAIL PROTECTED] To: 
 freedos-devel@lists.sourceforge.net Subject: Re: [Freedos-devel] FreeDOS 
 directory standard (1.1?)  Hi!  8-Янв-2008 00:05 [EMAIL PROTECTED] 
 (Antony Gordon) wrote to freedos-devel@lists.sourceforge.net:  AG In 
 FreeDOS 1.1 (or whatever) once the directories are finalized, a system AG 
 variable can be declared in the OS (at the master environment level) like in 
 AG Windows NT/2000/XP called SYSTEMROOT.  1. In MS-DOS, all variables are 
 defined by (replaceable) shell, not by OS itself.  2. To declare variable, 
 which points somewhere, OS/shell should know where this somewhere resides. 
 Unless you explicitly specify this placement, OS/shell will NOT know this 
 information. But how this specify will differ from non-OS, manual set in 
 some batch file (autoexec.bat or some other)?  AG On my Windows machine 
 it's C:\WINDOWS. AG For FreeDOS it can be C:\FDOS.  What happen, if user 
 installs FreeDOS into other directory? BTW, in Win9x, paths are specified in 
 the MSDOS.SYS.  
 - 
 Check out the new SourceForge.net Marketplace. It's the best place to buy or 
 sell services for just about anything Open Source. 
 http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace 
 ___ Freedos-devel mailing list 
 Freedos-devel@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
_
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Installed Application Database Hypothesis

[Antony Gordon]

Hypothesis:
 
Implementing an Installed Application Database along with an associated install 
API would make installing applications easier (perhaps somewhat akin to 
Windows). 
 
What I've learned:
Each application comes packaged in a ZIP file that contains a text file with a 
list of conflicting applications, prerequisite applications, and suggested 
configuration settings/memory requirements. Does the present installer have a 
means of locating said conflicting applications and checking prerequisites?
 
What I am suggesting:
Nothing overly complex, but perhaps a flat file database that can list 
applications as they are installed. I looked at the INSTALL.LOG file and the 
options of FDPKG. What I would be suggesting would be something along these 
lines
 
C:\PKGMGR    just chose that since FDPKG was in use
FreeDOS Package Manager v x.xx
 
 
File Maintenance Options Help
 
Currently installed packages/applications
 
   + FreeDOS 1.0 
   + FreeDOS GEM  repackaged for PKGMGR but basically Shane's OpenGEM
   + Random Application
 
Use arrow keys to select pages
 
File Menu
  Exit (Obvious)
Maintenance Menu 
   Change/Remove Application (existing apps on the computer)
   Install New Program (even if it is not a PKGMGR installer, this can track 
the changes for later removal)
   Add/Remove FreeDOS components (Devel tools, Language support, etc)
Options Menu
   Tracking (track 3rd party installs on/off)
Basically log the changes each install makes to config.sys autoexec.bat to 
facilitate easier removal (basically makes a copy before install and creates a 
DIFF file)
Help Menu
  Self explanatory
 
I think the hardest part would be tracking the changes on 
autoexec.bat/config.sys which I think would require PERL or awk to process.
 
_
Share life as it happens with the new Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS directory standard (1.1?)

[Antony Gordon]

In FreeDOS 1.1 (or whatever) once the directories are finalized, a system 
variable can be declared in the OS (at the master environment level) like in 
Windows NT/2000/XP called SYSTEMROOT. On my Windows machine it's C:\WINDOWS. 
For FreeDOS it can be C:\FDOS. Then the other directories (with the exception 
of \APPS and \SOURCE) could but placed under there.

Are there plans in the works to standardize the install process? Some sort of 
API of routines, or skeletal installer that would use these directory rules. 
With all this discussion, it would probably be easier to put together an 
installer API for FreeDOS that can process a script to install apps to make 
this setup work better. 

-T

 Date: Sun, 6 Jan 2008 12:08:00 -0600
 From: [EMAIL PROTECTED]
 To: freedos-devel@lists.sourceforge.net
 Subject: Re: [Freedos-devel] FreeDOS directory standard (1.1?)
 
 On 1/5/08, Eric Auer [EMAIL PROTECTED] wrote:
 
  Hi!
 
   LIB for libraries. We never really defined a lib before because
   FreeDOS doesn't support the shared-library model...
 
  I would put those in BIN if dynamic and in SOURCE if used to compile
 
 I don't think under BIN if dynamic is a good idea. It mixes too much
 non-user-executable stuff in BIN. BIN needs to be for user programs
 only. If there is ever a dynamic lib concept, it should be in its own
 LIB.
 
 But yes, looking back at the discussion, if the libraries are used to
 compile, they should go under the package name in SOURCE (same as
 normal practices.)
 
 
   INCLUDE would be a good place for any *.h files that are associated
   with the libraries in LIB. But I don't think I'd put them under LIB.
   This should be a top-level directory.
 
  I would put those in SOURCE
 
  Actually I would not even use SOURCE but the subdirectory
  of SOURCE used by this package. After all, dependencies
  should know on which package they depend...
 
 As above, if used to compile, they should go under the package name in
 SOURCE (same as normal practices.)
 
 
 
 To modify my original post with the above:
 
 
 BIN
 Binaries, such as exe and com files. And if a program is made
 of of a bat file, then that goes in BIN too. Programs only.
 
 DOC
 Package documentation, with each package having its own directory such
 as DOC\INSTALL or DOC\4DOS, etc. This allows a complicated package
 such as a compiler or programmable editor to include more than just a
 readme (perhaps sample code for the compiler, technical notes or other
 references, etc.)
 
 HELP
 The help files. I think the original FD directory structure was
 based on a UNIX-like directory tree, and the HELP directory was
 originally going to have subdirectories a-la UNIX 'man' sections:
 HELP\1, HELP\2, ... But that didn't make much sense in the end, so
 only the top-level HELP directory stuck. Later, we added an html-based
 Help program, so that needs its own directory for html files. I don't
 use the htmlHelp program, but it looks like the top directory for its
 files is in HELP\EN (i.e. the language.) That makes sense, I suppose.
 
 SOURCE
 For source code (when installed) with each package having its
 own directory. (Source package [spkg] only.)
 
 LIB
 If there is ever a dynamic lib concept, it should be in its own LIB.
 (future concept)
 
 
 
 
 -jh
 
 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel

_
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: RDA to FRBR mapping

[Antony Gordon]

 J. McRee Elrod schrieb:

 I doubt whether most will ever grasp the distinction between
 manifestation and expression.  I think both terms should be tossed for
 edition, which has served us well.

 Cheers!
 Why indeed not say edition instead of expression, and where
 it is important to differentiate between textually identical
 versions in different formats, just say versions. Might be
 a tad easier to grasp. Less flashy, though, but that's something
 most in the trade may be well prepared to put up with.


Sorry, but that's rather a bibliocentric view.  Edition makes no sense for
sound recordings where expression represents a new recording of a work,
governed by performers, place and date of recording -- and all three might
be required to differentiate  two recordings of a work without amibiguity.


Expression seems to me to be a serviceable format-neutral word.  I agree
that it's more difficult to disentangle the concepts of expression and
manifestation in the universe of printed items but it's perfectly clear in
the universe of sound recordings.  A recording = expression is published on
a CD = manifestation 1 and later published on a different CD = manifestation
2 together with different expressions of the same or other works.


Antony
--
Antony Gordon
Senior cataloguer/System administrator
British Library Sound Archive
96 Euston Road
London
NW1 2DB
UK


tel: +44 20 7412 7412
fax: +44 20 7412 7441
email: [EMAIL PROTECTED]


**


Experience the British Library online at www.bl.uk


Help the British Library conserve the world's knowledge. Adopt a Book. 
www.bl.uk/adoptabook


The Library's St Pancras site is WiFi - enabled


*


The information contained in this e-mail is confidential and may be legally 
privileged. It is intended for the addressee(s) only. If you are not the 
intended recipient, please delete this e-mail and notify the [EMAIL PROTECTED] 
: The contents of this e-mail must not be disclosed or copied without the 
sender's consent.


The statements and opinions expressed in this message are those of the author 
and do not necessarily reflect those of the British Library. The British 
Library does not take any responsibility for the views of the author.


*

Re: [RDA] Re: FRBR and prime entry: What about relation ships

[Antony Gordon]

I'm definitely with Bernhard here.  If we don't at least aspire to
perfection -- which encompasses practicality and utility -- how can we hope
to get anywhere close.
--
Antony Gordon
Senior cataloguer/System administrator
British Library Sound Archive
22 Micawber Street
London
N1 7TB
UK


tel: +44 20 7412 7412
fax: +44 20 7412 7413
email: [EMAIL PROTECTED]


 From: Mike Tribby [EMAIL PROTECTED]
 Reply-To: Resource Description and Access / Resource Description and Access
 RDA-L@INFOSERV.NLC-BNC.CA
 Date: Tue, 18 Jul 2006 08:07:36 -0500
 To: RDA-L@INFOSERV.NLC-BNC.CA
 Subject: Re: [RDA-L] [RDA] Re: FRBR and prime entry: What about relation
 ships

 In response to Hal Cain, Bernhard Eversberg schrieb:
 Well, if working on an entirely new code is not the time of aspiring to
 perfection, then when will that time ever come?

 Aspiring to perfection? How about aspiring to practicality and utility? If
 we're literally aspiring to perfection in all things for all metadata
 communities (whoever these communities are and whether or not they're
 desperately waiting for library catalogers to light their ways), the
 proposed 2008 pub date for RDA is ridiculously out of the question.


 Mike Tribby
 Senior Cataloger
 Quality Books Inc.
 The Best of America's Independent Presses

 mailto:[EMAIL PROTECTED]


**


Experience the British Library online at www.bl.uk


Help the British Library conserve the world's knowledge. Adopt a Book. 
www.bl.uk/adoptabook


The Library's St Pancras site is WiFi - enabled


*


The information contained in this e-mail is confidential and may be legally 
privileged. It is intended for the addressee(s) only. If you are not the 
intended recipient, please delete this e-mail and notify the [EMAIL PROTECTED] 
: The contents of this e-mail must not be disclosed or copied without the 
sender's consent.


The statements and opinions expressed in this message are those of the author 
and do not necessarily reflect those of the British Library. The British 
Library does not take any responsibility for the views of the author.


*