Re: [Freedos-devel] Ré : Ré : T2308 invalid partition signature after format
Hi guys, b0 7c 00 00 bb aa 55 b4 41 cd 13 72 32 81 fb 55 aa [...] I am a bit surprised the signature is also at the end of 0xb0 address line. Don't be: that's code checking the signature and it only _happens_ to be "aligned" there. :-) Joe ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fw: I need win32base.zip
Hi guys, I just received W32NASM.ZIP from TomCat but it's older (version 0.06, file date 1999-11-01) than the one inside the http://master.dl.sourceforge.net/project/win32nasm-cache/Win32NASM__60c5ed87f2e79d6259e9b2846049e051..7z?viasf=1 package (version 0.08, file date 2000-11-29). In case you're interested anyway, I uploaded it to http://sta.c64.org/shared/w32nasm.zip . Joe ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fw: Aw: I need win32nasmbase.zip
Hi guys, I found Tomcat's (Kaproncai Tamás) probable current email addrss and wrote him (in Hungarian). Hopefully, he won't mind the intrusion and dig up the ftp://ftp.szif.hu/pub/demos/tool/w32nasm.zip file from his archive. Joe___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi Tom,
offer Japeth (or other developers) this money to implement your wishes?
That would be weird in a _Free_DOS(-related) project. ("Free" in the
"gratis" meaning here, not the "open source".)
you are aware that 80+% of linux developers are paid for there work?
I din't know but why should I care? Good for them. :-) They accepted the
situation that this is their job, with all advantages (being paid etc.)
and disadvantages (having a boss etc.). I'm sure they (i.e. the companies
they work in) _do_ sell something - e.g. professional customer support -,
otherwise they couldn't make money, unless they are crowd sourced or
company/government sponsored (?).
However, _this_ is FreeDOS, not GNU/Linux. I was trying to show you the
mindset why possibly a money offer wouldn't work at all - perhaps, even
the opposite - in a different kind of "society". I never had the feeling
that someone here tried to sell anything, only be proud of their
accomplishments that became part of FreeDOS. Bye,
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi guys,
(Apart from the condescending tone...)
offer Japeth (or other developers) this money to implement your wishes?
That would be weird in a _Free_DOS(-related) project. ("Free" in the
"gratis" meaning here, not the "open source".)
I personally would feel it insulting if someone offered me money to
implement his or her personal wish in my free software, if I didn't like
the idea contained in that wish. I'm lucky that I have no commercial
software into which I _must_ add functionality requested by customers,
only because they give me money to do so and I make a living off them.
(And, before you'd ask, I _am_ a software developer. :-) ) I assume
Japheth feels similarly about his software. This is a different kind of
"software scope". Bye,
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.85a release
Hi guys, shell=c:\freedos\bin\command.com c:\freedos\bin /e:1024 /p=c:\autoexec.bat /nls:c:\freedos\nls\command.es your approach has has a deep disadvantage for programs like Norton/Volkow/Midnight Commander, make utilities, etc. that shell out to a new instance of command.com. they will start a new instance of %COMSPEC% with IMO no way of giving it any arguments, so you would run the english version instead of the localized one. I always thought that these settings, unless overriden from the command line that launches COMMAND.COM, are inherited from the parent COMMAND.COM or the root (that is, SHELL= in CONFIG.SYS). Apparently, that's not true. But then all other settings go back to the default, too; e.g. the environment size, although that's not as obvious as the language of DOS messages. Joe ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Additional notes on Games
Hi guys, there is absolutely no need to waste memory for everybody just because someone might try GNUCHESS. Why doesn't a program, that uses ansi.sys (or an equivalent), check for its presence?! :-) I found INT 2Fh, AX=1A00h for this purpose. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.3 packages
Hi guys, * NOT both DOSLFN and LFNDOS (which of them was better?) LFNDOS is written in C (larger executable!) and was abandoned in 1999/2000. DOSLFN is in assembler; its latest release is from 2012; it supports multiple code pages. I would recommend DOSLFN. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Inexplicable ambiguous name flags error from TurboC
Hi guys,
You have to change line 160 like this:
SET_WORD(H_FLAGS, z_header.(z_header_t)flags);
or
SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags);
How did this work? I used
SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags);
and I got this:
Error src\common\fastmem.c 160: Invalid combination of opcode and
operands in function restart_head
That's another error message related to assembly code. This line converts
to:
asm {
les bx,zmp
add bx,16
mov ax,z_header+16 // error
xchg al,ah
mov es:[bx],ax
}
and you get the same error message for the third instruction. In the
assembly code (compile with -S option), the "z_header" symbol is defined
as a word-typed label followed by lots of bytes, so probably the
"z_header+16" expression is taken for either byte-typed or untyped.
Therefore, you have to force the type:
mov ax,word ptr z_header+16 // no error
In the SET_WORD etc. macros, prepend "word ptr" wherever needed. Good
luck,
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Inexplicable ambiguous name flags error from TurboC
Hi David, Error src\common\fastmem.c 160: Ambiguous member name 'flags' in function restart_header I could reproduce this with Turbo C 3.00 running in DOSBox. It's not a compiler bug. If you read the help page of the error message, it applies to _assembly_code_, in the body of the SET_WORD macro. If multiple structs have a member with the same name, you have to qualify the member name with the struct name - but only in assembly code. Assemblers don't know much about types. They cannot deduce from the expression "z_header.flags" that to the right of the dot is the "flags" member specifically of the type of the "z_header" variable (on the left), "z_header_t", they rather translate this to a general expression like "address(z_header) + member_offset(flags)" for which the member's offset must be unambigious. You can narrow down the problem by inserting this line just below line 160: asm mov ax, z_header.flags; and you'll get the same error for this line, too. Actually, I think, the help page is wrong about the qualification syntax. You have to change line 160 like this: SET_WORD(H_FLAGS, z_header.(z_header_t)flags); or SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags); That is, there is no dot between the type qualifier and the member name. Have fun, Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel.asm question
Hi guys, mov dx,init_end+15 mov cl,4 shr dx,cl sub ax,dx why is 15 added to the end of the address of the symbol init_end if you just shift the value right by 4, doesn't that just undo the addition? This is a common trick: it rounds up the result of an integer division. See these examples for division by 10: Rounding down: X / Y 0 / 10 = 0 1 / 10 = 0 [...] 9 / 10 = 0 10 / 10 = 1 [...] Rounding half up: (X + Y / 2) / 2 0 / 10 -> (0 + 5) / 10 = 0 1 / 10 ~= 0 [...] 4 / 10 ~= 0 5 / 10 ~= 1 [...] 9 / 10 ~= 1 10 / 10 = 1 [...] Rounding up: (X + (Y - 1)) / Y 0 / 10 -> (0 + 9) / 10 = 0 1 / 10 -> (1 + 9) / 10 = 1 [...] 9 / 10 ~= 1 10 / 10 = 1 [...] In the code above, you calculate the number of paragraphs - an integer multiple of 16 bytes - from the number of bytes. The number of bytes is the offset of label "init_end" plus 15. The plus 15 is the "+ (Y - 1)" part in the rounding up example above. Rounding up makes sure that the number of paragraphs includes all paragraphs, even if the last one is partial: it contains only 1-15 bytes, not the full 16; that is, dividing the offset of label "init_end" by 16 gives you a non-zero remainder (the remainder is the length of the partial last paragraph). Paragraphs are a feature of the segmented memory model of x86 CPU's. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.3 list of packages
Hi guys, doslfn ... not sure if it's free/libre, but it's widely used. Of course, there are other alternatives, too, of varying quality (e.g. StarLFN). There's no able alternative for DOSLFN. (StarLFN isn't one as it doesn't actually support VFAT, only storing long filenames in a file per directory, a la UMSDOS.) Honestly, I think we can't afford to omit DOSLFN from the distribution. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Compiling with gcc
Hi Andreas, By the way, can anybody tell me, how to access environment variables, when the compiler doesn't support it? (no getenv() and environ=NULL) Use INT 21h, AH=62h to get the PSP segment and then see the word at offset 002Ch for the segment of environment variables. (See Table 01378 in the Ralf Brown Interrupt List for the PSP structure). Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] What is FreeDOS 2.0?
Hi guys, How about some of our md5 and sha... sum implementations? I'm working on pdsum, something that started as an expansion of pdSFV (http://rescene.wikidot.com/pdsfv ) but I completely rewrote it since. It compiles with Borland C++ 3.1 to 37 kbytes (without UPX) but it supports flavors of CRC-16/32/64 as well as MD5, SHA1, SHA256, SHA512 (! :-) ), BLAKE2S and BLAKEB. It compiles for 8086 or 386; it also compiles with Watcom C, DJGPP, MinGW and MinGW64. Would you be interested? I need volunteers for testing... * arclds (6 kb) Is that like "file" but only for zip and other archives? (I'm _very_ proud that it got mentioned at all!) It's not for identifying file formats, it rather lists the _contents_ of archives. I've been developing it since - but not released it yet -, with the new name "arclist", now compiling to 10 kbytes (without UPX) but with support for 64-bit file sizes (ZIP64). And a 8086 version and a multi-platform C version, too. At this very moment, I'm hacking TASM-style features into NASM so that I can compile arclist with NASM instead of TASM. I would be honored to donate both to FreeDOS, with public domain license. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Linux commands in DOS - Minibox
Hi guys, I've been writing my own set of UNIX tools for DOS for personal use. Same here, only for Windows. :-) (Designed with portability in mind.) Would anyone like me to publish these here in their own thread? Yes, please. I realized long ago that the DOS batch syntax is so poor that you can't do anything serious with batch files. But I knew Unix well enough to also realize that inventing my own batch language would fire back if I wanted to make my stuff multi-platform. Thus standard Unix and Unix-syle (but custom) pipe stages are the best solution: batch files will not become 100% shell scripts but, at least, as similar as possible. If so, are there any other commands that would be nice to add to them? I missed a few things from "tr" and it was relatively simple to implement. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Incompatibility issue due to FreeCom Dir command's output layout and Dosbox kernel limitations
Hi guys,
There is an incompatibility issue with the "File Selection" dialogs of
one of our legacy engineering MS-DOS programs. We don't have the source
code of the program but I know it was written in Borland Turbo-Basic a
long time ago. For years I thought it was a flaw in the FreeDOS
compatibility. In fact I found recently this is because the output of
the "dir" command is dumped in a temporary text file and parsed by the
program in a fragile way. I discovered three requirements for this
program to work. The display of the "dir" command must be formatted in
a way that :
1 - The file dates must be printed with a 2 digits year representation
2 - The file times must be printed without the AM/PM flag (24 hours
representation)
3 - The thousands delimiter of the file sizes must be a blank space (" ") instead of a
comma (",")
Honestly, I wouldn't bother with trying to disassemble, decompile,
recompile, whatever any of the programs involved because I wouldn't have
the necessary tools and settings to reproduce the same programs, only
with these small changes and nothing else. I would rather hack the
binaries.
In this case, your DOS program could be changed in a few places so that
its fixed but FreeDOS-incompatible requirements become fixed
FreeDOS-compatible ones. Without having seen your program, I would say
that changing requirement:
- #3 is easy;
- #1 is a bit complicated;
- #2 may not be possible.
In the last case, I would hack the FreeDOS command.com also/instead.
These changes would break compatibility between your program and other
DOS'es as well as the compatibility of FreeDOS with other programs so
they would be only for this very specific setup. You should get a
replacement for your program as soon as possible, though. :-)
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Why unzip now requires a 386?
Hi guys, BTW, Unzip hasn't had a proper release since 2009 (AFAIK). No, it hasn't. I was halfway implying that FreeDOS wasn't necessarily incompetent here, that it just hasn't changed much upstream since then. Hence there's really nothing "new" to ship. I know, there really is nothing we can do about it, I just confirmed the "AFAIK". If I may advertize myself, you can download my compilations But your binaries report the same 6.0 (2009) version. Is there a practical difference? Are there additional bugfixes? Or did you just want smaller size? There is supposed to be no difference _at_all_ because I compiled them from the original source. The point was that when I compiled them there was no official binary package for DOS yet (and no DJGPP 2.05 either). :-) Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] odd FreeDOS batch %1 %2 %3 behavior (differs from MS-DOS, too)
Hi guys, I don't have any solution to the problem but while on the topic of FreeCOM and batch file parameters, I have discovered an issue which I believe is a genuine bug. Create a batch file, for example: ECHO %1 %2 %3 %4 %5 %6 %7 %8 %9 Then run it with a parameter like "http://www.example.com/;. It will print http: //www.example.com / while MS-DOS and Windows will print it unmodified. I can confirm this but I think it's _not_a_bug_, rather intentionally different behavior. (I know, this also means compatibility problems.) Apparently, COMMAND.COM cuts apart switches in the command line into stand-alone arguments. Your example is considered as: 1. a command "http:"; 2. a switch "//www.example.com", with double switch characters; 3. a switch "/", an empty switch. You can prove this by adding "switchar=$" (only one "c"!) to [fd]config.sys which changes the system-wide switch character to "$". Now your example will be printed as "http://www.example.com/; but "http:$$www.example.com$" will be similary cut into pieces as "http: $$www.example.com $". Always enclose "suspicious" command line arguments into quotation marks so that they won't be reinterpreted in unexpected ways and that's not even DOS- or COMMAND.COM-specific. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] The block device driver interface
Hi guys, A normal DOS app can only access the first 4 GB of a file, or at least it can not seek beyond that, nor can it know about file sizes being beyond that. This came to my mind, too! Where is INT 21h, AX=7142h, the LFN/extended/DOS7+ equivalent of seeking in a file? It could be extended from a 32-bit value to a 64-bit value just like INT 13h, AH=02h was extended to AH=42h for reading disk sectors. If you extend DOS and / or drivers to support large files, still only software specifically made to use your extended file access interfaces will be able to use large files! You have to do everything on your own under DOS anyway. ;-) Also, the network redirector API does not support LFN, but I remember that CDEX plus LFN drivers together did provide some support for LFN on DVD and CD filesystems. Newer versions of DOSLFN support long filenames with newer versions of SHSUCDX (but not MSCDEX anymore) if A) SHSUCDX is already loaded or B) the "c+" option is specified on the command line so it can't be that complicated. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI 1.2
Hi guys, Having resident data will reduce issues with needing SET /P which has limitations (e.g. using pipes, which in most DOS command.com variants need temp files on a writeable drive) and is not in the classic MS DOS version of command.com (in case somebody tries to use your batch files to upgrade an existing MS DOS install). Of course I do not know if ALL instances of SET /P can be avoided this way, but it would be interesting to hear more about this :-) I'm not sure what you mean. The batch syntax "[...] | set /p VAR[...]" will _always_ create a temporary file (under DOS), as you wrote. Or do you think that V8Tools' resident part could preprocess command lines (including lines inside batch files) and replace " | set /p VAR[...]" parts - starting from the pipe character, not the "set" command! - with something else that reroutes command.com to itself (the part responsible for "set /p")? Maybe, preprocess batch files to turn " | set /p" parts into a special command (without a pipe), and _patch_a_hook_directly_ into command.com's (version/release specific, checks needed) command tokenizer/executor to be able to recognize these special commands before command.com tries to. Nasty, :-) and I'm not sure if it's worth the trouble. Under Windows (XP), where I'm using GnuWin32 (http://gnuwin32.sourceforge.net ) heavily but have not yet started using a Unix shell (stupid me?), this "set /p" command would've been extremely useful _if_ it could also be used as the end of a pipe. (I just checked: it doesn't work under Windows 7 either.) So I'm using a program called "xset" of my own (as usual, not releaed yet <:-) ) that does what "set /p" is supposed to do (and some more), reaching up into its parent process and injecting values into the parent process' (usually: cmd.exe executing it) environment variable block. Pipes are not as primitive under Windows as under DOS, though. PS: Regarding the block driver discussion, I *guess* that exFAT is too different from FAT. So a block driver to make it look like FAT to a DOS kernel would have to trick a lot. Better use CDEX/net API. Yes, that's what I realized, too. Especially if continuing to other file systems, those will be more and more different from FAT(12/16/32), even in basic concepts. The limit is there, useful discussion can only be about _where_ it is. What? Behind exFAT? It _is_ exFAT. ;-) Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI 1.2
Hi guys, set /p is a Windows NT feature of CMD.EXE. It was not available in MS-DOS or Windows 9x. And even in Windows XP, it doesn't support capturing the output of a command. A small test batch: --- test.bat --- @echo off set X= echo Y | set /p X= echo %X% --- outputs: --- ECHO is off. --- It works only if the input comes actually from the user (standard input?): --- test.bat --- @echo off set X= set /p X=X? echo %X% --- outputs: --- X? <= enter "Y" here Y --- Regarding finding the master environment, in order for FreeDOS to maintain compatibility with MS-DOS and the all the abandoned DOS software out there, FreeDOS has to implement SysVars, commonly called the List of Lists. This list can?t change it?s structure because by doing so, many DOS applications won?t be able to run because a lot of them depend on this ?undocumented? (by Microsoft) structure. Yup, that would be very nice. I have a DOS program that can reassign drive letters: http://sta.c64.org/dlmanip.html which relies _heavily_ on these data strutures. I'm not sure if I managed to make it work under FreeDOS (new version is not released yet). Also, while executing config.sys (_not_ autoexec.bat yet), the (master) environment variable block is not pointed to anywhere. I've unable to finish another DOS program that would record the boot drive into an environment variable so that PATH can later be set in autoexec.bat to :\[...][;...] (where can be A: for floppy, C: for hard disk etc.) Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] XFTOOLS - exFAT access a la LTOOLS
Hi guys, It is probably better to use the source of VMSMOUNT as basis for TSR drivers for exFAT access :-) Thanks, I'll keep that in mind. I already downloaded it. However, my plan is to _first_ release and test the (then read/write) access as a _C_ program and when the algorithm is stable and bugfree (?!) then rewrite the whole thing, instruction by instruction, in DOS assembly. I already did the opposite once. (Fortunately, there's not much to do to translate between C and assembly. ;-) ) Honestly, I don't wish to debug an assembly program, seeing the debug facilities of any C environment. Regarding nasty integers above 32 bits: No worries, as long as we do not support GPT, we only support 2^32 sectors in MBR :-p Then why does INT 13h, AH = 42h (BIOS extended read disk) expect the LBA sector number in a 64-bit integer? Oh, I see: _this_ supports LBA48 (and further), while now the _MBR_ becomes a new constraint, with its 32-bit LBA sector numbers. Ehhh... I haven't looked into GPT yet but I don't think it should be _that_ complicated. Also, you can of course use 64 bit data types in DOS software. I know. :-) I wrote a DOS program in assembly that lists the contents of compressed archives: http://sta.c64.org/pcutils.html#arclds . (This is the one that I translated to C but it's not released yet.) It compiles for 386 and above and uses two 32-bit registers for 64-bit integers. But Borland C++ is too ancient for this, and we agreed on that drivers shouldn't require protected mode, which move us to... I agree that OpenWatcom would be nicer than Borland C++ here. I agree. I forgot to mention that, while I never tried OpenWatcom and only looked at DJGPP a few times, I plan to "port" (read: add lots of ifdef's :-) ) the program to both. (At this moment, the 16-bit DOS program and the 32-bit Windows program creates _identical_ output, including the lots of debug messages, for the directory tree of a virtual disk image with a few directories and hundreds of files. So, this really is possible. gcc's warnings, when all enabled, helped a lot with my integer size compatibility problems. Amazing!) Not sure if Pascal would be nice for TSR drivers: You can do it (see keyboard driver) but the extra effort is that you have to translate existing filesystem code which probably is in C. I wrote a complete Norton Commander clone with lots of extras: http://sta.c64.org/sc.html in Borland Pascal (OOP, heavily modified Turbo Vision) but that project started in 1994. Now I see: Pascal is child's play compared to C. (And I knew even back in 1994 that OOP sucks. ;-) ) Sorry to Pascal lovers. (And, yes, I've already started to port it to Free Pascal, with good results.) In any case: Do not panic. Actually, I don't think you could dissuade me from this anymore. ;-) Now I have a bit more work to do with my daily job but I'll continue development. I'll keep you informed. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] XFTOOLS - exFAT access a la LTOOLS
Hi guys, You really stirred me up with this exFAT discussion and Eric gave me a great idea with requesting LTOOLS. I connected the two, I delved into it and spent most of the last five days with implementing an exFAT file system processor. It is _very_ exciting! I have _not_ looked into any existing source, the software is written from scratch, according to the contents of a virtual disk image (created and filled with data under Windows 7 running in VirtualBox) and reverse engineering documentations at: - SANS Institute: Reverse Engineering the Microsoft exFAT File System http://www.sans.org/reading-room/whitepapers/forensics/reverse-engineering-microsoft-exfat-file-system-33274 - Paradigm Solutions: Extended FAT File System (1.4) https://paradigmsolutions.files.wordpress.com/2009/12/exfat-excerpt-1-4.pdf - NTFS.com: exFAT overview http://ntfs.com/exfat-overview.htm Currently it has the following limitations: - no physical disk access, only virtual disks (= files); - read only; - files can't be accessed yet, only the directory tree traversed; - cluster chains are not yet followed; - it's written in C (not assembly), too big; - there will probably be a couple of nasty tricks to handle integers larger than 32 bits in DOS (LBA48 support). Its nice features are: - it's written in C (not assembly) ;-) , should be portable; - disks, partitions, volumes, clusters are abstract, should be able to support other file systems; - I _really_ tried to follow C coding conventions; - I'm aware of DOS memory constraints and try not to rely on lots of megabytes of memory available; - it compiles under both Borland C++ (DOS, 16 bit) and MinGW/gcc (Windows, 32 bit), without errors or warnings (all gcc warnings enabled) - it outputs debug messages in _great_ detail; - it does an _insane_ amount of checks on the partition table, exFAT boot sector and exFAT directory structures, could also be used as (read-only) CheckDisk/fsck; - it supports (or is supposed to support at the end) all exFAT details except for TexFAT (transactions; switch DOS disk cache off instead! ;-) ) and ACL table (no documentation available). I also found a few errors in the documentations mentioned above. I plan to release it, with full source, as soon as it can read files, a piece of standalone software (DOS and Windows) in the style of LTOOLS: http://www2.hs-esslingen.de/~zimmerma/software/ltools.html . (If you'd like to help or are interested, E-mail me.) I'm not sure about licensing, as I was previously planning to donate _all_ my software into the public domain, but I've been seduced here to go for GPL instead. ;-) I've also been working on a Windows port of FATSort: http://fatsort.sourceforge.net . Actually, I've had it and been using every day for _years_, just haven't found time to apply all changes into the latest release. This software could also be extended to support exFAT. I just need more free time. (But who doesn't? :-) ) Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI 1.2 Questions?
Hi guys, Unlike MS-DOS proper, FreeDOS comes with custom configuration files to optimize for different things, I have my personal opinion on this, but I digress. Given that the user may have modified the configuration files and there is no easy way to merge the changes of a vanilla FreeDOS config to a custom end user config, I would suggest maintaining the users configuration files. I agree; I'd really hate such a situation. Replacing configuration files should be an installation option, like "reset to default/factory settings". I'm not sure whether this option should be enabled or disabled by default; rather disabled. Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP/IP stack by M Brutman is now closed source
Hi guys, I've been coding free (as in use for no costs) software since 1994, with 60 thousand lines of code. ;-) It's open source but not exactly free (as in you may modify, republish it etc.) software. Since about 2010, not only I have no time to develop it but it also became obsolete, and I'm thinking of donating it into the public domain because there's no point of _any_ restriction anymore. However, because it's obsolete, no one cares anyway. But now I'm creating my own - GNU-style, generalized - utilities for processing database exports for my job. They haven't been released yet but I already wrote into all of them: "released into the public domain". I consider it as a maturation of my general attitude. mTCP/IP - as I understand, never seen it :-) - is apparently _not_ obsolete so there's a reason for people to argue and push the author into making it (again) open source free software. From this point of view, Michael, you should be grateful about it: it implies that there's still use for it. ;-) Even if you would never release the new sources anymore. And you said you _would_ release them so this is just a misunderstanding. Either side, please, don't be mad about it! Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: CheckHDD for FreeDOS 1.2 Installer
Hi guys, Just FYI, there was an old except from an AMD x86 manual that showed how to do 64-bit arithmetic in 32-bit assembly. I quoted/inlined it here, if you're curious: http://board.flatassembler.net/topic.php?t=7852 Or just steal the LongMul and LongDiv routines from Turbo/Borland Pascal's System unit, that are 16-bit code implementing 32-bit arithmetic, and turn it into 32-bit code implementing 64-bit arithmetic. ;-) See the source in http://sta.c64.org/arclist.zip . Bye, Joe -- KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel.sys and fdos (dir)
Hi guys, I am curious what others here think about this :-) In the early 1990's, my mother's work place moved document editing from paper to PC's with MS-DOS. One day her colleague looked around drive C:, found some very old files and deleted all of them. Pretty logical, why would you need old documents?! However, those files were actually the MS-DOS files so the next time the PC wouldn't boot up. My mother found out that she had to copy the same files from the same place from another PC, via floppy, and the disemboweled PC started working again. Smart users and idiots will do whatever they want anyway so don't try to stop them, you'll eventually fail. ;-) Joe -- KOVÁCS Balázs alias Joe Forster/STA s...@c64.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] LFNDOS source available
Hi guys, According to http://www.freedos.org/software/?prog=lfndos , the source of LNFDOS is not available. That isn't true, :-) it's been released under GPL. With _great_ difficulties, I managed to find not only the source of the last official release, 1.06, but also that of the unreleased 1.07 alpha 2. You can find it at http://sta.c64.org/dosprg/lfndssrc.zip . Joe (author of Star LFN and maintainer of http://sta.c64.org/lfnemu.html ) -- KOVÁCS Balázs alias Joe Forster/STA s...@c64.org; http://sta.c64.org Don't E-mail spam, HTML or uncompressed files! More contacts on homepage-- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
