> So, do you want to accuse me of the "not-so-positive intention" to say
> that JWASM has indeed disadvantages?
No, this was "generally" spoken. I don't know your intentions.
> Of course _I_ think that NASM is better.
Yes, I know. And I think that the "more free"-advantage of Nasm, which you
Hi Adam,
> As Eric put it, NASM is considered more free than JWASM.
as you probably can see there are also rather "questionable" sentences to find
in this mailing-list. "Freedom", "Democracy", "Justice", "Fairness", ... are
commonly regarded as positive terms and because of this they are also f
> Yeah, but ask Japheth whether he wants to keep NoMySo compatibility at all
> or whether he would use NoMySo once and then develop his software for
> NASM. I beat the answer is no.
This is probably true. But please don't get me wrong: I love Nasm. It's just
that once you
> More importantly, it means a
> developer cannot download the source code, make changes to suit
> his/her needs, and SHARE those changes with others.
I did exactly this with JWasm. I also read the Sybase license. I found parts
of it unclear, apparently contradictory, may be even nonsense.
I'm
> workarounds in the drdosprojects forum to grab ML
> (MASM and LINK in one file)
ML is NOT MASM + LINK in one file, it's still just the assembler which calls
an external linker.
-
This SF.net email is sponsored by: Microso
>> JWasm is available, a Masm v6 compatible Assembler, Open Source:
>> http://www.japheth.de/JWasm.html
>
> Nice, how masm compatible is it?
> And how wasm compatible is it?
>
> What are the requirements, is a 386 without FPU enough...?
> Are a few megabytes of RAM enough? Other relevant details?
Hi,
JWasm is available, a Masm v6 compatible Assembler, Open Source:
http://www.japheth.de/JWasm.html
It's available in 2 zips, binary and source. The binary package contains both
a Win32 and DOS application.
I'm afraid it's not fdupdate compatible.
Please don't tell me that you prefer Nasm o
Андрей Влащенко wrote:
> Hello everybody! CuteMouse project is dead;
> I can develop new mouse driver for the FreeDOS project.
> This driver, named "FreeMouse", I started today.
> Please reply to me, I want that you help me writing correct
> autodetection of used mouse type, and handle the PS/2
Hello,
http://www.japheth.de/Download/debug107.zip
contains FreeDOS Debug v1.07, a bugfix release.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log eve
>> this is off-topic, but I was banned permanently and Udo is a true citizen of
>> Schilda.
>
> I don't live in Germany, so I don't think I understand this remark.
>
Schilda is a fictional town, but it is also an epitome. This link might give a
faint idea what Schilda stands for:
http://www.si
> much more important is the threat header which mentions that UDMA/UDVD
> handles S-ATA disks and DVD's :))
Yes, Jack has announced his drivers in this list but apparently forgot to
mention the SATA support.
What should be mentioned as well is that the SATA support for DVDs is not
tested yet b
> For some reason, Udo banned Japheth for a moment (??)
this is off-topic, but I was banned permanently and Udo is a true citizen of
Schilda.
> Lucho is great, in particular his "LZ 7.10 MS DOS" (ever
> heard of copyright?).
Probably no. Well, "software cannot be s
. Another thing
which is mentioned is FreeDOS low speed concerning HD access compared to other
DOSes, but this is no bug of course, and of low priority.
Please don't be irritated by the wordings which were choosen there. The FOOL
mentioned
> Same as with the kernel, could an OpenWatcom expert please give
> me a hint how to say "farmalloc" (or fmalloc?) in a tiny memory
> model compiled OpenWatcom app? This is all that would be needed
> to compile SYS 3.3 in OpenWatcom :-). The sources are in Bugzilla:
I'm not an OW expert, but _fmal
>> - on PS/2 or newer, int 15 with ah=86 cx:dx=ysec might be useful for
>> delays (usually 1024 Hz granularity, your 1000 ysec should be fine)
>> but you will have to check first if the delay works, for example
>> by checking the BIOS ID or by checking 40:[6c] before/after a call.
> I tried
Hello Tom,
> if you are *using* it to play (legacy) games, hear music, whatever,
> you are *using*, not *evaluating* it; so you have to pay $$,
> otherwise you are violating license terms
That's possibly a bit a too restrictive view, since you cannot "evaluate"
without "using". The license there
tom ehlert wrote:
> and a non-free xxDOS kernel is completely useless to me (and many
> others) anyway.
Why? Just because it is "not free" (which seems to be an "unreasonable reason"
:) ) or are there other reasons?
-
Take
Hello,
> That is a very interesting suggestion. Japheth writes that DOS
> should hook int 19 and remove its own handlers if int 19 is
> triggered. Int 19 is what a "FDAPM HOTBOOT" would call, too.
>
> We can definitely tell FreeDOS to do as MS DOS 7 does (remove
> int
For the record: I added the bug to OW's bugzilla
http://bugzilla.openwatcom.org/show_bug.cgi?id=685
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to sha
> BTW, Japhet, if you prepare (1) diff for OW source tree and (2)
> compiled executable(s)/data files, I will glad to prepare update.zip
> archive, which will contain all critical/noticeable updates after stable
> release. I hope, this way is easier and, probably, more productive, than
> tryin
> J> I'm asking because there is a KNOWN bug in OW 1.6 with DOS4G applications
> J> launching other applications. The enviroment of the launched application
> J> contains garbage, which makes it pretty impossible to use BINW\WMAKE for
> J> example.
>
> In which circumstances? Why this was not
Are the binaries unmodified?
I'm asking because there is a KNOWN bug in OW 1.6 with DOS4G applications
launching other applications. The enviroment of the launched application
contains garbage, which makes it pretty impossible to use BINW\WMAKE for
example.
---
>
> 320 bytes? Hard task, unless your code is ineffective :) or there is
> present some redundant functions.
>
> May you in short explain layout of your code? This should ease my
> findings.
the resident protected-mode code is in segment V86, the resident real-mode
code is in segment
>>> 1. On your site, program versions nowhere mentioned, only in "news"
>>> sometime.
> J> no, see http://gra3/Jemm386.html
> J> no, see http://www.japheth.de/Jemm386.html
>
> http://www.japheth.de/HX.html
> Find "2.1" -> not found
Yes, but you claimed program versions are *nowhere* mentioned, so
> Ok, I may discuss at public, if you wish.
I do not wish, but all your email addresses are "invalid" and you refused to
use the nice EDR-DOS forum.
> 1. On your site, program versions nowhere mentioned, only in "news"
> sometime.
no, see http://gra3/Jemm386.html
> 2. I see "Jemm386 ... b
> no, see http://gra3/Jemm386.html
no, see http://www.japheth.de/Jemm386.html
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT
This thread has been opened for Jemm386 issues and discussion.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topic
> http://www.japheth.de/Download/DEBUG99B.ZIP
there is no longer a v0.99 version available, it is now
http://www.japheth.de/Download/DEBUG101.ZIP
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net
>
> DRDOSPROJECTS? Strange place. Especially, I neither German speaking nor
> pay attention to DRDOS nor use forums at all.
I guess there are more russians than germans at this place. Prefered language
is english, however. It's not restricted to EDR-DOS. If you don't use forums
at all, the
>
> Ok, this bug is fixed. Where you expect discussion for DEBUG and JEMM?
> Private or here?
Paul Vojta maintains FD DEBUG.
Jemm386 is not a FD project.
So discussing these things in a FD mailing list surely would be regarded as
"pollution".
Since you don't have a "valid" email address,
> Aha... DEBUG creates "application" PSP, but forgets to close all file
> handles from it before exit?
this bug is fixed (now debug v99i).
-
Using Tomcat but need to do more? Need to support web services, security?
Get s
>
> Does NOT works with MS-command.com 7.1 in W98 DOS box.
I see the problem now. After DEBUG has terminated there are open files left in
the SFT, which might be an indication that a PSP has been created but not
closed.
>
> PS: Japheth, do you receive my letter about JEMM?
> - bug:
>> debug.com /?
> DEBUG version 0.99g. Debugger.
>> echo q>test.scr
>> debugtest
>> debugtest
> Error creating file
but works with ms-dos 7.1 and command.com
>
> - bug/incompatibility:
>> debug
>> a
>> int3
> ^ Error
>> int21
> ^ Error
agreed, but I regard this as minor because thi
r reg' understands the 80386 32bit registers (EAX, ...) if cpu is 80386+
- 'a' and 'd' know how to handle LOOPD, LOOPZD and LOOPNZD
- the new 'rx' command displays the 32bit registers if cpu is 80386+
http://www.japheth.de/Download/DEBUG99B.ZIP
Japheth
> For this reason it might be interesting to no longer support MS-DOS and to no
> longer use int25/int26 in FreeDOS utilities (like defrag).
Hmm, but the bugs in DEFRAG will most likely remain, regardless if you call
ints 0x25/0x26 or - let's assume - new API ints 0xFE/0xFF.
> Are you sure that it is not just slow? Because that is just the result of
> using it on huge disks.
I'm *not* sure, since I waited a restricted time period only :). What I can
tell is that 5 minutes apparently was "too short". But if this is the case,
tell me how long I have to wait: 1 hour,
I did a quick test with some FAT32 drives.
The "undefined problem" error has disappeared, but in almost all cases I get
no response at all after the drive has been selected and have to reboot. No
C:\DEFRAG.LOG has been written then.
For one drive I get an error response (IIRC it was "error get
>> and i do not get the point in an int21 handler in
>> emm386. because it already has an any-int handler!
>
> The way the V86 monitor now has to work is by intercepting all interrupts in
> protected mode.
> Then reissue the interrupt in V86 mode. when that interrupt comes back you
get an iret
>
> Yes, you first have to lock the drive. With the lock command.
>
> This is windows specific. Nothing defrag can do about that.
>
That's a bit weak. DEFRAG could
- refuse to run on MS-DOS 7 at all (or just for FAT32)
- display that the drive is not locked and exit
- lock/unlock the drive itse
Hi,
as a substitute for Florian I did a quick test with 1.2.1.:
what's good, my simple test case, defragmenting a FreeDOS image mounted with
SHSURDRV (size 16 MB) gives no longer the "undefined problem" error.
what's bad, a true FAT32 drive (44 GB) still displays that error.
The error message
> I will move it to openwatcom. This way it can be compiled for 386.
> This will probably double the speed, since everything is internally computed
> as 32bit.
Not if you will use the OW 16-bit compiler (WCC). Although it has a switch
"optimize for 386", the generated code will not use 32bit re
>
> Welp, anyone who has an 8088 or 8086, or 80186 or 80188, or 80286, can try
> test EXE's at ftp://ftp.devoresoftware.com/download/emm386 called
> HIMKIK86.EXE and EMMKIK86.EXE for --8086 compressed HIMEM and EMM386,
> respectively, and report their results. It should kick out a message for
> Nah, I'm still waiting for a good explanation of how using UMBPCI and
> EMM386 is a common, or a not very uncommon, or even a desirable configuration.
>
> But, to be honest, I don't care much. I'm done. I'm free. The slings and
...
> code to find edge conditions and posting cute comments
> Though, as noted by Michael, UMBPCI+EMM386 is far from common
> configuration, so this issue is minor and may be deleayed. :)
this config also doesn't install the A20 handler:
c:\himem.exe
c:\emm386.exe FRAME=E000 X=C800-DFFF
but of course you will argue now that this is also very uncommo
> May you give examples, when disabling A20 handling is need?
if a new bug is discovered in Emm386'a A20 handling :)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre
> Don't see exactly where this would happen in a supported configuration,
> since EMM386 requires HIMEM/XMS manager presence and handles UMB's
> internally. Nonstandard, unsupported configurations, well, can always plan
> for that later.
Don't know if the configuration I'm often using is nons
The host stack problem is solved. Fine :)
Not a severe problem (IMO it's more like a feature), but the A20 line
switching will only work if an UMB handler has been installed. There are some
constellation where this is not true, and then the A20 gate is unhandled by
Emm386.
There is also still
> I didn't know if you were still working on it or whether it was just an
> example patch. If an example, it wasn't worth your time (or mine, frankly)
> to go into further detail. If you're interested, the removal of the 16-bit
> stack check and adjustment for PM_Entry "appears" to expose cer
> If you mean "optional" in that there should an option added (post-1.0) to
> control A20 for potentially complex machinations (e.g. directly accessing
> DOS structures at a time where HMA is mapped out), then most should agree
> that an A20 handler inhibit option should be on the to-do list. I
Eric Auer wrote:
>> Also the call to INT67/3F was also commented out just temporarily
>> and reactivated later. It's a feature!!! :)
>
> As this means "you temporarily locked the real and virtual A20
> to on", and as you call it a "feature", I have two comments...
I called the current implementat
I also read this in RBIL and changed it temporarily to find the "/NOX2MAX32"
bug and somehow this version has found the way in the Emm386 being uploaded.
But even MS Himem clears BL if it returns AX=1, so there should be no need to
modify anything.
Also the call to INT67/3F was also commented o
Imre Leber wrote:
> http://hp.vector.co.jp/authors/VA013937/editdisk/index_e.html
>
Hi,
EditDisk is good, but I would prefer commandline tools ("mtools"?) which also
work in plain DOS. Do you know if there are such tools available and in a
somewhat "mature" state. I once found some, but they w
> And then there are numerous problems with the keys.
> For example if you start the turbo c debugger (tc) it has a nice feature where
> almost every key is repeated twice. So if you press delete, it will delete
> two chars
> instead of 1.
qemu's keyboard emulation is bad. Usually this isn't not
> Japhet, how did you traced the IF problem with QEMU ?
What do you mean with "how did you trace the IF problem"?
I run ctmouse under debugger control inside qemu of course. There was no magic.
-
Take Surveys. Earn Cash. Inf
> Since low-level changes were made to this version of EMM386, please keep an
> eye out for any problems and report them as soon as you can. While I don't
The IF bug fix may have disclosed some previously hidden bugs which are due to
a careless handling of flags. The following is an excerpt fr
> BUT: is it working? There was a lot of talk about LFN lately, but I did
> not find a final diagnostic, just that 1.0 will have it disabled...
Yes it works. That means, FreeCOM is aware that such a thing may exist.
- load doslfn.com
- set LFN=Y to make FreeCOM LFN aware
- now use LFN in FreeCOM
> could be DOSLFN included? I think that most people needs the driver!
That would be good, but generally I had to realize that all the LFN things are
"a bit" underdocumented in the distribution, someone not familiar with LFN
support in DOS will not know what to do to make it active.
---
> 1. Bug: wrong handling for clc/stc in some places (they ignored, because
>popf follows, thus caller receives "always success"):
>
> __O\_/_\_/O__
> @@loc2:
> [...]
> clc ; flag success
> @@l
> I can't duplicate the XMS memory block fragmentation with DOOM or anything
> else handy, so whatever's happening depends upon the gameplay or memory
> configuration or moon phase or any of the usual suspects.
The errer has been described in Bugzilla more accurately. Especially it is
mentioned
> This is bug.
Don't choose so rude words! Be more polite! Instead say: "This could be
improved possibly?"
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the ch
> environment. Even better would be a good explanation for why the problem
> only manifests itself with that specific environment and application.
I've looked into the Qemu BIOS code for int 15h, ah=C2. Usually the code found
in "real" BIOSes is programmed very "defensively", that is, if a piec
> Here's my initial problem with this idea: it works when you get step
> outside of the Qemu DOS sandbox. Plus it works (or worked) in Bochs, since
> I remember testing it under Linux a year or two ago when trying to figure
> out what the heck was going on with CTMOUSE and Qemu. And it only se
>
> QEMU has never liked CTMOUSE under FreeDOS, and possibly MS-DOS. I don't
> know why.
when I modify emm386.asm, proc v86_monitor, so that the IF in real-mode is
cleared for all interrupts routed to v86-mode, not just the IRQs, it works
with CTMOUSE in qemu.
There might be good reasons to
Some minor issues so far are:
- if I select one of the configs with EMM386 the machine seems to hang after
ctmouse is loaded (last command in autoexec.bat). If I remove that last
line, everything is fine. This problem may be specific to qemu, however.
- if I select the option to load FD wi
This is my experience so far:
First attempt
I tried to install on a pretty small partition (QEMU) where MS-DOS 5.0 was
already installed. The installation very soon stops due to insufficient
hard disk space (although nothing is told, you just see no more "progress"
on the screen). After that the
> btw: it looks to me as if japeth wrote a tiny program to produce the
> bug; it's always helpful for maintainers if they get this
> program/source/description how to reproduce,
> so the time to reproduce the bug (and thereby time
> spend on the problem) is significant reduced, and often motivation
> Strange. I was think, that "bugzilla", "private email" or "post in
> group" is only ways to transfer reports to author and have nothing with
> "distance between me and program".
Bugzilla is more complicated and you have to login - several - times. That
makes you think twice before you inde
> Do you think, that "distance" allows/mean more rude behavior?! :) :(
No, it means using Bugzilla for bug reports - if anything at all. :)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Te
> Be polite never late!
You're right. But to be safe I will maintain a tiny security distance between
me and everything FD-related in the future.
> PS: Last 5 days news.openwatcom.org misbehaves for me. Is it my troubles or
> it broken itself?
I've experienced the same troubles. It seems
> Total "all" or total "free"? If first, then this is bug.
RBIL is a bit unclear, but given that the FD-Himem competitors are correct it
is meant "total free".
> Be more polite! :)
It's too late. Mr. Devore already expressed his "bewilderment" concerning my
remark.
> I never seen si
> Thank you for a most reasoned and pleasant remark. It is a particularly
> enlightened remark to make in view of recent mail-list history. In any
> case, you have certainly modified my overall view of your attitude and
> willingness to act as a responsible party in reporting errors and
> com
Here is another "CORRECT, but not terribly GOOD" behaviour of FD-Himem (newest
version!):
1. the xms state after booting FD without EMM386:
XMS3+ largest free block (kB): 785088
XMS3+ highest address: 2FFF
> the largest (allocatable) block. In its defense, I believe that
> contiguous XMS blocks will be merged on allocation if there is insufficient
> memory contained in a single block, although I might be remembering that
> wrong. In other words, if my memory is correct, block merges are done on
>
There is a bug left in the FD-Himem.exe memory manager.
When a program that had allocated several XMS blocks doesn't release these
blocks in the order FD-Himem likes it, it will report a too small "largest
free block". Luckily the memory is not "permanently" lost, FD-Himem is able to
regenerat
After fixing the first error, I'm getting:
---
C:\FREEDOS\EMM386\SOURCE\EMM386>d:\alt\tc201\make
MAKE Version 2.0 Copyright (c) 1987, 1988 Borland International
Available memory 563902 bytes
d:\alt\tc201\tcc -G- -w -r -
> No issue; no nesting. Ergo, I'm not changing it. In reply, rather than
> quoting boring old pre-ISO C compiler options, please instead trace support
> back to the far more enriching Magna Carta. King John of England's
> viewpoint on how an unpaired '/*' inside of a comment block makes the
76 matches
Mail list logo
