Re: [Freedos-devel] Calling interrupts when iddle

> It's not that I want to stop, but just be nice to others. If they > don't exist, I assume it'll get back to me fast. Not halting will unnecessarily spin through CPU cycles and energy while the program is idle. Halting instead is less costly. Regards, -

Re: [Freedos-devel] About Bret's license

> Don't forget > http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1 for > European developers, because it's compatible with GNU GPL v2 and is > available in 22 languages. I think you're allowed to use it even if you're no European citizen, aren't you? Still, isn't it GPL v3 incompa

[Freedos-devel] About Bret's license

As this is about software licensing issues, I want to state here: I'm not a lawyer and this e-mail does not contain any legal advice. Oh, and if you're easily annoyed by licensing issues then you might prefer not to read this thread. In "FreeDOS 1.1 (again)", dos386 wrote: > Bret's USBDOS (

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

CM>RBIL> on DOS versions which do not support the FAT32 calls, this function CM>RBIL> returns CF clear/AL=00h (which is the DOS v1+ method for reporting CM>RBIL> unimplemented functions) CM> CM> You have to be careful about this criterion. My observations indicate CM> that CM> DOS versions t

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

> 1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged, > then the kernel is not aware of the 21.73xx FAT32 functions. Why test another function (which is really undocumented at that, so unlikely to be implemented properly in other DOS versions) to determine whether function 7303h is sup

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

> RBIL is pretty much it (right? or some "undocumented" book, perhaps?), > and it doesn't say much that hasn't already been mentioned. > > http://www.delorie.com/djgpp/doc/rbinter/id/40/32.html For completeness, here's the original site (right?): http://www.cs.cmu.edu/~ralf/files.html The book

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

> I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and > 16-bit > regs). > > I cannot find any documentation on the functions that freedos uses for > its > filesystem functions, like getting filesystem vo

Re: [Freedos-devel] ASCII to unicode table

> You would need an Input Method driver which lets you type > complex key sequences or combinations to type in a language > which has more than the usual few dozen chars of alphabet. Yes. The (keyboard) input and (screen) output appears to be the most complicated exercise here. DBCS or UTF-8 sup

Re: [Freedos-devel] ASCII to unicode table

> Combined with, for example, a UTF-8 enabled Super-NANSI to > make the step from strings to their display, of course. The > problem would be loss of "ASCII" art block graphics in apps > which are not using Unicode. But that happens for some code pages anyway. (For example, CPs 858 and 850 drop

Re: [Freedos-devel] ASCII to unicode table

> I think your attitude is not very constructive. We have to keep this > idea as simple as possible or nobody implements it. I think some of that is important, even if you only want to implement a simple translation. Besides, of course it isn't very constructive to *discuss* an idea. Go use

Re: [Freedos-devel] ASCII to unicode table

> UniCode is not the panacea it's purported to be. No, but you have to give them that it's certainly an improvement. >> UTF-8 is independent of byte-order. The exact encoding (and byte-order) >> should always either be implicit (in the interface's or format's >> definition) or be marked in some w

Re: [Freedos-devel] ASCII to unicode table

> Should the translation be "accurate" or should it be "useful"? I think it should be accurate for file systems. Such a "useful" translation is a good concept for displaying output (maybe even that of the DIR command) but not for actually working with the file system. Keyboard input can't ma

Re: [Freedos-devel] ASCII to unicode table

> Now programs do it self by looking into own datafiles with .TBL > extension. Look at DOSLFN or Volkov commander 4.99. They have few files > like cp852uni.tbl, cp866uni.tbl and so on. > It is a very good solution but problem is that here is no way now how to > determine which file should be

Re: [Freedos-devel] C/C++ BIOS backup

> I read through the boot code and didn't see and specifics written > about where the system bios is stored in memory. The boot code uses the software interrupts associated with the BIOS to call BIOS functions. For example, interrupt 16h (BIOS keyboard functions) and interrupt 13h (BIOS disk a

Re: [Freedos-devel] C/C++ BIOS backup

> each bios is going to be different. what is common between the BIOSes > is the > int21H functions, which are outlined here: > http://hdebruijn.soo.dto.tudelft.nl/newpage/interupt/out-0100.htm Interrupt 21h is provided by DOS. The list you link to contains BIOS functions as well as DOS funct

Re: [Freedos-devel] [Freedos-user] svn failure

> How can I deal with an improper file name? This is probably a question you should rather ask the TortoiseSVN guys, but I found the relevant section of their FAQ: http://tortoisesvn.tigris.org/faq.html#cantmove It links to this, which is a workaround for improper file names but requires wri

Re: [Freedos-devel] [Freedos-user] Regarding dot and dotdot entries

DOS386 (on Freedos-user): > [...] the great "." and ".." AKA "dot" and "dotdot" entries are > inherently > useless and many DOS and non-DOS kernels do ignore them mostly or fully. I think that there are drivers/systems that will just expect both entries to reside in the first two directory ent

Re: [Freedos-devel] Standardized development tools

> Now, I will have to disclose that I have not tried jwasm. There's no > reason > behind that except for laziness. Having learned nasm and finding it met > my > needs, I just didn't try jwasm because I didn't want to learn it. So, I > cannot compare nasm to it. I can't really compare NASM t

Re: [Freedos-devel] Standardized development tools

> I'm thinking it would be a good idea to standardize on one C/C++ compiler > for the project. [...] I would be interested in your opinions about standardizing one or several assemblers for the project. I think that the kernel and FreeCOM assembler source files currently use NASM, a 2-clause B

Re: [Freedos-devel] New Distro: checking everything

Hi Alain, > JEMMEX crashes XMSDSK, so it could crash other programs and I did no > further test. I often use both together without issues. Maybe you could report the bug that you experience? When did you test JemmEx? Regards, Christian -

Re: [Freedos-devel] Pre-presentation of a project

> I'd better put up the code. I don't want to be all theory up here. I'm fine with theoretical discussions. > Even though you first said I shouldn't change my project just because > some people may not like it, and I agree, I also believe it is very > important to check with you guys and to b

Re: [Freedos-devel] Pre-presentation of a project

>I'm thinking that I can perfectly get an interrupt, without having to > reserve one. That is, a function under AMIS could tell the driver to get > hooked at a certain interrupt chosen by the caller. This would be more > comfortable for the high-level programmer than having to call an >

Re: [Freedos-devel] Pre-presentation of a project

>The reason why I've been considering a brand new interrupt is because > the driver is not supposed to be single-purposed. This does not convince me. > What I want to create is a new standard interface where support for new > features can be hooked in a very tidy and organised way. I thin

Re: [Freedos-devel] Pre-presentation of a project

> I was trying not to present it until it consists of a significant > running piece of code, because I don't want it to sound "virtual" I know what you're talking about here. >I know that the main objective in FreeDOS is to provide a working > classical DOS environment and not to turn in

Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts

> Is there any site where I can read in very good detail and in a way that > is easy to understand, how flat-real mode, VCPI and DPMI work and how > they deal with other previously loaded systems to avoid collisions? I don't know about such a site. RBIL however provides much information abou

Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts

>> but then virtual-86 mode is set and I can no loger use 32bit real-mode >> pointers! > > IF you need PM from V86 there is VCPI. Protected mode isn't the same as flat real mode. >> Yet, there has to be a way, because HIMEM works even though EMM386 is >> loaded. > > As said, it uses INT $15 /

Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts

>When you say a program would still need to set up flat real mode, I > suppose you mean that they still need a jump to protected mode and back > to initially setup the segment registers. Yes. > However, I understood that HIMEM did something like establishing a > routine that was run whe

Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts

>I'm building a driver (for DOS) that's supposed to have several > functions hooked at an interrupt. When applications call these > functions, the driver should load and unload some tables or > activate/deactivate them somehow. Because these tables are big, I don't > want to keep them i

Re: [Freedos-devel] How to get FreeDOS kernel version?

Int21.33FF returns a pointer to an ASCIZ release string in dx:ax. Try the function in a debugger and look at the string; it's format isn't fixed. There's no call which returns the numbers but you might try to parse the string instead. Regards, Christian -

Re: [Freedos-devel] newer motherboards and [U]EFI, large-sectored drives

> LARGE SECTOR DRIVES: There is also the issue of large-sectored disks > coming after the 2TB drive, if anyone plans on purchasing one of those. > by large-sectored I mean drives that have 1024, 2048, 4096 byte sectors. > Microsoft has warned of this. large-sectored drives allow you to use

Re: [Freedos-devel] Unable to compile format

> The lesson to be drawn today: develop in Pascal, since that's not > case-sensitive, and have a nice system for handling modules (units). > :p After one year of Pascal "introduction" in school I still couldn't write code easier to read/understand/maintain than my Assembly programs. Consider t

[Freedos-devel] Specify RDISK letter

> I am changing > RDISK from a .SYS to a .COM file, which will then allow a user > specified drive letter when loaded thru the AUTOEXEC.BAT file. > [Not possible in CONFIG.SYS, a "long story" why!]. Actually, with a "bad" hack it is possible to do that. RDISK won't install as normal block device

Re: [Freedos-devel] Closed: FIXED

>> > and leaves both (!!!) files present in the directory and empty ... >> Which both do you mean? It deletes the original, >> so only the temp file still exists? > > YES, but the following rename call apparently recreates the original > name, Yes. > but without deleting the temp name, No, the

Re: [Freedos-devel] Closed: FIXED

>> 1. For AH=$5A, EDR-DOS appends slash, FreeDOS doesn't ... what is more >> valid ??? > > Appending is valid. RBIL is wrong. MS-DOS 5+ appends it, not only version > 5. And just in case someone suspects "evil" usage of DEBUG to disassemble MS-DOS: that wasn't even required here. Just test the

Re: [Freedos-devel] Closed: FIXED

> 1. For AH=$5A, EDR-DOS appends slash, FreeDOS doesn't ... what is more > valid ??? Appending is valid. RBIL is wrong. MS-DOS 5+ appends it, not only version 5. > 2. UIP seems to do a very strange thing: it brews a temp file (AH=$5A, > regrettably not > visible above, but there was ONE call

Re: [Freedos-devel] New RxDOS memory subsystem source code

>> RxDOS is another DOS clone entirely from FreeDOS. > > I agree, but *please* send the link to that other list... I would like to > subscribe :) This, and that RxDOS isn't so entirely different. First, it's of course free now (thanks to Mike!), and second, RxDOS is effectively just a kernel p

Re: [Freedos-devel] New RxDOS memory subsystem source code

> replying here would be somewhat off topic. You're saying development of free DOS software is not on topic in the "FreeDOS devel" list? -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplifi

Re: [Freedos-devel] New RxDOS memory subsystem source code

> not yet a fully working kernel. Am working on RxDOSEXE.ASM right now ;-) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited ro

[Freedos-devel] New RxDOS memory subsystem source code

Just linking this item for those of you interested: If you want to comment and prefer the mailing list, feel free to add your comment as reply here. Regards, Christian

Re: [Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

> Hi, at the risk of talking too much about EDR DOS... Are you afraid of different DOS versions? ;-) >> No, you misunderstood that. He's going to expand the current EDR-DOS >> EDPB >> (call it the [FAT32] DDSC, that's the DR-DOS term "Drive Descriptor") by >> another 2 bytes, it will be 6 bytes

Re: [Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

>> - To improve compatibility regarding the EDPB layout, the EDR-DOS EDPB >> will be expanded to contain another additional 2 bytes. DEVLOAD won't >> work >> with this EDR-DOS version. > > I rather had the impression that Udo was willing to make the MS / EDR > FAT32 DPB size difference smaller th

[Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

Hi, the current DEVLOAD version contains a special check for EDR-DOS, to set the DPB size to a 4 byte larger value if it's found. (It appends new DPBs when loading block devices, and therefore needs to know the size of the DPB.) Now, that's a fine thing, to support other DOS versions and all

Re: [Freedos-devel] Volunteering

> You know that open source has advantages, That's the reason I use it. > for example FreeDOS > runs on more modern hardware Well, decent MS-DOS kernels plus command interpreters also have LBA, FAT32 and DOSLFN support. (But you're right regarding utilities, the FreeDOS ones are often better

Re: [Freedos-devel] Volunteering - Arachne

> - I am not sure whenever Udo Kuhnt's version uses 16 or 32 bit DPMI but > it I think it's 16. The difference isn't that big, anyway. Default code operation size changes, but this doesn't require changes to the actual code (even in .ASM source files) if the assembler or compiler supports both

Re: [Freedos-devel] Volunteering

Hi guys, EA: > > Thanks for the warning :-)). Luckily most of the FreeDOS > > kernel is written in C... One of the things that make it > > complicated is that it sometimes has to follow long chains > > of things calling each other because it is documented that > > MS DOS does it the same way, so f

Re: [Freedos-devel] Volunteering

> The question whether Masm or Nasm has a larger "community" or is more > "widely > used" is indeed somewhat interesting, but it's interesting because it's a > common propaganda item which nicely shows that people tend to believe > what > they want to believe. It's also interesting because JWA

Re: [Freedos-devel] Volunteering

> fdpkg requires c:\FDOS? > how do you maintain a working existing environment > along side the beta one even following the existing > structure and using c:\FDOSBETA or something acceptable. No, it doesn't require this directory name. The directory name is read from the DOSDIR environment vari

Re: [Freedos-devel] Volunteering

>> If you want to learn about (16-bit) DOS kernel stuff, first get the RBIL >> (Ralf Brown's Interrupt List) and the source of DOS-C (mostly C) and >> Udo's >> Enhanced DR-DOS kernel (Assembly). (You might as well get the old RxDOS >> 7.1.5 Assembly sources but oh well.) > > ...and the sources fo

Re: [Freedos-devel] Volunteering

>> As Eric put it, NASM is considered more free than JWASM. > > as you probably can see there are also rather "questionable" sentences > to find > in this mailing-list. "Freedom", "Democracy", "Justice", "Fairness", ... > are > commonly regarded as positive terms and because of this they are al

Re: [Freedos-devel] Volunteering

> A (or more then one) virtualizer is a good source for initial developing > and testing, often an emulator is even more picky about how you > implement. DOSBox is good for DOS games but many utilities refuse to > work. You can boot a real DOS (f.e. FreeDOS) disk image inside DOSBox which make

Re: [Freedos-devel] Volunteering

Hi Adam, > My main interest is programming and a challenge. Occasionally play some > old > games > that I miss. Bards Tale etc. Check out Commander Keen ;-) > Interested in the Kernel and Assembly programming. If you want to learn something about the DOS kernel and Assembly language I could

Re: [Freedos-devel] building freedos

>>> Is the 4DOS license okay for Fedora? > >> I doubt this. Lucho added some ridiculous >> crap and limitations to it. > > Strong words, do you have examples of changes > in 4DOS that are unpleasant for you / others? I'm talking about the license here. Just read what he writes about it on the ma

Re: [Freedos-devel] building freedos

> DOSLFN is probably not free enough for Fedora [...] I wasn't talking especially about Linux license compatibility here, sorry. > Is the 4DOS license okay for Fedora? I doubt this. Lucho added some ridiculous crap and limitations to it. > Not really written for - Japheth just stopped keeping a

Re: [Freedos-devel] building freedos

> The FreeDOS Spec says: > > "Our reference C compiler is OpenWatcom C. (Borland C 3.1 was > originally chosen as the reference standard because this is the > compiler used to build the FreeDOS kernel. However, it is preferable > to use entirely free tools to create FreeDOS.)" > [...] > "This does

Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...

>> You can cast a short to an int, an the conversion in ok, but to cast a >> short* to an int* will bring in 2 extra bytes and an INVALID POINTER... > > no short * and int * are the exact same size in 16-bit compilers (try > compiling a test program which prints sizeof(int), sizeof(short). For > s

Re: [Freedos-devel] Fantom drives

>> I have a proposal for the 2038 kernel: >> >> What about to add possibility to disable creating the fantom >> drive B: on systems with only one disk drive (A:) installed? > > This feature already exists and is much older than 2035 ;-) > It is called the DJ mechanism: When you try to access drive

Re: [Freedos-devel] bug in freedos kernel int 21.1c invalid drive handling?

> As people might call this to find out whether a > drive exists, FreeDOS should return the sectors/ > cluster as 255 as expected for invalid drives... People might do, but it isn't reliable: redirected drives might return al=FFh as well. > The bugfix would make sure AL=255 is returned > for in

Re: [Freedos-devel] bug in freedos kernel int 21.1c invalid drive handling?

> 1) For existing 3,5 floppy disks all give the same (correct) results only > MSDOS gives wrong Total number of Sectors and Sectors per Cluster This bug of MS-DOS 7.10 is also documented in RBIL 61. BTW, I think the other registers should not be changed when al is set to FFh regardless of what