from:"C. Masloch"

On at 2022-07-17 13:32 -0400, Travis Siegel wrote:

On 7/17/2022 7:56 AM, C. Masloch wrote:
On the assumption that DR-DOS is included among the CP/M derivatives,
which would agree with the fact that DRDOS, Inc. did sell DR-DOS 7.xx
(and the shortlived DR-DOS 8.xx) and so had the rights to those, this
means tht EDR-DOS is now free!

For some reason, I'd thought DRDOS has been free for quite some time.

I remember when opendos was released as opensource, (I have a copy of it
around here somewhere), but I thought DRDOS was released as freeware
sometime after that, though I don't remember where I might have seen
that. I do not have a copy of that, though until recently, I did have a
copy of original floppy distribution of DRDOS, but that got lost in our
most recent move (or perhaps that was novel dos which is essentially
opendos now that I think of it).

But regardless, I seriously thought DRDOS was already free.

I was sure you could download it from their site, unless that was
opendos which (afaik) was a later version of DRDOS anyway.

Am I barking up the wrong tree, or is this just me misremembering things?

You aren't entirely right. There was the "OpenDOS" release, aka "Caldera
OpenDOS Machine Readable Source Kit (M.R.S) 7.01". It was redistributed
by the EDR-DOS project at drdosprojects.de (now down but the Wayback
Machine has the page [1]). This was "open" in name only though, and not
accepted as Open Source by the OSI nor Free Software by the FSF (nor by
me). The LICENSE.TXT file in this archive has some choice decisions like
these:

> LIMITED LICENSE FOR EVALUATION, EDUCATIONAL AND NON-PROFIT USE

The details on that indicate you have to belong to a few groups:

if (a) you are a student,
faculty member or staff member of an educational institution
(K-12, junior college, college or library), a staff member of
a religious organization, or an employee of an organization which
meets Caldera's criteria for a charitable non-profit organization;
or (b) your use of the Software is for the purpose of evaluating
whether to purchase an ongoing license to the Software. The evaluation
period for use by or on behalf of a commercial entity is limited
to 90 days; evaluation use by others is not subject to this 90 day
limit but is still limited to a reasonable period.

The "source code grant" section also has wording such as:

for personal, non-commercial use.

This is not free software because you cannot use, redistribute, and
modify it as you wish; you need to limit yourself to personal and
noncommercial use, or merely "evaluate" the software.

Other than that, DR-DOS 7.02 and 7.03 used to be sold by DRDOS, Inc.,
and there were partial versions (kernel, maybe shell) numbered as 7.04
and 7.05 used for some embedded jobs. There was also version 8, but due
to FreeDOS copyright infringement that had to be changed. The developers
at the time chose to completely burn any trace of version 8 instead of
complying with the copyleft usage conditions for the included FreeDOS
parts. As far as I know, none of these versions were free until now, and
beyond that not even just gratis or allowed for noncommercial / personal
use.

Regards,
ecm

[1]:
https://web.archive.org/web/20160326184121/http://www.drdosprojects.de/index.cgi/download.htm

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

Re: [Freedos-user] CP/M "and derivatives" legal status clarified


On at 2022-07-17 13:42 +0200, Liam Proven wrote:

I wrote a story about this on the Register:
https://www.theregister.com/2022/07/15/cpm_open_source/

Bryan Sparks (president of DRDOS Inc, which is still around) has given
official permission for the modification and distribution of "CP/M and
derivatives". It's on the Unofficial CP/M Web Site:
http://www.cpm.z80.de/license.html

Since CP/M-86 is a derivative of CP/M, as is DR-DOS, Concurrent DOS,
Multiuser DOS and so on, this would seem to be an important legal
precedent.

No, it is not a proper FOSS license. That takes lawyers and lawyers cost money.

But it's the next best thing and I suspect as good as we will ever get.


That's great news, thank you! For the record, here is the exact wording 
that we get. The old wording from the 2001-10-19 email:



Let this email represent a right to use, distribute, modify, enhance and
otherwise make available in a nonexclusive manner the CP/M technology as
part of the "Unofficial CP/M Web Site" with its maintainers, developers and
community.

I further state that as Chairman and CEO of Lineo, Inc. that I have the
right to do offer such a license.

Lineo and its affiliates, partners and employees make no warranties of any
kind with regards to this technology and its usefulness or lack thereof.


The new wording in the 2022-07-07 message:

Not sure how to "officially" clear this up except to modify the original email content 
removing the constraint to the website/group that was mentioned. So, perhaps, this 
will suffice:


"Let this paragraph represent a right to use, distribute, modify, enhance, and otherwise 
make available in a nonexclusive manner CP/M and its derivatives. This right comes from 
the company, DRDOS, Inc.'s purchase of Digital Research, the company and all assets, 
dating back to the mid-1990's. DRDOS, Inc. and I, Bryan Sparks, President of DRDOS, 
Inc. as its representative, is the owner of CP/M and the successor in interest of 
Digital Research assets."


On the assumption that DR-DOS is included among the CP/M derivatives, 
which would agree with the fact that DRDOS, Inc. did sell DR-DOS 7.xx 
(and the shortlived DR-DOS 8.xx) and so had the rights to those, this 
means that EDR-DOS is now free!


As for this being "not a proper FLOSS license", I think it is clear 
enough that it allows usage, distribution, and modification, which is 
all that is needed for free software. It is true that this is what 
people call a "crayon license", but a lot of free-ish DOS software does 
have such. I consider this free software.


Regards,
ecm


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

Re: [Freedos-user] Questions on Eric Auer's Terminal


On at 2022-07-17 11:07 +0200, C. Masloch wrote:
Next problem: The cursor always stays in the lower left corner of the 
DOS screen. This is sort of documented in the manual [8], but I don't 
fully understand it.


The idea was to either wrap at the end of line for a dumb terminal
experience or try to stick to intended coordinates where possible.

A slightly more elegant method would have been to let the terminal
show the upper 80x25 chars of a 256x256 char coordinate system :-)


I don't understand how the F6 setting is related to any of what you 
wrote. The cursor problem is the only major problem I could not fix yet. 
Makes line editing in lDebug more difficult than I'd like it to be 
because you can't tell where the debugger's cursor is at.


Fixed the cursor problem [1] (at least for normal output with 
CR/LF/text, maybe not fixed for some ANSI escape things). Before this, 
all output during normal operation (ie not PROMPTPARM [2]) would simply 
write to the screen text memory wherever it pleased. The cursor wasn't 
*set* to stay in the lower corner, it just happened to be that after the 
DOS boot, config, and autoexec output the cursor usually *already* was 
in the lower corner. If you tried running CLS in FreeCOM and then 
started Terminal, the cursor would stay near the upper corner instead.


I also fixed a bug I didn't even know was there before: Pressing F5 
would cycle through the different CR policies (what to send when 
receiving an Enter keypress) but would not update the status item that's 
supposed to show which CR policy is in effect. The fix was simple [6].


Another bug caused the speed to be garbled in the status display before 
using F2, at least when running Terminal as "terminal.com a 4 ! &". The 
upper byte of the word [linespeed] was nonzero in that case. [3]



So the remaining problems are:

1. sometimes part of long output is lost,

2. hang on STAU,


Improved this by enabling the "prevent jammed keyboard" option already 
given before in the source. This is now included by default, though only 
actually used when the hshake variable indicates a jam (STAU indicator 
lights up). [4] That allows to spam F7 until the keyboard jam handling 
lets through the keypresses, allowing to change the F7 setting back and 
regain control of the terminal.



3. inverted video changes to brown,


I missed previously that the default colour is yellow-on-blue, not 
light-white-on-blue as I assumed. Yellow is actually light-brown. That 
explains how we got to blue-on-brown. Anyway, I fixed the reset to 
actually set light-brown-on-blue [5] and the invert to properly invert 
the colours and intensity bits [6]. (RxANSI does it differently, as 
noted in the commit message here. Might be something to fix.)



4. and the cursor is glued to the bottom corner.


As mentioned, mostly fixed. Before the first output is shown the cursor 
is not set yet though. And as mentioned may not be correct if ANSI 
escape sequences are involved. But it is already much better for my 
simple use case.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/terminal/rev/14e39566145a
[2]: https://hg.pushbx.org/ecm/terminal/file/bf9903fceae9/term-set.asm#l97
[3]: https://hg.pushbx.org/ecm/terminal/rev/bac5c6182290
[4]: https://hg.pushbx.org/ecm/terminal/rev/d48e0bf12ed9
[5]: https://hg.pushbx.org/ecm/terminal/rev/c64249cb36b5
[6]: https://hg.pushbx.org/ecm/terminal/rev/bf9903fceae9


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

Re: [Freedos-user] Questions on Eric Auer's Terminal


On at 2022-07-16 23:17 +0200, Eric Auer wrote:


Hi!

That sounds like great question to discuss with other dosemu2 experts
including you, as the serial port emu of dosemu2 has to do a large
part of the work in what you want to do, I think? :-)


It may be related to dosemu2 oddities, yes. However, some parts may be 
errors in Terminal, too.



The terminal uses mostly BIOS if i remember correctly, to be slow
but compatible? Yet that also means slower and less reliable comm.


Actually it seems that Terminal mostly uses direct port and text-mode 
screen memory access.



Regards, Eric

PS: The terminal, I think, interprets some basic ANSI itself to
be self-contained and faster, but as you say, it lacks features
such as translating cursor keypresses to messages to the server.
In general, all this has been a very long time ago, though.


I added handling for arrow keys now [1], and also some other special 
keys [2] that are detected by lDebug's rawinput line editor [3]. 
(PageUp/PageDown/Insert are detected but don't do anything yet, except 
for beeping.)


I also added simple support for the Bell codepoint, just calling the 
video ROM-BIOS interrupt 10h service 0Eh to handle the beeping [4].


Next problem: The cursor always stays in the lower left corner of the 
DOS screen. This is sort of documented in the manual [8], but I don't 
fully understand it.


The idea was to either wrap at the end of line for a dumb terminal
experience or try to stick to intended coordinates where possible.

A slightly more elegant method would have been to let the terminal
show the upper 80x25 chars of a 256x256 char coordinate system :-)


I don't understand how the F6 setting is related to any of what you 
wrote. The cursor problem is the only major problem I could not fix yet. 
Makes line editing in lDebug more difficult than I'd like it to be 
because you can't tell where the debugger's cursor is at.


The dropped debugger output was *mostly* fixed by enlarging the receive 
buffer to 2 KiB, from the prior 32 bytes [5]. If I do very long output 
such as from a "tp f" command, then it still sometimes loses part of 
the output, but normal commands with half a screenful of output or so do 
work now.


I also fixed a bug I didn't even know was there before: Pressing F5 
would cycle through the different CR policies (what to send when 
receiving an Enter keypress) but would not update the status item that's 
supposed to show which CR policy is in effect. The fix was simple [6].


Other than that I also added two convenience parameters to the 
command-line parsing that skip the intro [7] respectively change the 
default CR policy to the one I want [8].


So the remaining problems are:

1. sometimes part of long output is lost,

2. hang on STAU,

3. inverted video changes to brown,

4. and the cursor is glued to the bottom corner.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/terminal/rev/479128a44413
[2]: https://hg.pushbx.org/ecm/terminal/rev/7ebcbaf69a06
[3]: 
https://hg.pushbx.org/ecm/ldebug/file/aaa006adaee0/source/lineio.asm#l2530

[4]: https://hg.pushbx.org/ecm/terminal/rev/564d2103c38d
[5]: https://hg.pushbx.org/ecm/terminal/rev/621b8283ed1d
[6]: https://hg.pushbx.org/ecm/terminal/rev/07bee5d55b39
[7]: https://hg.pushbx.org/ecm/terminal/rev/0405a5b9c62d
[8]: https://hg.pushbx.org/ecm/terminal/rev/453eb5e82fff


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

[Freedos-user] Questions on Eric Auer's Terminal

2022-07-16 Thread C. Masloch


Hi list,

I was just about to write to Eric concerning some problems of mine in 
using the Terminal program. I figured someone else on this list may also 
be able to help with some of these problems.


I received this program from some mirror of Eric's, and mirrored it in 
turn on our server [1]. I also imported the four available versions into 
an hg (Mercurial) repo [2]. I did not modify the terminal program 
itself, yet.


Here's the current setup I am using:

1. Run the socat command to create a PTTY with two ends:

socat pty,link=/tmp/vptty-debug,rawer pty,link=/tmp/vptty-terminal,rawer 
& disown


2. Run a dosemu2 instance with COM1 connected to one of the PTTY ends:

dosemu -K "$PWD" -E "terminal.com a 4" -I "serial { com 1 device 
/tmp/vptty-terminal }"


(Note that the "a" indicates to use COM1 and the "4" indicates [3] to 
use 9600 baud.)


3. Wait until the slideshow in the top row finishes

4. Run another dosemu2 instance with COM2 connected to the other PTTY end:

dosemu -dumb -td -kt -I "serial { com 2 device /tmp/vptty-debug }" -E 
"ldebug.com /c='r dco or= 4800'"


(Note that lDebug defaults to using COM2 and 9600 baud [4].)

5. Enter the "KEEP" keyword then Enter to the debugger's prompt

6. Press F5 twice to change into send-CR-only mode


The first problem is that the receiving of debugger output to the 
terminal doesn't seem to work reliably. It drops parts of the output. It 
appears unpredictable which exact parts this are, changing when 
repeatedly entering commands. There's an image file of how it can look 
[5]. Or here, selected and copied from the dosemu2 window:


F1=inf F2=Sp+ F3=Brk! F4=ETX! F5=TxCR F6=RxCR F7=SHK? F8=EXIT F9=RTS! 
F10=DTR!


lDebug connected to serial port. Enter KEEP to confirm.
= keep
-
-r
AX= BX= CX= DX=00retn
-r
AX= BX= CX= DX= retn
-r
AX= BX= CX= DX=retn
-r
AX= BX= CX= DX=retn
-


This is what I expect the "r" command to display (with whatever segment 
value is current of course):


-r
AX= BX= CX= DX= SP=FFFE BP= SI= DI=
DS=41E1 ES=41E1 SS=41E1 CS=41E1 IP=0100 NV UP EI PL ZR NA PE NC
41E1:0100 C3retn
-


In trying to fix this, I have attempted to cycle through several of the 
settings that Terminal provides. That includes all speeds (F2), "sending 
of a break" (F3), "toggle handling of RTS" (F9), "toggle transmission of 
DTR" (F10), and cycling the handshake ways (F7), though not all 
combinations of those.


The latter (F7) appears to make the Terminal application accept one more 
keypress from the user to send to the serial port, then it appears to 
hang, it does not seem to allow any further input. (That's including 
commands using the Function keys, so I have to close dosemu another way 
then.) When this happens the "STAU" (traffic jam) indicator lights up 
when F1 was first used once to enable the status display.



Next problem: Enabling change highlighting in the debugger causes the 
colour to switch from bright-white-on-blue to blue-on-brown. Then the 
reset switches the colours to brown-on-blue. A subsequent highlighted 
change switches to (light-?)blue-on-brown and then resets back to 
brown-on-blue. The results can be seen in a screenshot [6]. As 
documented in the manual [7], lDebug sends ANSI escape sequences to 
change the attributes, namely \x1B[7m to reverse video then \x1B[m to 
reset the colours.



Next problem: When entering some input and then Backspace, it appears to 
work. However, when entering Backspace on an empty command line, then a 
dot-in-the-middle symbol is displayed. This appears to be a purely 
cosmetic error though. (Actually I just figured out that this is what 
happens when the debugger sends a Bell U+0007 code. That insight is part 
of the way of how to fix this.)



Next problem: The cursor always stays in the lower left corner of the 
DOS screen. This is sort of documented in the manual [8], but I don't 
fully understand it. Pressing F6 once to change any either CR or LF be 
expanded "to a full CR LF combination" certainly isn't what I want (the 
debugger already sends CR LF to indicate a single linebreak, or CR-only 
to reset a line to the first column). And it doesn't seem to change the 
cursor's position anyway.



Next problem: The cursor keys don't arrive to the debugger. This is 
documented [9], and I believe I may be able to fix it myself if I start 
to look into it.



That's all I have got so far. I'd be interested in any relevant comments.

Regards,
ecm


[1]: https://pushbx.org/ecm/download/terminal-2007jun20.zip
[2]: https://hg.pushbx.org/ecm/terminal
[3]: https://hg.pushbx.org/ecm/terminal/file/f9c5454794f3/terminal.txt#l26
[4]: https://pushbx.org/ecm/doc/ldebug.htm#vardspvd
[5]: 
https://pushbx.org/ecm/test/20220716/Screenshot%20at%202022-07-16%2022-25-12.png
[6]: 
https://pushbx.org/ecm/test/20220716/Screenshot%20at%202022-07-16%2022-42-36.png

[7]:

Re: [Freedos-user] DOS ASM resources

2022-07-07 Thread C. Masloch


On at 2022-07-07 09:39 -0700, Ralf Quint wrote:
Similar with NASM, where for some weird reasons, they made the assembler 
case-sensitive, which I would consider utter nonsense (also among my 
griefs with C(++)). And it really bites you if you are trying to link 
assembler modules with other programming languages. It also 
(deliberately) doesn't support some assembler instructions (as per Intel 
specs) just because it doesn't fit into their parser (LODS, MOVS, ...),


Fair enough on all the other points, but the support for string 
instructions is actually there. It just isn't done with explicit 
operands to the instruction to indicate the operand size and segment 
override (whereas I believe the symbol offset address you can specify to 
MASM is ignored). Instead, NASM supports eg lodsb / lodsw / lodsd, as 
well as segment override and a16 or a32 as prefixes. So for example you 
could have "a32 es lodsd". This syntax used to be documented in their 
instruction set reference, as forked by me. [1]


On the ignored address, the Intel manual according to felixcloutier.com 
[2] says:


===

At the assembly-code level, two forms of this instruction are allowed: 
the “explicit-operands” form and the “no-operands” form. The 
explicit-operands form (specified with the LODS mnemonic) allows the 
source operand to be specified explicitly. Here, the source operand 
should be a symbol that indicates the size and location of the source 
value. The destination operand is then automatically selected to match 
the size of the source operand (the AL register for byte operands, AX 
for word operands, and EAX for doubleword operands). This 
explicit-operands form is provided to allow documentation; however, note 
that the documentation provided by this form can be misleading. That is, 
the source operand symbol must specify the correct type (size) of the 
operand (byte, word, or doubleword), but it does not have to specify the 
correct location. The location is always specified by the DS:(E)SI 
registers, which must be loaded correctly before the load string 
instruction is executed.


===

Regards,
ecm


[1]: https://pushbx.org/ecm/doc/insref.htm#insLODSB
[2]: https://www.felixcloutier.com/x86/lods:lodsb:lodsw:lodsd:lodsq



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

Re: [Freedos-user] DOS ASM resources

2022-06-30 Thread C. Masloch


On at 2022-06-30 10:00 -0500, Santiago Almenara wrote:

Hello!

What book or webpage do you recommend to learn some DOS assembler?

Thanks in advance

Santiago


I learned primarily using these methods:

1. Read existing code and try to understand it. Even better, start with 
higher-level commentary about code if you can find any. Some 
applications' manuals are good for this, eg DOSLFN.


2. Have an english-language instruction set reference handy. I used the 
one included with older NASM versions, which I subsequently forked when 
it was dropped from NASM. [1]


3. Likewise, refer to the Interrupt List for reference as to what a 
particular interrupt service does. Apart from some modern extensions it 
is fairly complete. It can be found in plain-text files (split across a 
lot of them, you can concatenate them to receive a single file) on Ralf 
Brown's pages [2] and can be accessed online, page per page, hosted by 
several different websites such as fd.lod.bz [3].


4. Try out things in a debugger if unsure, such as when unclear about 
what a particular instruction does, or to trace an existing program and 
try to improve your understanding of its workings. My main project is 
lDebug (with a small "L"), a debugger with a command line interface 
that's based on FreeDOS Debug. [4]


5. You can also read some of the books that have been written about DOS. 
At home I have the following print books: "FreeDOS Kernel", "DOS 
Internals", "Undocumented DOS (Second Edition)" (UDOS), "Dissecting 
DOS", "Extending DOS", "Advanced MS-DOS Programming", "Writing MS-DOS 
Device Drivers", and a german "DR DOS 6.0" manual. UDOS and the DR DOS 
manual are probably the best among these.


Finally, I wrote a document called Assembly Comments Explained: Guide 
for Advanced Learning and Style [5]. It is intended to clarify 
conventions in my assembly language sources in particular.


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/insref.htm
[2]: http://www.cs.cmu.edu/~ralf/files.html
[3]: https://fd.lod.bz/rbil/index.html
[4]: https://pushbx.org/ecm/web/#projects-ldebug
[5]: https://pushbx.org/ecm/doc/acegals.htm


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

Re: [Freedos-user] how to get dosemu working under ubuntu installed in wsl

2022-03-14 Thread C. Masloch


On at 2022-03-14 18:47 +0100, Liam Proven wrote:

I don't agree that this feature "makes DOS apps part of the apps on
the computer"


DOS apps (not games but productivity applications) are by nature text
mode apps, with only a few modern exceptions which probably won't work
well on DOSemu anyway.

All xNix text-mode apps are designed and intended to exchange
information by means of plain text: either text files, or pipes.

DOS apps under DOSemu *windows* work on whatever is in the Linux
filesystem, and that generally includes the ability to import or
export plain-text files. And if you run them without graphics support,
you can pipe their output to other shell commands.

For me, that means that DOS apps can be used alongside with, and
interact with, Linux apps.  That is what I was getting at when I said
that they work alongside Linux apps, as just another type of binary
you can run -- in a way that is _not_ true of DOS inside a VM.


Some things to note:

1. Yes, you can use your Linux terminal (dosemu mode -t or mode -dumb) 
to do your DOS application's I/O. This is fairly unique, although qemu's 
-curses mode is similar to dosemu's -t.


2. dosemu runs an actual DOS system, traditionally FreeDOS. On the 
contrary, DOSBox is mostly used without a proper DOS, running its own 
operating system shims. (dosemu2 is blurring the distinction a bit with 
fdpp, which is a FreeDOS kernel port that runs in 32-bit or 64-bit host 
code and replaces the proper DOS kernel you can use otherwise. fdpp 
*only* runs in dosemu2 so far.)


3. The major feature of dosemu is certainly its filesystem redirector, 
based on the MachFS DOS redirector, which allows you to access host 
directories as DOS drives, and supports (to some extent) simultaneous 
accesses from Linux and DOS. (DOSBox has this too, but IIRC only for its 
built-in OS, not for when you boot an actual DOS instead.)


Other than that I don't really consider dosemu (or DOSBox) anything 
other than a "Virtual Machine" with some DOS-specific knacks.


Regards,
ecm


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

[Freedos-user] Announcement: lDebug release 4

2022-03-08 Thread C. Masloch


Hello list,

today I finished release 4 of my libre 86 DOS debugger called lDebug [1].

This release fixes several bugs, including several in the interactive 
enter mode (E command), one of which was reported in January to the 
original Debug/X project [2]. (lDebug is a fork originally based on 
FreeDOS Debug/X version 1.13 of 2008-02-27.) A major new feature is that 
the DI command (Dump Interrupt handler) now allows to follow downlinks 
of IBM Interrupt Sharing Protocol (IISP, [3]) headers, and can 
optionally also walk all Alternate Multiplex Interrupt Specification 
(AMIS, [4]) multiplexers' interrupt lists to find and identify handlers 
belonging to an interrupt's handler chain.


The entire news are listed in the manual, available in the release 
archives as well as on the web [5]. As usual, there are a tarball 
(lzip-compressed), a zip file, and a FreeDOS package zip file available 
in the lDebug download subdirectories on the server I use [6]. 
Additionally, there are now "current" release zipfiles available on the 
server. They are automatically updated daily, if changes were committed 
to the hg repo. There's ldebug.zip for the debugger proper [7] and 
lddebug.zip for the debuggable build of the debugger [8]. (You only want 
to use the debuggable build if you intend to debug the debugger itself.)


Regards,
ecm


[1]: https://pushbx.org/ecm/web/#projects-ldebug
[2]: https://github.com/Baron-von-Riedesel/DOS-debug/pull/4
[3]: https://pushbx.org/ecm/test/2020/intshare/INTSHARE.DOC
[4]: https://fd.lod.bz/rbil/zint/index_2d.html
[5]: https://pushbx.org/ecm/doc/ldebug.htm#news-r4
[6]: https://pushbx.org/ecm/download/ldebug/
[7]: https://pushbx.org/ecm/download/ldebug.zip
[8]: https://pushbx.org/ecm/download/lddebug.zip


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

[Freedos-user] Announcement: lDebug release 3

2021-08-15 Thread C. Masloch


Hello FreeDOS developers and users,

Another 3 months have gone by and here's the next release of the 
advanced Debug re-implementation, lDebug, based on FreeDOS Debug. It is 
free/libre and builds from source using a toolchain including NASM and a 
C compiler.


Like before, there are 5 executables in the FreeDOS package's BIN 
directory. A few more choices of different compression methods are 
shipped in the SOURCE/LDEBUG/ldebug/tmp subdirectories. (Robert reported 
that the default LZMA-compressed executables may require several minutes 
to unpack on low-end machines. The fastest choice of compression method 
is likely LZ4. There are also the uncompressed executables.)


The manual has been updated to include the release 3 news [1], and also 
has received some additional parts. The packages are available from my 
server [2] in the /ecm/download/ldebug directory and its fdpkg 
subdirectory. My website [3] contains links to those and to the repo [4] 
too.



News include:

* Interrupt 8 hook (Timer) documented and made opt-in

* Interrupt 2Dh hook (AMIS, the Alternate Multiplex Interrupt 
Specification), opt-in


* Tries to unhook interrupt handlers properly if reachable by walking 
IISP (IBM Interrupt Sharing Protocol) headers and AMIS TSRs' interrupt 
lists, with options to force unhooking if individual handlers are not 
reachable.


* Expression evaluator additions: VALUE x IN y construct for range 
checking, ternary conditional cond ?? then :: else operator, LINEAR 
keyword to get linear addresses from segmented ones, string literals #"..."


* Instructions disassembled using the R command are now examined so as 
to set the READADR0 (linear address of a read access) and READLEN0 
(length in bytes) style variables, also WRITADRx and WRITLENx


* H BASE=/GROUP=/WIDTH= command to output numeric results in arbitrary bases

* Control-C handling improved: scan int 16h circular buffer for 
Control-C keypress, make Control-C abort running RE buffer and script 
files, allow lDebugX to use DOS function 0Ah in PM


* Several bug fixes

* A collection of acceptance tests

* Hosted on a new web domain (the old one ulukai.org still carries the 
same files for now but pushbx.org is preferred)



Note to the server admins: Please mirror the LDEBUG3.ZIP FreeDOS package 
from the fdpkg subdirectory!


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#news-r3
[2]: https://pushbx.org/ecm/download/ldebug/
[3]: https://pushbx.org/ecm/web/#projects-ldebug
[4]: https://hg.pushbx.org/ecm/ldebug/


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

[Freedos-user] Announcement: lDebug release 2, suggest to include in FreeDOS release

2021-05-05 Thread C. Masloch


Hello FreeDOS developers and users,

I decided to push out release 2 of my FreeDOS Debug fork today, nearly 3 
months after release 1. It is based on 2008's FreeDOS Debug 1.13 first, 
staying with the Netwide Assembler source, though with many of the 
changes added to FreeDOS Debug since ported and merged in.


It is an advanced take on a simple line I/O based debugger. It can be 
controlled as a DOS application (int 21h), from a ROM-BIOS terminal (int 
10h, int 16h), through a serial port, and/or from script files. It runs 
in Real or Virtual 86 Mode, as a DOS application, DOS TSR, or bootloaded 
instead of an OS kernel. The DPMI-capable lDebugX also can run as a DPMI 
client.


lDebug is free/libre software and can be re-built entirely using a free 
toolchain. The provided scripts are for cross-compile building on a 
desktop or server Linux host system.


As before, the manual is included, in a HTML file (preferred) as well as 
a text file and PDF. The five application executables are the same as 
for the prior release too; ldebug.com and ldebugx.com are 
LZMA-compressed, ldebugu.com and ldebugxu.com are uncompressed, and all 
four can be used as DOS applications or bootloaded from the lDOS boot 
sector loaders. The included instsect application allows installing such 
a loader to a DOS drive, file system image file, or into a boot sector 
file for chainloading. All programs are intended to run on any processor 
type down to the 8088/8086 level.


Refer to my website [1] for links to the releases, repo, and most recent 
documentation on the web. Changes since release 1 (and the ones prior to 
release 1) are now listed in the manual [2]. Release 2 includes a few 
bug fixes, as well as two new features: Line editing history [3] and 
register dump change highlighting [4].


Jerome suggested [5] for me to write to the mailing lists to advertise 
this package and suggest it be included in future FreeDOS releases. I 
decided to finish release 2 for the occasion, mainly because I would 
like to get out the bug fixes added since release 1.


To the ibiblio server admins: Please mirror the LDEBUG2.ZIP file from my 
FreeDOS package subdirectory [6].


Regards,
ecm


[1]: https://ulukai.org/ecm/web/#projects-ldebug
[2]: https://ulukai.org/ecm/doc/ldebug.htm#news-r2
[3]: https://ulukai.org/ecm/doc/ldebug.htm#interface-input
[4]: https://ulukai.org/ecm/doc/ldebug.htm#interface-rdump
[5]: https://github.com/shidel/FDI/issues/14
[6]: https://ulukai.org/ecm/download/ldebug/fdpkg/


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

2020-12-16 Thread C. Masloch


On at 2020-12-14 07:36 +0100, Mateusz Viste wrote:

Hi Christian,

Your docs seem very interesting! I didn't know about them. Having them 
available as AMB books would definitely be very cool.
I am not very fond of HTML as a source-to-be-processed data, but the halibut 
thing appears very promising. I will see how hard it would be to create a 
halibut2amb converter.

Mateusz



Very nice! I'd guess it may be the path of least resistance to add an 
AMB output format to the existing Halibut compiler. So you don't have to 
re-invent the Halibut input handling.


By the way, I am not a Christian. The C. does not stand for that.

Regards,
ecm


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

2020-12-13 Thread C. Masloch


On at 2020-12-13 09:15 +0100, Mateusz Viste wrote:
I'd love to have the FreeDOS books in there, too. 
https://www.freedos.org/books/
I don't think I have the free time to convert them, but if I sent you 
the ODT files, could you convert


Sure, if the books are terminal-friendly (ie. no illustrations or 
illustrations can be removed easily).


Hi,

I wonder whether you could convert my documentation to AMB format too? 
Most of it is found at [1] -- each HTML file contains a link to the 
corresponding hg repository near the end, which has the source. Such as 
[2].The source format is that accepted by the Halibut documentation 
preparation system [3]. Perhaps you can convert from either the HTML 
output or the Halibut sources to AMB?


Regards,
ecm

[1]: https://ulukai.org/ecm/doc/
[2]: https://hg.ulukai.org/ecm/insref/
[3]: https://www.chiark.greenend.org.uk/~sgtatham/halibut/


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

Re: [Freedos-user] Boot sector compatibility

2020-05-31 Thread C. Masloch

On 5/30/20 1:09 PM, Eric Auer wrote:
> 
> Hi ECM,
> 
>> https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/boot32lb.asm
>> -- also last change 2004. Note that this requires a 386 and doesn't
>> check for it. My take on a FAT32 boot sector loader allows to load
>> FreeDOS KERNEL.SYS too, but automatically detects either CHS or LBA and
>> is supposed to work even on 8086:
>> https://hg.ulukai.org/ecm/ldosboot/file/3b98bf84db45/boot32.asm (It
>> requires part of it be installed to the FSINFO sector, which is how it
>> can do so much more.)
> 
> That is exactly the difference: It was an interesting challenge to
> put the whole boot sector into one sector :-) I believe that CHS
> FAT32 version even works for 8086, while LBA FAT32 needed 386? :-)

Yes, as you can see I commented on boot32lb.asm which is the FAT32
loader that uses LBA.

> Note that Windows would use the second sector only for FSINFO and
> uses the THIRD sector for additional code for booting, so I wonder
> why you prefer the FSINFO sector for it? When not used, the third
> sector just contains the 55 aa magic. All three sectors have that.

It allows using my loader in parallel to theirs. They use the third
sector or whatever, I use FSIBOOT in the FSINFO sector. For example, if
one were to use your Metakern then booting Microsoft loaders requires
their additional sector to be present where they expect it. And booting
my loader from Metakern requires its additional FSIBOOT part be present
in the FSINFO sector. (All assuming 512 bytes per sector. If there are
1024+ bytes per sector my loader expects the FSIBOOT part to be present
at offset 512 in its own sector, thus already loaded.)

Note that although they differ in their details, the lDOS/RxDOS.3 and
FreeDOS load protocols of my FAT32 loader both use the exact same
FSIBOOT part, so can be used in parallel without re-installing the FSIBOOT.

Regards,
ecm

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

Re: [Freedos-user] FreeDOS 1.3-RC3 News!

2020-05-30 Thread C. Masloch

On at 2020-05-29 20:54 -0500, Rugxulo wrote:
> There may have been a bug in older FreeDOS boot sectors requiring
> 186?? But I thought that was fixed (by ecm).

I don't think I ever contributed to the boot sector loaders. I actually
checked but there doesn't seem to be any such contribution.

https://github.com/PerditionC/fdkernel/tree/master/boot -- all are from svn

https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/boot32.asm
-- last change 2004

https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/boot32lb.asm
-- also last change 2004. Note that this requires a 386 and doesn't
check for it. My take on a FAT32 boot sector loader allows to load
FreeDOS KERNEL.SYS too, but automatically detects either CHS or LBA and
is supposed to work even on 8086:
https://hg.ulukai.org/ecm/ldosboot/file/3b98bf84db45/boot32.asm (It
requires part of it be installed to the FSINFO sector, which is how it
can do so much more.)

https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/oemboot.asm
-- last change 2009, but not by me

https://sourceforge.net/p/freedos/svn/1481/log/?path=/kernel/branches/UNSTABLE/boot/oemboot.asm
-- last change 2005

https://sourceforge.net/p/freedos/svn/1835/log/?path=/kernel/trunk/boot/boot.asm
-- last change 2009, not by me

> Not aware of other
> problems (although, yes, newer FreeCOM 0.84-pre2 XMS_Swap [standard
> 2006 build] uses 186 code sometimes, but XMS needs a 286 anyways.

That's https://github.com/FDOS/freecom/issues/15 where I noted that the
XMS handling uses 186+ code; this was fixed. And my fork of 8086tiny did
offer XMS without full 186+ instruction set support, though by now I
have updated it to add the latter.

Regards,
ecm


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

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

2020-05-22 Thread C. Masloch

On at 2020-05-22 07:58 -0700, Ralf Quint wrote:
> And the license kind of disallows to re-use the
> code from the files, similar to that of the DOS 1.x/2.0 source they
> published last year...

That's incorrect. Note that in the blog post they're referring to
"re-open-sourcing" the old MS-DOS files. The *original* release was not
FLOSS. However, that "re" open sourcing was under the MIT license. The
same is also used for this GW-BASIC release:

https://github.com/microsoft/GW-BASIC/blob/master/LICENSE

What is more of a problem is that the MS-DOS 2.x sources are missing
most of the IO.SYS (BIO) source, and I also can't find SYS or their boot
sector loaders anywhere. And the COMMAND.COM does not entirely work with
subdirectories yet.

Regards,
ecm

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

Re: [Freedos-user] DOS version control

2020-02-18 Thread C. Masloch

On at 2020-02-18 18:25 +0100, Matej Horvat wrote:
> I have managed to get Mercurial 3.4.2 running on DOS semi-reliably (at
> least for local use) with some modifications. I can try to reconstruct
> the steps needed if you want.

I'd be interested in this. I'm using Mercurial for my own projects.
Shameless plug: https://hg.ulukai.org/ecm/

Though I do still depend on things like bash, perl, grep, and sed, for
actually running my build scripts. But Mercurial running on a DOS would
still be good.

Regards,
ecm

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

Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)

2019-10-26 Thread C. Masloch

On at 2019-10-26 03:09 -0500, Rugxulo wrote:
>> I also worked some on an 8086tiny fork of mine recently. There are
>> several bugfixes there, as well as implementing all 186 instructions, so
>> it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/
> 
> I tested all of this under Linux (Xenial Puppy, 64-bit) jump drive.
> 
> It seems you're missing "lmacros3.mac" (not found) for tinyxms, but I
> just ignored that for now: "make no_graphics -k -i" or whatever. (I
> just used a modified version of my old BARE_DOS floppy image.)

Oh yes, that was not intended. I think the included fd.img does have the
compiled tinyxms.sys already, but to build it from source you need to
load all of lmacros[123].mac from https://hg.ulukai.org/ecm/lmacros and
put them in one of the directories included by the NASM run:

> tinyxms.sys: tinyxms.asm
>   nasm -f bin -I ../lmacros/ -I lmacros/ -l tinyxms.lst -o tinyxms.sys
tinyxms.asm

That is, either copy the three macro files to the same directory as
tinyxms.asm, or to an lmacros subdirectory, or to an lmacros
sibling-directory of the 8086tiny directory.

Regards,
ecm

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

Re: [Freedos-user] Tinyasm vs. NASM (was: Re: A neat find on /r/asm)

2019-10-08 Thread C. Masloch

On at 2019-10-05 18:49 -0500, Rugxulo wrote:
> "Unfortunately, nasm doesn't run over 8086/8088 processors,and I
> couldn't find a compatible assembler!"
> 
> Strange. I was lightly playing with 8086tinyplus (on Windows)
> recently, and I noticed that the (in)famous 16-bit NASM build from
> 2005 of 0.98.39 didn't seem to run properly. (But that could be an
> emulator bug. It runs fine under QEMU. I know 8086tinyplus can't
> handle 186+ ENTER/LEAVE properly.)

If the 16-bit NASM uses 186+ instructions, that's a bug (or possibly
wrong option?) on the part of the compiler.

I also worked some on an 8086tiny fork of mine recently. There are
several bugfixes there, as well as implementing all 186 instructions, so
it might be worth testing. It's at https://github.com/ecm-pushbx/8086tiny/

> Even other NASM versions had
> issues. (A86 and Wolfware/WASM worked fine, though.) Actually, I think
> I ran my old BARE_DOS floppy and used "call /s", and then at least
> NASM 0.97 worked. I meant to try to recompile NASM 0.98.39 with both
> Turbo C and OpenWatcom (supporting bin only or bin+obj only) and test,
> but I never found the extra time and energy.
> 
> * https://jaybertsoftware.weebly.com/8086-tiny-plus.html
> * 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/
> 
> Comments on further testing welcome!


Regards,
ecm


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

Re: [Freedos-user] Not sure is it possible - but maybe I'm missing something?

2019-05-10 Thread C. Masloch

On 2019-05-09 18:02 +0200, ZB wrote:
> BTW: which macroassembler you prefer?

I prefer NASM. The reason I initially forked lDebug was actually to keep
its source in the NASM dialect. Also, I adjusted the (default)
disassembly display to mostly match NASM's syntax.

Regards,
ecm





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

Re: [Freedos-user] Not sure is it possible - but maybe I'm missing something?

2019-05-09 Thread C. Masloch

Hello,

On at 2019-05-05 18:16 +0200, ZB wrote:
> For testing small snippets of ML code "debug" is quite enough. But the
> disadvantage is that when I try to script it ("debug  using files like this example:
> 
> a 100
> mov ax,10
> [...some other ML code...]
> [...some other ML code...]
> [...some other ML code...]
> [empty line]
> [...more "debug" commands...]
> 
> ..it works just fine but it always returns to DOS prompt (I believe it
> always happen when it detects end of "script" file). Yes, I can save the
> snippet as binary this way before it leaves debug, but maybe there's a way
> to stay in debug's "shell"?

I needed something similar in my lDebug symbolic anyway, so I created a
quick patch to add a Y command in my fork of FreeDOS's DEBUG. You give
it a filename (LFN or SFN, use double quote marks if to escape blanks)
and it pushes the file onto an internal stack. The script file should
not include a Q command (since that quits the debugger entirely as it is).

I uploaded a build at https://ulukai.org/ecm/ldebug-64117aa565dd.zip --
The repo is available at
https://bitbucket.org/ecm/ldebug/src/64117aa565dde7183edcbd87f1a8c4896f71814a

Regards,
ecm


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

Re: [Freedos-user] New FASM and NASM versions available

2019-05-01 Thread C. Masloch

On at 2019-05-01 21:11 +0200, ZB wrote:
>> (While we still get DJGPP builds, there haven't been any 8086 builds
>> since 2005's 0.98.39.)
> 
> Actually, why? Are all of these programs that large - or there are some
> significant advantages in providing them as DJGPP builds? "Ordinary" x86
> build could work just fine, IMHO

I believe that there are some tables in more recent NASM that exceed 64
KiB in size, so they can't be addressed without segmentation arithmetic
any longer. And the compiler that was used (OpenWatcom IIRC) presumably
didn't provide that.

DJGPP builds are much easier to maintain because DJGPP is a mostly
compatible gcc/GNU environment.

Regards,
ecm

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

Re: [Freedos-user] DISGUSTED With Pundits!!

2012-10-12 Thread C. Masloch

 I have not posted on this forum in almost 5 months due to the
 rather VICIOUS attacks on me by Bret Johnson, Ralf Quint, and
 Tom Ehlert re: diskette detection in the UIDE drivers.

 However, this post has now become necessary.

A++ would read again

Regards from our Bunch of Trolls That Ruin (TM)

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Need your comments about the FreeDOS site

2012-09-26 Thread C. Masloch

 Example:

 WCD 5.2.0
 Erwin Waterlander has released wcd 5.2.0. [...]

 has absolutely no info about what the thingie is after all ;-)

I agree. Hmm... I think to vaguely remember what /this/ WCD was, but it's  
still not as clear as it could be. In general, maybe append a short  
description of what something is to the first sentence, or where  
appropriate expand acronyms or such.

Regards,
Chris

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Boot Disc

2012-09-26 Thread C. Masloch

I'll link to the 1.0 boot floppy image, under the FreeDOS 1.0 section.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img

Kernel on that image uses 386+ instructions... and it seems as if it does
that without (properly) checking for the presence of a 386.

That it's a 386+ kernel is just an oversight (or should be documented for
the image), but if 386+ kernels really do not abort with an appropriate
message on non-386 CPUs, that's a bug.

Does a kernel developer know whether such checks are... just kidding, I
examined the sources myself. In kernel.asm such a check does not exist or
(in recent builds and SVN revisions) it exists but isn't used to orderly
abort loading if the CPU isn't supported. It then jumps to _FreeDOSmain,
which is the C function FreeDOSmain in main.c. In the kernel on that disk
image, the very first instruction happens to be push fs, code 0Fh 0Ah,
which on pre-386 CPUs is an error (or at least not push fs).

The file kernel.asm (SVN r1705) is this one:
http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/kernel.asm?revision=1705view=markup

Note lines 194 to 196, where precisely in this latest r1705, Kenneth added
the comment TODO display error if built for 386 running on 8086 etc. I
can prepare a patch to implement this (I'd think entirely in kernel.asm)
if the kernel developers are interested.

Regards,
Chris

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual boot

2012-09-19 Thread C. Masloch

 Maybe you should reread what I wrote previously:

Right, sorry. I didn't look into that.

 grub root (hd0,0)
 grub setup (hd0,0)
 grub quit

I thought you were referring to how to *load* FreeDOS from within GRUB,  
considering how that was the topic previously. But that's of course  
installing (legacy) GRUB, presumably into a different partition then the  
primary partition that you boot FreeDOS from.

Using sys c: is indeed easy (using whatever letter currently represents  
the primary partition to boot) (more to the point would be sys c:  
/bootonly, or sys c: bootsect.bin /bootonly for chainloading the file  
and leaving the current boot sector alone), assuming you booted into a DOS  
to use the usual FreeDOS SYS.

So this set-up again has a requirement (of booting into a DOS first) that  
the GRUB 2 freedos command method doesn't have. But you would be right  
in now asserting now that the current FreeDOS installer needs that anyway,  
so overall installation might be easier using GRUB legacy. To clarify,  
switching from GRUB legacy to GRUB 2 for just one minor feature wouldn't  
be worth it usually too; I didn't mean to imply otherwise.

And there's another (definitive) disadvantage of GRUB 2: it has a slightly  
less compatible licence, GNU GPL v3+ instead of v2+. Even if one prefers  
v3, it does lessen compatibility.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Survey of available DOSes


 * DOSBox ... sure, it's only for games and is really its own fake
 DOS, but it sorta works and is free/libre, popular, and easy to find
 binaries.

 I wouldn't specifically include DOSEMU because it needs a real DOS,

DOSBox can also boot an actual DOS version (like dosemu always does),  
which improves DOSBox's compatibility a lot (eg testing function calls  
that are not supported by DOSBox won't immediately exit the emulation).

Unfortunately, at least as far as known to me, DOSBox's FS redirector is  
only available with the built-in DOS, not when booting a DOS inside it.  
For that usage, dosemu is better because it provides its MFS-based  
redirector for the booted DOS (using the lredir program).

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

 On a semi-related note, I think you can boot Win 3.x inside DOSEMU,
 DOSBox, etc. Even Mike Chambers' Fake86 can (mostly) boot it. There
 may even be some experimental support on some of those for booting
 Win9x, but since that's uninteresting to me, I've never delved deeper.

This is irrelevant to DOS compatibility when booting a DOS inside any of  
them. It'd only be interesting whether DOSBox's built-in DOS is able to  
load (any) MS Windows.

 MS-DOS / Win9x forced you to install in the very beginning of the hard
 drive. DR-DOS can install in subsequent partitions but has some weird
 limit regarding mounting and seeing previous partitions. FreeDOS is
 the most flexible in that it can see and use anything.

I don't think the FreeDOS kernel does properly boot from (or install in)  
file systems inside extended partitions. Even if you manage to boot it  
(possibly using GRUB), the kernel probably won't correctly determine the  
boot drive.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

 I think it still did use DOS file system calls, but I could be wrong.

It circumvented DOS for higher performance if no DOS software was  
intercepting or handling the FS and block device functions (from DOS Int21  
API through DOS block device down to ROM-BIOS Int13 API), at Windows  
start-up. If it detected any such interception, it would indeed run the  
affected FS in some sort of compatibility mode where it used the  
underlying V86 APIs (block devices, Int13) instead of its own ones. This  
incidentally disabled its LFN functionality for the affected FS.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual boot

   Is DosEmu actually capable of working with Portuguese
   diacritics and supporting a standard Brazilian keyboard in
   the first place?

It's probably possible, but it might require configuring dosemu more, or  
maybe even patching dosemu's source.

   And if DosEmu can't do it, would dual boot (Grub) be a
   good idea? I read the announcement in July that Grub 2.00
   supports FreeDOS.

GRUB 2 indeed supports loading FreeDOS, which just means you can directly  
specify the kernel.sys file to load instead if needing to chainload a  
FreeDOS boot sector. With the current kernel and current GRUB versions,  
you still need to install FreeDOS into a primary partition, though.

   Again, would dual boot be a good idea? If so, what could I
   use? Metakern?

GRUB is possible, too.

 My personal preference would be dual boot, but I wonder whether
 it would bring its own problems. Those are other people's
 computers, which I don't want to mess up.

In older PCs, idling was not regarded as necessary; with 1990s and more  
recent (powerful) CPUs proper idling is important.

Therefore you should enable the idlehalt= setting in the FreeDOS kernel's  
config, and/or load FDAPM with some setting. [One of them might suffice,  
but using both shouldn't be particularly harmful even if unnecessary.]  
fdapm apmdos (optionally prepend lh ) should result in the highest  
savings (though it might decrease performance a bit).

Failure to enable proper idling will cause one CPU (that is at least one  
core on multi-core CPUs) to permanently be 100% loaded in polling loops,  
wasting energy and heating up the CPU a lot. Even with FDAPM and such,  
some applications' polling loops disable idling - custom patching might be  
necessary to implement proper idling then.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

 Again, this was purely marketing, not technical, as MS wanted to
 exclusively bundle their DOS with Windows. With (very creaky) shims,
 DR-DOS was said to be able to boot Win95 (and proved such in court),
 
  Where and when was that? This lawsuit was never brought to trial in
  the first place...

 I don't know all the details, barely any actually.

 So why keep spreading such rumors? :-\

Sources specified in the article http://en.wikipedia.org/wiki/DR-DOS :

http://www.v3.co.uk/v3-uk/news/1996865/cebit-caldera-windows-dr-dos-denying-ms-claims
http://www.seattleweekly.com/1998-09-16/news/the-mouse-that-roared/  
(second page)

 Why do you think that back in the early days of Windows 95, the
 16bit thunking was such a big deal? That wouldn't have been at all
 necessary if Win32 and the old 16bit stuff weren't in effect two
 discrete entities...

Thunking is just API translation because of different pointer conventions  
and such. Arguably the existence and usage of Windows-4-style thunking  
between 32-bit and 16-bit components illustratively shows that Windows 4  
is close to its Windows 3 roots.

In x86 Windows NT, 16-bit subsystems known as NTVDM and WOW are enabled by  
default, but they seem to be separated more clearly from the main (32-bit)  
system.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual boot

 I read the announcement in July that Grub 2.00 supports FreeDOS.

 So does Grub Legacy, [...]

As opposed to GRUB 2, it additionally needs setting up the correct boot  
sector file (to be chainloaded from GRUB for loading the kernel), which is  
possible using FreeDOS's SYS.

There's a fork called GRUB4DOS which includes easier FreeDOS kernel  
loading similar to GRUB 2.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

Where neither source mentioned that there was anything proved in
court, as there was never a trial on that matter.

Right, it wasn't. So the rumour part was _only_ the mention of proved in
court, which it didn't quite reach. But it isn't a rumour at all that
MS-DOS 7 and 8 were unnecessarily tied to MS Windows 4.

Regarding that, more of the sources specify in detail that Caldera showed
(and even some of Microsoft's developers that worked on MS Windows 4 and
MS-DOS 7 explained/agreed) that both of them could very easily have been
separated:

http://www.maxframe.com/DR/Info/fullstory/tech.html (lots of details)
http://news.bbc.co.uk/2/hi/business/600488.stm (mentions settlement that
instead happened, and Caldera was able to demonstrate publicly Windows 95
running with DR-DOS, and it was thought unlikely that Microsoft would
win because of the strength of the evidence that Caldera had partially
disclosed)

There was an out-of-court settlement before it came to a trial, which
beside apparently putting some money in Caldera's

It is right that the settlement occurred instead.

robs us now to actual see what was claimed and what in fact the ties
between Windows 95 and DOS at that point was...

Even as we don't have the implementation, the first source above does
specify a lot of details.

And here's a less official, though also interesting source: a post
authored by Matthias Paul on 2007-12-18. It also has some technical
comments:

http://www.msfn.org/board/topic/109018-windows-98-in-dr-dos/page__view__findpost__p__721209

MP [...] WinGlue basically just faked a number of undocumented
MP interfaces and data structures, [...] it was decided to fork
MP the kernel and directly add full MS-DOS 7.0 (and later 7.1)
MP support into the DR-DOS kernel. The DOS 7 compatible fork was
MP nicknamed DR-DOS WinBolt [...]

So, WinGlue (Scheibenkleister) was a basic device driver to make MS
Windows 4 load, and WinBolt was a 7.02-ish fork of the kernel to fully
support the new interfaces. The post also acknowledges that a different
fork went on to be released as 7.03.

Rather to the contrary, if it would be that close, thunking should
not be necessary in the first place (or to a far lesser extend).

Without the parenthetical remark, you would be incorrect, because at least
pointers/buffers do have to be translated or made compatible somehow, no
matter how close the systems are [unless hypothetically the 32-bit APIs
artificially were limited to only using 16-bit registers and pointers].

And the issue of 16 bit thunking in Windows 95 ran itself out
after more and more programs where specifically written for Win32
instead of relying on old Windows 3.x 16bit code/DLLs.

That's to be expected regardless of thunking details.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual boot

 grub root (hd0,0)
 grub setup (hd0,0)
 grub quit

 Oh so difficult,

That also requires the boot sector to /already/ be set up correctly, just  
in the partition itself this time =)

 shenanigans, and 5-10 times the HD space sprawled across several
 directories and/or partitions, required to make Grub2 work.

I don't disagree that apart from this one feature, GRUB 2 might be more  
complicated to install or whatever.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual boot


 A:\ SYS C:

 [...]

 A:\ FDISK /MBR

Yep, you successfully circumvented GRUB now =P

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

 why does the line
 unlike the old ms dos freedos lets you access fat 32 file systems
 appear?
 fat 32 file systems existed in ms dos about 1997 or so.
 I have fat 32 partitions on my ms dos system in fact, and there is no
 windows on my computer whatsoever.
 While there are likely many things freedos can do, networking for
 example?, the fat 32 one as distinguishing it from ms dos is false
 information and should be removed.

I would suggest that we precisely quote the passage in question. I think  
you're referring to this one (please correct me otherwise):

page FreeDOS is basically like the old MS-DOS, but better!
page For example, unlike MS-DOS, FreeDOS lets you access
page FAT32 file systems and use large disk support (LBA).
[This is found under the heading Welcome to FreeDOS, in the answer What  
is FreeDOS?.]

Now, you're correct that later MS-DOS versions (those typically only  
bundled with MS Windows systems) did also support the FAT32 FS (as well as  
LBA access).

On the other hand, at least the first sentence quoted by me refers to old  
MS-DOS specifically, which might be understood to refer to the earlier  
(stand-alone) MS-DOS versions.

 Honestly even stating that freedos is sill under development unlike ms
 dos is distinction enough, and correct.

Another distinguishing feature important to many users (and developers  
alike) is the freedoms that apply to core FreeDOS software, including of  
course gratis unlimited redistribution which is completely legal for these.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?

 Yes, Win95 OSR (or whatever) introduced FAT32 later on, but it wasn't
 in DOS per se,

This does not accurately describe the technical circumstances.

If we were to discuss LFNs, in that case the MS-Windows-bundled DOS  
versions alone did indeed only provide rudimentary help and application  
support, with the important core LFN driver only inside Windows code.  
However, opposed to the LFN situation, the MS Windows 4.10 implementation  
of FAT32 was also accompanied by a DOS implementation of FAT32.

So, FAT32 very much is in DOS per se there, though only in these new  
Windows-bundled MS-DOS versions.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] false info on the freedos home page?


 still the point is as you shared yourself, might be understood  to mean
 older stand alone ms dos, it might not as well.   be understood..that is.

I agree.

 for my part, the edition of ms dos 7 i run was packaged by developers  
 much like yourselves.

I maybe would personally prefer not to be compared to them.

 Is it official ms dos stand alone? perhaps not.

I am not aware of any legitimate (legal) stand-alone MS-DOS versions 7 and  
up. I have been made aware that apparently one or some highly questionable  
distributions exist, but this mailing list probably isn't apt for  
evaluating these. (To clarify if needed: the previous is only my personal  
opinion.)

 is it bundled under windows? not at all.

This might be right. I think it's not important whether that's true,  
though.

Significantly, these MS-DOS versions existed, even if we only consider  
them when they were bundled with MS Windows (whether versions 4, or later  
as the contents that a floppy disk receives if formatted to be MS-DOS  
bootable or such).

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] about lfn...?

Hi Karen,

 Does freedos have its own long file name utility?
 If so, is it close enough to ms dos to be run?
 Just curious, the person I know seeking it says they are running freedos,
 but they are using the old ms dos 7.1 lfn command.
 Made little sense to me, unless there is no specific freedos utility for
 it?

It depends on what they mean by LFN command. I imagine they might be  
referring to DOSLFN, the extension initially developed by Henrik Haftmann  
which enables FAT's LFNs (for all LFN-aware applications) without needing  
to load MS Windows.

In that case, DOSLFN was developed to run on MS-DOS 7.00 and up initially,  
but it now does function properly with older MS-DOS versions and others  
such as DR-DOS and FreeDOS as well. In fact, it has been distributed along  
with FreeDOS for some time, and most recently is maintained by Jason Hood  
- not only for MS-DOS! In the FreeDOS website's software list, you can  
find DOSLFN in the UTIL category, or with this direct link:  
http://www.freedos.org/software/?prog=doslfn

If this doesn't seem similar enough to what they were referring to, it  
might help if you could describe more what they and you mean by LFN  
command.

If they were referring to DOSLFN, then they can use their old MS-DOS 7.1  
DOSLFN with FreeDOS, though it might be advisable for them to insure that  
they're using an updated DOSLFN (for both MS-DOS and FreeDOS). If they  
want that, please refer to Jason Hood's web page on DOSLFN (Primary site  
in the software list entry, linked above) for selecting the appropriate  
version - if you're using SHSUCDX or no CD FS redirector along with  
DOSLFN, the latest DOSLFN version should be the right one. There's another  
(older) one only required for using other CD FS redirectors such as MSCDEX  
along with DOSLFN. The latest one is currently 0.41b, and the alternative  
older one is 0.34d.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] fdconfig.sys syntax

2012-09-15 Thread C. Masloch

 This seems a poor way do discover what I see in the initial fdconfig.sys
 file created by the FreeDOS installer, which is very broken and useless

I think the FreeDOS 1.0 installer wrote a menu for these choices, which  
was more useful. If the new installer left you with no menu display by  
default, that's an error in it.

 Obviously the FDCONFIG.SYS options can be selected via [01234], but it  
 would be nice to be able to see the boot menu and not have to blindly
 select from a hidden list of options

Right. The config file should use menu to display a menu, and optionally  
menudefault. Note that what is displayed using menu doesn't actually  
create the menu; as you see the config handling already asks you for a  
menu using your current (default installed?) configuration. The menu  
command is more like the echo command but intended for displaying the  
config menu.

menu: http://help.fdos.org/en/hhstndrd/cnfigsys/menu.htm
menudefault: http://help.fdos.org/en/hhstndrd/cnfigsys/menudef.htm

 instead of unhelpful partitioning info at boot time.

If you prefer, that can additionally be turned off:

sys config c:\kernel.sys showdriveassignment=0

The file name here must specify the kernel that you use to boot, typically  
found in c:\kernel.sys. If the file name is kernel.sys and the path  
(typically c:\) equals the current directory then you need not specify the  
file name at all.

The command syntax is described at  
http://help.fdos.org/en/hhstndrd/base/sys.htm

The following file (kernel's sys.txt) describes these kernel settings:  
http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/sys.txt

Regards,
Chris

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Can you help me?

2012-07-11 Thread C. Masloch

 There is also Dissecting DOS, ISBN: 0-20162-687-X, by Podolsky;

Without commenting on my opinion of the book or RxDOS; no, I don't think  
the author's named Podolsky ;)

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Can you help me?

2012-07-11 Thread C. Masloch

 Podanoffsky, isn't it? :)

Yeah. At least my copy does have Michael Podanoffsky on it! =)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 If code is released to the public domain, anyone can use it
 without restriction.

Right.

 But there would be no license to protect us, to keep someone like
 Microsoft from copying our code, and re-releasing it as their own
 under a proprietary license.

Yeah, that's a subset of anyone can use it without restriction.

 So as I wrote my programs, I started to use the GNU GPL. This made it
 clear that anyone could use my programs, and the source code would
 remain free and open to everyone.

That last part is not entirely accurate.

 [...] it prevented others from re-releasing my programs without
 making sure people had access to the source code.

That, however, is accurate.

 I was happy with that. I opted not to use MIT or BSD for personal
 reasons, I just thought the GNU GPL was the right one for me.

Similarly to releasing things into the public domain (where applicable),  
those licences differ from the GPL in that they do not impose copyleft. So  
following your perfectly understandable above explanation, of course you  
specifically wanted a licence with copyleft. Moving from public domain to  
a MIT-style licence wouldn't have added any copyleft (only attribution,  
that is, the requirement to display the copyright notice somewhere).

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 I just ask that you choose a license that preserves the freedom
 of the source code, so that everyone may use it and contribute to it.

Rhetorically speaking, MIT-style licences could be read as not preserving  
the source's freedoms as much as licences with copyleft (such as the  
GPLs). (Note the distinction of source's freedoms and recipients'  
freedoms in this paragraph of my reply and the next. This is important.)

 Avoid licenses that limit the freedom of users, including licenses
 that look free but exclude certain classes of users (May not be used
 by the military or For non-commercial use only.)

Or for legal use only or for ethical use only etc. (Seen 'em all.)  
Technically, the GPL does restrict an individual user's freedoms as well,  
though their disadvantage there is of course only to insure the freedoms  
of (potential) downstream recipients.

 However, these different
 licenses does make it a bit difficult to share code between projects,
 if they have different licenses.

Specifically, if (incompatible) copylefts are involved.

 That's another reason why I prefer to
 contribute only to programs under the GNU GPL, so I can easily re-use
 code from one project to help out another.

Ah, but you could do so if you primarily contributed to programs under  
MIT-style licences as well. And, specifically, the MIT-style licences  
allow anyone to relicense the content under the GPL (ie adding copyleft),  
but it naturally doesn't work the other way around.

 As far as the version of the GNU GPL, I happen to prefer version 2 for
 DOS programs because I think version 2 applies well to
 statically-linked programs (typical in DOS.)

The most licence-compatible option (if you have already decided to employ  
the GPL) is to chose wording (such as the FSF's default suggestion) which  
allows GPLv2+; if you merely specify GPLv2 but do not explicitly state  
the option to change to a newer one, then this is the same as explicitly  
specifying GPL v2-only (like the licence of current Linux releases) -  
that is, that source's copyleft is then incompatible with the copyleft of  
source released under GPLv3(+).

Not to imply you didn't know all of those details. I merely felt that your  
descriptions here could use some more context. After all, while it's all  
perfectly simple, choosing a licence should occur after one has learned of  
the potential consequences of such a choice.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Licensing and copyleft (Was: Re: FreeDOS compatibility with DOS applications

~Warning~: Pedantry ahead. Only read on if you dare.

(Then again, if you read more than eight bits of my past contributions,  
you probably already recognised that I'm a proud and unapologetic pedant.)

 Other licenses may be more free in that they have less restrictions,
 including the copyleft.

Precisely. It merely depends on which freedoms we're referring to.

 That's great for them, but that's not the kind of commercial
 activity I want to support.

That's great for you. So what?

 If somebody uses open source code, they
 should be willing to show their changes for others to build on.

(Which isn't exactly what the GPL's copyleft enforces, because the only  
others who must be provided with the changed source are downstream  
recipients. There is no notion of community or public intrinsically  
linked to it. For that, see  
http://en.wikipedia.org/wiki/Reciprocal_Public_License - incidentally, not  
FSF-approved and avoided by others as well.)

 I have been a user of open source code (GPL) for over 20 years now
 starting with early versions of gcc.  Before I released my own code
 under the GPL v3 I was paid by a major corporation with three initials
 to write open source code, usually under GPL2.

GPL2, really? Do you mean v2 only? Or v2 or later?

 That same corporation
 was a major player in open source and spent a lot of time making sure
 they complied with the rules, including redistribution of changes.  It
 works for them and it works for a lot of other people.   I find it hard
 to imagine how something so simple gets twisted up in meta discussions.

I find it hard to imagine how this thread's current topic (which, by the  
way, still was about FreeDOS compatibility with DOS applications... just  
another sort of compatibility!) could be considered a meta discussion  
that twisted up anything.

I'd specifically like to reject your compliment that this discussion is in  
any way meta, because in the current culture any software development  
requires licensing decisions. Even just releasing source code without any  
statement this or that way is considered to imply a decision. So,  
arguably, licensing becomes part of writing software, merely a different  
kind of technical matter. That is all so regardless whether a particular  
developer appreciates it. And if they're the one to make these decisions  
then I believe they should be aware.

 Show me where somebody was harmed by the copyleft provisions of GPL
 licenses ..

Isn't that obvious? Any incident can be considered harmful in which the  
GPL specifically causes someone to refrain from re-using code (whether an  
entire project or only a tiny part of it) and they instead re-implement  
similar functionality, but worse. Note that I don't care about the  
success of a particular business that depends on selling copies of  
software without Free source, but (regardless of how the software is  
developed and distributed) in such cases there is still harm for any  
recipient/user because the software they get to use is worse than it could  
be if everyone had worked together. (Arguably, whenever the software is in  
some way networked and communicates with other users' software, the others  
might be disadvantaged as well - for instance, because the  
re-implementation adheres to protocol standards less well than the  
copylefted alternative does.)

Unquestionably, in such scenarios a licence with (severe) copyleft is less  
harmful than, say, one where the source isn't released at all. For that  
reason as well, I consider it disingenuous to refer to copyleft as somehow  
viral unless one would too refer to any kind of closed-source licensing  
as viral in the same manner (though more severely).

What is unquestionable too is that copyleft of whatever severity is a  
compromise that, well, forces individual recipients to pass on their  
source changes (at least) to downstream recipients. And if you find that  
compromise works for you, yeah, great, go for it!

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Licensing and copyleft (Was: Re: FreeDOS compatibility with DOS applications

I agree, I'm certainly overly pedantic and unreasonable and silly.

And you're the one using the term intellectual property as if that was a  
coherent concept.

=)

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Licensing and copyleft (Was: Re: FreeDOS compatibility with DOS applications

lol

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 I'm not sure if this is a bug, misfeature, lack of testing (re:
 FreeDOS specifically vs. arcane dark corners of MS-DOS), or user
 error.

You don't need to be sure, because I am sure enough what it is.

And what it is, is completely broken file system semantics. Nothing to do  
with arcane dark corners of MS-DOS. To the contrary, /not implementing/  
proper file system semantics would have been entirely nonsensical if not  
for compatibility with MS-DOS (without its SHARE). So FreeDOS reproduced  
this unfortunate architecture (ie file locking implemented in a loadable  
external module that interfaces with the kernel).

The problem is that even with FreeDOS's SHARE loaded, file system  
corruption occurs (reproducibly), and in cases that do not fail on MS-DOS  
with MS-DOS's SHARE loaded.

 As good as FreeDOS is, obviously we haven't ever had a big
 company kicking the tires. So some minor flaws may persist, but
 overall it seems to works very very well.

 I'd like to hear what Jeremy or Japheth have to say, esp. as I don't
 recall either of them weighing in on this. But others (hi, Tom) seem
 more pessimistic about it ever being fixed. As much as I like
 FreeDOS, it does seem unlikely that more will get done unless we get
 more volunteers. I'm not too skeptical, but I guess it's more
 realistic (defeatist?) to just accept that FreeDOS will always have a
 few bugs (like any software). We can't have everything, I guess.

If there are enough active kernel developers around, eventually one of  
them should ask me for the small test case program that I created, or  
other technical information required to fix this bug; unless they figured  
it out all on their own already of course. (Naturally such technical  
communication might be more appropriate somewhere else instead of  
Freedos-user.)

But you're right, maybe there aren't.

 But, to be fair, this is not something that most people need, and only
 Marcos seems to have run into this issue. I guess most of us are more
 tame in our usage. At least the code posted on BTTR seems to be user
 error that nobody in their right mind would willingly write:
 fopen(test1,wb) twice in near succession.

Nope, you're wrong.

Besides, that is a typical case that the type of fix I'd propose would  
correctly[*] handle, but the addressed underlying design flaw can cause  
other failures as well (such as when deleting an opened file; according to  
RBIL's Int21.41 description SHARE should insure that no file system  
corruption occurs then).

Additionally, the two opens need not necessarily come from the same  
program. After all, there is resident software (besides networking  
servers) which does (write-)access files.

[*] Correct here refers to not causing any file system corruption; in this  
example, data written to that file later would overwrite data written to  
the same file earlier (seeing as no file region locks were put in place  
and the file access modes allowed writes from several handles).


Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 In very rare cases only, though.

Irrelevant.

 Admittedly nobody wants corruption, but I don't think most people rely
 on deleting open files (except POSIX, so it's probably only a problem
 when porting GNU stuff to DJGPP).

Inaccurate. RBIL's notes seldom refer to programs that target POSIX.

 practically nobody (or not enough) has
 encountered this bug

Over-abundant usage of quotation marks.

 frequently enough to care to even whine, much
 less fix it themselves, so far. Obviously I'm in favor of fixing it
 (esp. in lieu of just using Linux), but I'm not a kernel dev.

Yeah, right now am uninterested in putting effort into GPLed C code.

regards
C

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 FWIW, I use MS-DOS on a daily basis instead of FD for reasons like  
 this.  MS-DOS is, by far, the most stable of the DOS's, and is still the  
 minimum standard to which others must compare.  I would classify  
 possible file corruption as a major problem, not a side issue.

You do always load its SHARE though, right?

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

 No, not by default.  According to the official documentation (e.g.,  
 the MS-DOS on-line HELP utility), you only need SHARE in a network or  
 multi-tasking environment, which doesn't apply to my current situation.

Then the particular problem in question is generally not a reason to  
prefer MS-DOS, because whenever you do not load their respective SHARE  
extensions then both the MS-DOS and the FreeDOS kernel are /designed/ to  
allow possible file corruption in this and more cases (which by the way I  
would agree to classify as a major problem, not a side issue).

Or in other words, the official documentation is bad. Unsurprisingly so.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS compatibility with DOS applications

2012-07-01 Thread C. Masloch

 Recently there was a thread
 about concurrent file access in the network - apparently FreeDOS
 SHARE and kernel support for it are not as good as in MS DOS

... where this not as good support apparently amounts to may corrupt  
your file system when concurrent write access occurs. This, naturally, is  
expected for MS-DOS-lacking-SHARE semantics; with the FreeDOS kernel  
though, there seems to be some missing functionality even with its SHARE  
loaded! [I just created and ran a particular test on the latest kernel  
release (build 2041 compiled 2012-02-07) with the latest SHARE  
(2005-09-14) loaded and it reproducibly causes clusters to be lost. I  
believe that more serious file system corruption is possible as well.]

Concurrent file (write) access is often incorrectly conflated with  
networking, but can in fact occur even on a single-tasking single user  
system that doesn't run anything network-related. (For historical reasons,  
most typical DOS programs try to avoid accessing files in a way that would  
expose such problems, of course.)

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Networking

2012-06-19 Thread C. Masloch

 conclusion: don't use FreeDOS as a 'server' machine.

 Sure, that's the obvious easy way out.

 But wouldn't it be better overall (and wiser) to 1). actually find
 out what MS-DOS does, and 2). fix it in FreeDOS' kernel?;-)

If you are indicating that you want to volunteer... ;-) (... if that would  
indeed be the case, then I'd suggest gaining practice in C, in 86-mode 386  
assembly language, and in using a capable enough 86-mode debugger to  
inspect DOS kernels as well as reading Undocumented DOS Second Edition  
and DOS Internals at least, plus optionally FreeDOS Kernel as well.  
[*] Then, one would have to become acquainted with the FreeDOS kernel's  
sources. And then the required course of action would either be  
self-evident, or one would have to start getting creative!)

Regards,
Chris

[*] Don't read Dissecting DOS though.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Networking

2012-06-19 Thread C. Masloch

Thanks. Here's some comments if you care to read them. Not all of them are  
particularly relevant to our thread's topic.

 MSDOS, and presumably FreeDOS, does not natively provide a framework for
 safe filesharing and file locks, this needs to come from the server  
 software
 working in combination with requests from the application via the client
 networking.

If the server software is running on top of a DOS, it either needs to  
implement locking separately (in the server application), or it has to  
rely on locking being implemented by the DOS kernel.

 Normally when a simple DOS application opens a file it opens it
 in a specific mode, eg read or read/write, and when a file is opened in
 write mode it is opened exclusively, so any process that tried to open  
 the file is given an access denied.

If this is meant to refer to the normal case of local file system access  
without a proper SHARE extension loaded on eg MS-DOS and FreeDOS, then  
this is incorrect. The problem is that processes are allowed to freely  
access the same file in parallel, without any checks going on.

 and another mode for programs that did not like how share.exe worked.

This other mode is the compatibility mode, and it presumably was only  
intended to allow older, mode-unaware programs to continue to work.  
Unfortunately, even most DOS programs developed after the introduction of  
the new modes continued using compatibility mode.

 Share.exe maintains two tables in memory, one for
 each file that is opened, and another for which portions of the file were
 locked, and what mode the portion was locked in

Crucially, the entries in that new file table are unique (that is, each  
existing file might have at most one entry) and they link to all entries  
in DOS's other (SFT) file table. Lacking the new table, duplicate entries  
in the other table are entirely undetected.

 I have run DP over many many different server and networking client
 combinations, with up to about 40 simultaneous connections and not ever  
 had a problem unless I was running share.exe on the client

I don't understand how this could have happened. Given what I know,  
SHARE should only affect access to the local file system. And using it  
as opposed to not using it should definitively not cause problems.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] (no subject)

2012-06-16 Thread C. Masloch

 if the answer to 2) is 'FreeDOS' then either SHARE.EXE is not running
 or SHARE.EXE is buggy. the latter is quite likely as it was never
 really tested against network access.

 I think SHARE.COM must be running because the two-computer test
 network works perfectly -- as long as the two users won't press
 and hold arrow keys of PgUp/PgDn simultaneously, or try to run
 reports from the client. In other words, as long as server and
 client don't attempt to access the hard drive in the same
 millisecond or so.

That is not the right way to determine whether SHARE is loaded.

Your conclusion hence might quite plausibly be wrong.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Networking

2012-06-16 Thread C. Masloch

Hi Tom,

This might be irrelevant to the case at hand.

 if the answer to 2) is 'FreeDOS' then either SHARE.EXE is not running
 or SHARE.EXE is buggy. the latter is quite likely as it was never
 really tested against network access.

If you know; does FreeDOS's file locking (ie SHARE) propagate file  
metadata changes to all SFTs referring to the same file?

Here's some context for anyone interested:  
http://www.bttr-software.de/forum/forum_entry.php?id=11572

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Warning: using suspect partition

2012-05-13 Thread C. Masloch

 However, I get a warning on boot: InitDisk Warning: using suspect
 partition Pri: 1 FS 0C with calculated values 970-42-42 instead of
 1018-8-40. I've tried partitioning the disk with different CHS values,
 but it always complains that the calculated values are different than
 those other values(I guess the bios supplies them). Neither set of
 values are exactly the same CHS that I actually used to partition the
 disk in the first place. Anyway I think it should be using lba anyway,
 so does it even matter? and if it does, is there a way to fix it?

initdisk.c contains the following notice in one of the comments:

 However we need to be safe, and with varying CHS at different levels
 that might be difficult. Hence we _only_ trust the LBA values in the
 partition tables and the heads and sectors values the BIOS gives us.
 After all these are the values the BIOS uses to process our CHS values.
 So unless the BIOS is buggy, using CHS on one partition and LBA on  
 another
 should be safe. The CHS values in the partition table are NOT trusted.
 We print a warning if there is a mismatch with the calculated values.

So that seems to be the warning you see. According to the notice, then,  
this simply means the kernel determined that the exposed geometry[*] of  
the actual CHS interface (as provided by _the currently running_ ROM BIOS)  
doesn't match what was apparently used to record the partition table  
entries' CHS information. If the ROM BIOS's interface works as it is  
supposed to, this condition will not cause any further problems. (However,  
primarily some boot loaders rely on the CHS information in the partition  
table to be correct instead of re-calculating CHS information using the  
LBA information as well as what a geometry query to the ROM BIOS returned.  
These programs will fail to function correctly. If the boot process  
appears to work correctly for you, then the loaders you are using are not  
affected.)

[*] As usual, this generally does not directly correspond to a disk's  
physical geometry nowadays.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] LH PCNTPK INT=0x60 not working

2012-05-04 Thread C. Masloch

Hello Henry,

 One of the steps of the
 howto says to edit autoexec.bat changing the line REM LH PCNTPK
 INT=0x60 to LH PCNTPK INT=0x60. This didn't work for me. Somehow the
 packet driver was never actually loaded on startup. What did work is
 changing the line to PCNTPK INT=0x60 without the LH. I'm not much on
 batch scripting so I'm not totally sure what LH does, but some
 googling reveals that it means Load Highmem. Can anybody give me an
 explanation?

LH, Load High, is a command to load a process into the Upper Memory  
Area, UMA for short, if it is available. I'll quickly explain the involved  
concepts and what LH does in the next four paragraphs, but it isn't  
crucial to know all of that, so you may skip these if you want to.

---

The Lower Memory Area, LMA for short, is the first 640 KiB of memory  
usually thought of as DOS's normal memory. This is not because of  
restrictions that always were inherent to the 8086 architecture or DOS's  
memory allocation, but because IBM when designing their first PC (which of  
course went on to make early MS-DOS popular) decided that it would be  
reasonable to reserve the entire upper 384 KiB (37.5 %) of the 1 MiB  
address space of the 8086 exclusively for usage by the ROM BIOS and  
memory-mapped I/O. Later, it became usual to map the video card's graphics  
buffer at linear address A_h, or 655360. This is precisely at the 640  
KiB boundary, which means that on machines potentially using the graphics  
buffer there, continuous address space for DOS memory only ranges from ca.  
0_0600h to this A_h address. This is the LMA.

MS-DOS 5 and later, as well as compatible systems such as FreeDOS, have  
standardised a specific interface that lets DOS manage the mentioned UMA,  
which is the in principle reserved 384 KiB from linear address A_h to  
just below 10_h. DOS doesn't concern itself with insuring that usable  
RAM is actually mapped in there; this is the responsibility of driver  
software such as, most commonly, EMM386 (of which various variants exist  
 from several vendors). The configuration program built into DOS will,  
during the processing of (fd)config.sys, query a specific (XMS) interface  
for unused UMBs (Upper Memory Blocks, ie blocks of memory in the UMA), and  
allocate all of them. All such allocated UMBs are then added to DOS's  
memory management.

However, by default, DOS only will let a program see the default (LMA) DOS  
memory, that is, continuous memory inside the first 640 KiB. This is for  
compatibility with programs that do not know of the existence of UMBs,  
especially as they might expect most of the available DOS memory to be in  
a single continuous block, which is not generally the case if considering  
both the UMA and the LMA on systems where DOS grabbed UMBs. Hence, there  
is a special way in which application programs must tell DOS to make DOS  
UMBs visible if they wish to allocate them.

This is where LH comes in: by default, loading a DOS process by entering  
its program's name after the COMMAND.COM (or FreeCOM) prompt will only use  
the LMA, consequently placing the process itself entirely inside the LMA.  
Prefixing the program's name with the LH statement will effectively first  
tell DOS to make its UMBs visible (if there are any), and then load the  
newly created process while preferring UMBs to LMBs (= memory blocks in  
the LMA). This means that the process itself will be loaded into a UMB if  
it fits. This is especially useful for TSR programs, unless the program's  
installer has special code to relocate into a UMB automatically, in which  
case additionally using LH would be useless. (Most older TSR programs do  
not have that sort of code, so LH is necessary if you want the resident  
portion to end up inside the UMA.) If there are no available DOS UMBs,  
then prefixing a program invocation by the LH statement should effectively  
be the same as just invoking the program without the LH statement.

---

I would speculate that in your case the problem was that apparently,  
loading the PCNTPK program to install the packet driver using LH failed in  
some way, while attempting the same without LH succeeded. As I have  
indicated in the last sentence of the previous paragraph, this should not  
occur. It is possible that your system does not offer any DOS UMBs. It is  
further possible that LH as implemented by FreeCOM (FreeDOS's COMMAND.COM)  
might be broken here in that situation, or that regardless of DOS UMB  
availability some other unexpected circumstance occurred which lead to  
this unexpected outcome.

In any case, loading the driver without LH doesn't cause any harm apart  
 from a possibly slightly disadvantaged memory usage layout. However, what  
you have described does seem to point to an error in FreeCOM or possibly  
in other FreeDOS components, so thank you for reporting this irregularity.  
The FreeDOS developers might ask for your future assistance about this.

Re: [Freedos-user] Concerned about a site...

2012-04-09 Thread C. Masloch

 Problem I see is, the OS used is freedos and the disc costs $34.95 to  
 activate. [...] Is the way freedos is being used here legal, or have I  
 discovered an abuse?

If they provide all required sources (ie of GPL- or similarly-licensed  
programs) along with their discs, it is legal. Free software can be sold  
legally.

regards,
CM

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem after updating to FreeDOS 1.1 with writing of environment variables.

2012-03-07 Thread C. Masloch

 Now the problem was when we wrote this, that there was no way
 to store any data to pass it back to the calling batch file.

 We had a clumsy turbodisk memory partition (there is no writable storage  
 on
 our system when running under FreeDOS), so we write a batch file in that
 partition with the environment variables we need, and then the calling
 script executes than batch file on exit to pickup those set environment
 variables.

Sounds good.

 Anyway, updated to latest FreeDOS and this no longer works.   The  
 turbodisk
 is getting created fine, it's being formatted, and we can find it's drive
 letter correctly using the find utility.

So... how exactly doesn't it work then? Is the file created? Is it called?  
(Try to insert some echo commands into the batch script and check whether  
they're visible.)

regards,
C. Masloch

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

 Dear List... I'm calling back with respect to the 4k-sector USB disk  
 drive. I'm considering writing a loadable DOS 'block' driver for it, as  
 Eric Auer suggested.

This doesn't belong on Freedos-user then.

 I would like to take the simplest approach possible first, even at the  
 expense of performance. My driver would be little more than a 'shell'  
 around USBASPI.SYS.

What exactly do you want to accomplish with that?

 - Using a loadable driver for the block device implies DOS won't use  
 /its/ internal buffers, so I don't have to care about DOS own buffers  
 sizing, right ?

This is wrong. Block drivers directly interact with DOS and its buffering  
scheme. If what you want is to circumvent the restrictions imposed by  
DOS's buffering scheme (for example, current 512B-/2048B-sector limits of  
the FDK) you'll have to write your own (FAT) file system driver which  
interfaces downwards with the block device driver (in your case,  
USBASPI.SYS) and upwards with DOS's file system redirector interface. (The  
redirector interface is what file system drivers for non-FAT file systems  
(eg *CDEX) and networked file systems use to make their files accessible  
to DOS. Your case, as I understand it, would be a special case to  
circumvent DOS's FS driver's limits.)

regards,
C. Masloch

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] writing a loadable block driver for 4k-sector drive (Questions)

 This doesn't belong on Freedos-user then.

 Maybe Czerno / Bertho is not on freedos-devel?

Then they should subscribe to it.

 Or maybe there is
 simply too little traffic on freedos-devel, so he preferred to
 give it a try on freedos-user... I am CCing -devel here,

I'm keeping -user as the main recipient until OP moves.

 If your block device driver shows the DOS kernel a device
 with 512 byte per sector virtual sectors then the kernel
 will happily use 512 byte per sector BUFFERS for them...

Oh, that's what you meant.

 This is wrong. Block drivers directly interact with DOS and its  
 buffering
 scheme. If what you want is to circumvent the restrictions imposed by
 DOS's buffering scheme (for example, current 512B-/2048B-sector limits  
 of
 the FDK) you'll have to write your own (FAT) file system driver which
 interfaces downwards with the block device driver (in your case,
 USBASPI.SYS) and upwards with DOS's file system redirector interface.

 This is also wrong. Because the filesystem still is FAT
 and the kernel does already understand FAT, your driver
 can present your 4 kB per sector disk as a BLOCK device
 or in other words: As a bunch of sectors. However, your
 driver has to transform what the DOS kernel sees of the
 boot sector and BPB, because the whole idea of having a
 4 kB disk support driver for 512 byte per sector DOSes
 is that it shows the kernel a bunch of 512 BYTE SECTORS
 (virtual ones) instead of showing the real 4 kB sectors.

Apologies, I misunderstood the request. I should have thought of your  
(Eric) sector size downwards transformation suggestions of earlier.

 This DOES circumvent the limitation of the DOS kernel:
 The kernel only sees 512 byte per sector blocks. But
 as explained above, now your driver will have to spend
 at least 4 kB of buffer space for the transformations.

This is accurate.

 redirector interface is what file system drivers for non-FAT file  
 systems
 (eg *CDEX) and networked file systems use to make their files accessible

 That would mean that you duplicate the whole logics of
 understanding the FAT filesystem into your driver.

Correct.

 NOTE: Transformation of sector sizes is easiest in FAT32.
 Other FAT sizes may take more effort.

I don't think so. Why would they? Cluster size stays the same, no  
FAT-related special handling (which would be more complicated for, say,  
FAT12) is necessary as far as I can tell.

 Also, you can only
 transform from 4096 byte units to 512 byte units if the
 filesystem is at most 2 Terabytes and cluster size is at
 most 32 or maybe 64 kilobytes.

Right, the usual 32 (or for some OSes, 64, 128, etc) KiB cluster size  
limit still applies here.

 You CANNOT transform from
 512 to 4096 usually, as format tools do not take care to
 align things in a way that would make this easy enough.

True.

 Of course you CAN transform back a FAT32 partition from
 an originally 4 kB per sector disk to 4 kB sector disks
 after you accessed it in 512 byte units and even if you
 actually stored it on a physically 512 byte per sector
 disk and used it there. This only needs the boot sector
 transform to be transformed back :-)

Right. Even a file system originally created with 512 B sectors could be  
transformed into using 4 KiB (or other  512 B sizes) sectors if the  
file system structures (reserved sector number, FAT size, root size. And  
the cluster size must be = target's sector size) are properly aligned; as  
you implied.

regards,
C. Masloch

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] writing a loadable block driver for 4k-sector drive (Questions)

 NOTE: Transformation of sector sizes is easiest in FAT32.
 Other FAT sizes may take more effort.

 I don't think so. Why would they? Cluster size stays the same, no  
 FAT-related special handling (which would be more complicated for, say,  
 FAT12) is necessary as far as I can tell.

Sorry for replying to my own message, but I just thought of something here  
again. You're probably referring to the root directory alignment handling,  
which of course is not needed in FAT32 as its root directory is not in a  
specifically reserved area.

As I noted in our (Eric) previous correspondence, the special case where  
some rounding is required (which might imply an incompatibility) doesn't  
usually occur (as formatting software usually leaves no unused directory  
entries in the last sector).

 You CANNOT transform from
 512 to 4096 usually, as format tools do not take care to
 align things in a way that would make this easy enough.

 True.

Another additional note, as I went thinking about this a bit. Only cluster  
values are stored in the FS (think FAT contents, FSINFO, and start  
cluster fields of directory entries) apart from what is in the *BPB, so a  
runtime upwards sector size transformation (say, from 512 B to 4 KiB, or  
 from 128 B to 512 B, or whatever) is still possible, just more  
complicated. I'm not certain, but my intuition is that it'd still be  
rather trivial to do.

As might be thought to be implied, transformation from 512 B away seems  
rather pointless now, but as I remarked in the previous paragraph, an  
upwards transformation could be /to/ 512 B if the stored file system  
(whether it is stored on some physical medium, in a file as an image, on a  
RAM disk, etc) uses smaller sectors.

regards,
C. Masloch

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] writing a loadable block driver for 4k-sector drive (Questions)

 Another additional note, as I went thinking about this a bit. Only  
 cluster values are stored in the FS (think FAT contents, FSINFO, and  
 start cluster fields of directory entries) apart from what is in the  
 *BPB, so a runtime upwards sector size transformation (say, from 512 B  
 to 4 KiB, or  from 128 B to 512 B, or whatever) is still possible, just  
 more complicated. I'm not certain, but my intuition is that it'd still  
 be rather trivial to do.

missed mentioning one condition: cluster size must be large enough

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] writing a loadable block driver for 4k-sector drive (Questions)