Re: [Freedos-devel] Bug 0x5801/41

[jerome]

Has there been any follow up on this issue?



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

Re: [Freedos-devel] Bug 0x5801/41

[jerome]

Hi All,

I fixed some erroneous source code comments in the testing program. 

Since none of the binaries support command line options, I moved it’s 
configuration settings into a SETTINGS.INC file. 

This provides an easier way to change what size blocks, UMB link state, 
allocation strategy and total number of tests performed. 

There is no difference in the compiled binaries themselves to the previous 
version. 

It is just easier to modify the source test settings.

https://fd.lod.bz/redist/memory/umbtest.zip 


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

Re: [Freedos-devel] Bug 0x5801/41

[jerome]

> On Apr 7, 2023, at 12:23 PM, tom ehlert  wrote:
> 
> Hi,
> 
>> Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 
>> (5.83) or My Head.
> 
> it's in the Kernel - or in your head.

Yep, could be my interpretation of the documentation. 

> 
> to decide between these two alternatives it's always helpful to send your 
> actual sources - not
> an english description of what you had intended to do.
> and of course autoexec.bat/config.sys

I understand that. :-)

I was considering whipping up a demo program after finishing working on my 
current project. Possibly on a bootable floppy image. That would make 
understanding and finding the issue easier. 

In part, the previous post was to remind me to do that. And, remind me what was 
going on. But, it will only take a few minutes to create one. I’ll do it now.
.
.
.
Ok, that took longer than I wanted. But, it yielded some interesting results. 

You can download the sources and precompile test programs from my server at:
https://fd.lod.bz/redist/memory/umbtest.zip

There are 4 binaries built from the same source (conditional defines):

UMBNTEST.COM - Binary without read back verification.
UMBNTEST.SYS - Device driver without read back verification.
UMBVTEST.COM - Binary with read back verification.
UMBVTEST.SYS - Device driver with read back verification.
(plus a sample FDCONFIG.SYS)

Executing the COM files (with or without verification) performs as expected.

But with the device driver version, things get interesting.

When using the UMBVTEST.SYS (with read back verification), DOS says it 
successfully changes the UMB linked state. However, when reading back the new 
setting it returns 0x00. The driver then terminates and all is well. 

Using the UMBNTEST.SYS (no read back), once again DOS says it changed the UMB 
linked state. When read back, a error message is displayed. But, we continue 
anyway. No error changing the strategy. Allocation succeeds regardless of size 
tested or strategy. Sometimes returning a segment in the high memory area, 
sometimes low. The system will continue to boot. After both FDCONFIG.SYS and 
FDAUTO.BAT have been fully processed. The system crashes with a JEMM exception 
while trying to load FreeCOM. 

Loading the either test driver low exhibits the same behavior with one 
exception. When it allocates low memory, the segment address it returns is the 
code segment of the driver. Ouch.

Testing the test driver under MS-DOS 6.22:

When UMBNTEST.SYS is loaded high, DOS reports failure when attempting to set 
the linked state. Changing the allocation strategy is successful. All attempts 
to allocate memory fail with error 0x0008 and 0 free paragraphs. The system 
continues to boot and operates normally.

When UMBNTEST.SYS is loaded low, DOS reports failure when attempting to set the 
linked state. All test allocations succeed. However, regardless of the strategy 
are allocated in upper memory using 0x40, 0x41, 0x42. Some are allocated at the 
beginning or end of high memory based on only 3 bits of the strategy. The 
system continues to boot and operates normally.

The config under MS-DOS was very simple, basically just:
DOS=HIGH
DOS=UMB
DEVICE=C:\MSDOS\SETVER.EXE
DEVICE=C:\MSDOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\MSDOS\EMM386.EXE NOEMS RAM
DEVICE=C:\UMBNTEST.SYS

> and - well I understand that kernel version control is a complete
> mess - but Kernel 0.85a seems a bit unlikely given that
> https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to
> 0.42.

Sorry, was a long day and the cat kept jumping on me (great excuse for dumb 
mistakes). 

Don’t know how or why I wrote Kernel (0.85a). 

Should have been Kernel (2043), FreeCOM (0.85a)…. 

But obviously, FreeCOM would not have anything to do with the issue.

> 
> Tom

Jerome

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

Re: [Freedos-devel] Bug 0x5801/41

[Rugxulo]

Hi,

On Fri, Apr 7, 2023 at 11:46 AM tom ehlert  wrote:
>
> and - well I understand that kernel version control is a complete
> mess - but Kernel 0.85a seems a bit unlikely given that
> https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to
> 0.42.

* https://github.com/FDOS/kernel

... says this:

"FreeDOS kernel - current 0xFD version is 2.43 (2043)"

Try "ver /r" if in doubt.


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

Re: [Freedos-devel] Bug 0x5801/41

[tom ehlert]

Hi,

> Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 
> (5.83) or My Head.

it's in the Kernel - or in your head.

to decide between these two alternatives it's always helpful to send your 
actual sources - not
an english description of what you had intended to do.
and of course autoexec.bat/config.sys


and - well I understand that kernel version control is a complete
mess - but Kernel 0.85a seems a bit unlikely given that
https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to
0.42.



Tom




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

[Freedos-devel] Bug 0x5801/41

[jerome]

Hi All, 

First, nearly all the features I wanted for the initial release of LOGGER have 
been implemented. The only thing remaining is the advanced capture. That is not 
complicated and won’t take long. I just put it off until the end. Like I 
mentioned before, I am very time constrained at present. Hopefully, I should be 
able to squeeze out the initial release over the next day or so. It has some 
neat features. :-)

Anyhow...

I noticed what appears to be a memory management bug when allocating a upper 
memory block. I usually do not mess around with allocating memory in that 
region. So, correct me if I am wrong. 

After performing a call to DOS (INT 0x21) to set the memory strategy 
(AX=0x5801) to allocate a “best fit, high memory only” (BX=0x0041), a 
subsequent call to allocate memory (INT 0x21, AH=0x48) should either return a 
segment in upper memory or fail. 

When the requested allocation can be made in the high memory area, it does 
return successfully with the segment for the block allocated in that region.

However, if it cannot allocate memory in the high memory area, it allocates it 
in lower memory. 

Although strategy 0x41 was set, 0x81 was actually performed. Documentation 
seems to indicate it should not do that and should fail.

I did not investigate any further. It is easy enough to work around by simply 
verifying the segment of the memory block returned. 

But, still seems like a bug to me.

Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 (5.83) 
or My Head. 

:-)

Jerome

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

Re: [Freedos-devel] Bug or Not

[jerome]

Hello,

> On Mar 19, 2023, at 10:27 PM, Prime Seal  wrote:
> 
> Mr J Hall here is the links to the video of FreeDOS after configuration.
> The errors after configuring fdauto.bat file
> YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo 
> 
There a a couple problems with your additions. 

First, that is a lot of environment variables. 

As Willi suggested, you may want to increase you environment space. 

But, there is a more serious problem…

You have 11 variables with a minimum of 15 characters each. Which is over 150 
characters.  Which you then attempt to append into the PATH variable. This is 
not possible. Those variables are expanded before the set a new variable. This 
means toy are attempting to use a command line of well over the 125 character 
limitation in FreeCOM batch files. 

You need to go about this a different way. 

If you want easy access to all of those tools, here is what I suggest. 

1) return the FDAUTO.BAT back to its original state.
2) create a environment setting batch file under the C:\FREEDOS\LINKS\ 
directory to configure things for the different tools.
3) create an “unset” batch under that directory as well.

This would easily allow you to select or switch development environments.

Here is a quick example of files you could create under the links directory….


NODEVENV.BAT

@echo off

rem remove any development specific environment varaibles
set LUAC=
set WATC=
set FASM=
set BCC=
set DGP=
set DJGPP=
rem add more as needed to clean stuff up

rem Return the system path to it’s default setting.
if not “%DEFAULTPATH%” == “” set PATH=%DEFAULTPATH%
set DEFAULTPATH=%PATH%

FASM.BAT

@echo off

rem clear any existing development settings
call %DOSDIR%\LINKS\NODEVENV.BAT

set FASM=C:\DEVEL\FASM
set PATH=%FASM%;%PATH%
cd %FASM%
echo Switched to FASM development environment.


Then simply typing “FASM” will switch everything you need to work with FASM. 
Since, the C:\DEVEL\FASM directory would be first in the PATH setting, you do 
not need to worry about any file name collisions. For example, typing FASM 
again would now try to run the C:\DEVEL\FASM\FASM.EXE and not the FASM.BAT file.



> 
> Kind regards
> Seal Prime
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

Re: [Freedos-devel] Bug or Not

[Prime Seal]

The solution has worked.
Thanks Wilhelm Spiegl

On Mon, Mar 20, 2023 at 1:44 PM Wilhelm Spiegl 
wrote:

> Hi, I did not check the whole video, but there was a message: "Environment
> full?"
>
> Possible solution:
> edit fdconfig.sys, goto the last lines and search for: "/E:1024". Change
> 1024 to 2048 (maybe a little more higher).
>
> Did it help?
>
> Thx for response
>
> Willi
>
>
> *Sent:* Monday, March 20, 2023 at 3:27 AM
> *From:* "Prime Seal" 
> *To:* "Jim Hall" , Freedos-devel@lists.sourceforge.net
> *Subject:* [Freedos-devel] Bug or Not
> Mr J Hall here is the links to the video of FreeDOS after configuration.
> The errors after configuring fdauto.bat file
> YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo
>
> Kind regards
> Seal Prime
> ___ Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug or Not

[Wilhelm Spiegl]

Hi, I did not check the whole video, but there was a message: "Environment full?"

 

Possible solution:

edit fdconfig.sys, goto the last lines and search for: "/E:1024". Change 1024 to 2048 (maybe a little more higher).

 

Did it help?

 

Thx for response

 

Willi

 
 

Sent: Monday, March 20, 2023 at 3:27 AM
From: "Prime Seal" 
To: "Jim Hall" , Freedos-devel@lists.sourceforge.net
Subject: [Freedos-devel] Bug or Not



Mr J Hall here is the links to the video of FreeDOS after configuration.

The errors after configuring fdauto.bat file

YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo

 

Kind regards

Seal Prime

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




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

[Freedos-devel] Bug or Not

[Prime Seal]

Mr J Hall here is the links to the video of FreeDOS after configuration.
The errors after configuring fdauto.bat file
YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo

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

[Freedos-devel] Bug 157: HELP freezes if language is Spanish

[Jim Hall]

I haven't had time to experiment with this bug yet (I'll have more time
over the weekend). The person reports that HELP freezes under any language
other than English? Has anyone else seen this problem?

Based on the description, I think the problem can be reproduced by changing
the language setting, then running HELP.



-- Forwarded message --

I installed FreeDOS 1.2 RC1 on AQEMU (host OS: Ubuntu 16.10 amd64) in
French and after the installation if I type help the system freezes. I was
about to file a bug report about it, but then I saw this ticket and tested
installing FreeDOS 1.2 RC1 in Spanish. The error described in the first
post till occurs.

This looks like a serious bug.
--

* [bugs:#157]  "help" command
freezes the system when freedos in Spanish is installed (except using xmgr
xms memory dirver) in VirtualBox latest version*

*Status:* open
*Group:*
*Labels:* help command help freeze FreeDos 1.1 VirtualBox
*Created:* Fri Oct 07, 2016 12:46 PM UTC by Vinilux
*Last Updated:* Fri Nov 04, 2016 10:06 PM UTC
*Owner:* nobody

When installing FreeDos in spanish and using the "help" command it works
well in English, but in spanish installation, the system freezes when using
all memory drivers excep xmgr xms (the 3rd option when bootin).
When using the last option VirtualBox directly gives an error and the
instance of the machine closes.
--
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug in Freecom

[dos386]

> FreeCom allows this command: "COPY CON"

confirm

> After that I can write text which echoes after enter in next line and
> it can't be interrupted nor with CTRL-Z

worx for me ... can be interrupted with CTL-Z

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Bug in Freecom

[Ladislav Lacina]

FreeCom allows this command: "COPY CON"

After that I can write text which echoes after enter in next line and it 
can't be interrupted nor with CTRL-Z nor with any other key combination. The
only I can do is a restart with CTRL-ALT-DEL.




MSDOS does not suffer with this bug - it does not allow "COPY CON" but 
writes the error message that file cannot be copied in itself.




The FreeCOM version I tested is 0.84-pre2 XMS_swap [Aug 28 2006]
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] bug in mode

[Jim Michaels]

there is a bug in mode.com where it requires 2 lines to get into 132x50 text 
mode.
not everything supports that mode, but it's cool that you can have it.

for some reason, there is a bug in mode where it requires these 2 lines to get 
into 132x50 text mode
mode CON: COLS=132
mode CON: COLS=132 LINES=50




command.com's dir/w does not support it.

I use this in my install batch file.

 
-
Jim Michaels
jmich...@yahoo.com
j...@jimscomputerrepairandwebdesign.com
http://JimsComputerRepairandWebDesign.com
http://JesusnJim.com (my personal site, has software)
---
Computer memory measurements, SSD measurements, microsoft disk size 
measurements (note: they will say GB or MB or KB or TB when it is not!):
[KiB] [MiB] [GiB] [TiB]
[2^10B=1,024B=1KiB]
[2^20B=1,048,576B=1MiB]
[2^30B=1,073,741,824B=1GiB]
[2^40B=1,099,511,627,776B=1TiB]
hard disk industry disk size measurements:
[KB] [MB] [GB] [TB]
[10^3B=1,000B=1KB]
[10^6B=1,000,000B=1MB]
[10^9B=1,000,000,000B=1GB]
[10^12B=1,000,000,000,000B=1TB]--
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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in edit

[Travis Siegel]

On Jun 1, 2011, at 6:16 PM, Jim Michaels wrote:


0.7d is what I am using.  it seems to work much better when
- the files are fully extracted
- the files are not readonly (I was copying off of cd), especially  
the .cfg file I should think.


so it's my problem.

when copying files off of a cd, the readonly attribute is  
automatically set on the file.  If I were unzipping, this would not  
be a problem I should think.

so I have an issue with my OEM cd.
this has nothing to do with the freedos cd (unless you guys are  
doing the same thing).


This is perfectly normal.  The read-only bit gets set by the os  
everytime you copy something from a read-only media (how could it be  
any different) It's not the os's fault, it's the media.  It's read- 
only, so the files copied from it are the same way.  If you copy the  
zip file, then extract the zip, you won't have this problem, but if  
you copy the files directly from the cd, then this is the expected  
behavior.


p://p.sf.net/sfu/quest- 
sfdev2dev___

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


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in edit

[Jim Michaels]

0.7d is what I am using.  it seems to work much better when
- the files are fully extracted
- the files are not readonly (I was copying off of cd), especially the .cfg 
file I should think.

so it's my problem.

when copying files off of a cd, the readonly attribute is automatically set on 
the file.  If I were unzipping, this would not be a problem I should think.
so I have an issue with my OEM cd.
this has nothing to do with the freedos cd (unless you guys are doing the same 
thing).




From: Eric Auer e.a...@jpberlin.de
To: freedos-devel@lists.sourceforge.net
Sent: Tuesday, May 10, 2011 1:59 PM
Subject: Re: [Freedos-devel] bug in edit


Hi Jim,

 if you try to highlight text by holding down the left shift key and
 hitting the end key or using any of the arrow keys, the program will
 not let you do anything (like save or exit).  the only thing you can
 do is reset the computer.  it locks up.  kind of.  menus are still
 sort of operational, but they are not entirely active.

This does not seem to happen with EDIT 0.7d, so apparently
something went wrong in the event / message pumping in the
version of EDIT which you are using, e.g. in editbox.c as
far as the source is concerned, e.g. related to marking.

Please give some more details about which version of EDIT
you are using, which keyboard and keyboard driver, and if
using the mouse for menus still works when keys are stuck.

Regards, Eric



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in edit

[Eric Auer]

Hi Jim,

 if you try to highlight text by holding down the left shift key and
 hitting the end key or using any of the arrow keys, the program will
 not let you do anything (like save or exit).  the only thing you can
 do is reset the computer.  it locks up.  kind of.  menus are still
 sort of operational, but they are not entirely active.

This does not seem to happen with EDIT 0.7d, so apparently
something went wrong in the event / message pumping in the
version of EDIT which you are using, e.g. in editbox.c as
far as the source is concerned, e.g. related to marking.

Please give some more details about which version of EDIT
you are using, which keyboard and keyboard driver, and if
using the mouse for menus still works when keys are stuck.

Regards, Eric



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Eric Auer]

Hi, I noticed that int 21 with ah=1c might return wrong
values for invalid drive, can somebody check this? For
example: Is this a bug? When did we introduce it? What
do other DOSes do here...?

For invalid drives, I get: ds:bx=0:0 al=0 cx=400 dx=unchanged

I expect: al=ff, other values are not explained in RBIL

AL is sectors per cluster, CX is sector size, DX drive size
in clusters or -1 if above 64k, DS:BX points to media ID byte

Thanks for checking :-)

Eric


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Ladislav Lacina]

Well, I did some testing in FreeDOS, MSDOS 7.1, Windows98 and WindowsXP

This function works in all these environment different. F
1) For existing 3,5 floppy disks all give the same (correct) results only
MSDOS gives wrong Total number of Sectors and Sectors per Cluster
2) For existing hard disks all three give different value for Total Number
of Sectors (FD: 65525, MS: 65534, 98: 65526, XP: 15747 (bullshit))
3) Non existing drives: difference is in Sectors per Cluster: in FreeDOS:
all output seems to be undefined, in other OSes is all undefined except
Sectors per Custer which seems to be always 255 (FFh)
4) Other diferencies are in CD/DVD roms and flashdisks.

From the above is shown that MS-DOS and WinXP give undoubtebly wrong
results. The output for non existing drives seems to be random except AL,
which was in all tested OSes except FreeDOS FFh. RBIL mentions it so maybe
it could be fixed, however I think that programmers just shouldn't call this
function for non existing disks and I even think this function shouldn't be
called at all.


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Christian Masloch]

 1) For existing 3,5 floppy disks all give the same (correct) results only
 MSDOS gives wrong Total number of Sectors and Sectors per Cluster

This bug of MS-DOS 7.10 is also documented in RBIL 61.


BTW, I think the other registers should not be changed when al is set to  
FFh regardless of what MS-DOS does.

Christian

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Eric Auer]

Hi Laaca, thanks for checking!

 ... FreeDOS, MSDOS 7.1, Windows98 and WindowsXP ...
 existing 3,5 floppy disks all give the same (correct) results only
 MSDOS gives wrong Total number of Sectors and Sectors per Cluster

As this is MS Win9x DOS 7, the wrong number is expected...

 2) For existing hard disks all three give different value for
 Total Nr. of Sectors FD: 65525, MS: 65534, 98: 65526, XP: 15747

I assume you mean total number of clusters?

And I assume you measured on a FAT32 drive
which actually has more than 65536 clusters
which cannot be expressed as 16 bit number?

How many clusters does that drive have, for
example according to dosfsck -v X: or so?

 3) Non existing drives: difference is in Sectors per Cluster:
 in FreeDOS: all output seems to be undefined, in other OSes
 is all undefined except Sectors per Custer which seems to be
 always 255 (FFh)

As people might call this to find out whether a
drive exists, FreeDOS should return the sectors/
cluster as 255 as expected for invalid drives...

Trying with the FreeDOS 1.0 kernel 2036, I get:
AX, CX, DX, BP, SI, DI, ES, SS, SP unchanged
DS:BX 0:0, so I would not say undefined. The
experiment was to fill values like 1234 in all
the registers to see what you get back later.

The bugfix would make sure AL=255 is returned
for int 21.1c calls for an invalid drive, but
for CX and DX and DS:BX I am not sure whether
it is better to change or not to change them?
What do the other DOSes or DOSish OSes return?

 4) Other diferencies are in CD/DVD roms and flashdisks.

Yeah, what happens for CD/DVD is kind of random I guess...

Eric




--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [bug] mem.exe crashes on 8086

[Arkady V.Belousov]

Hi!

23-Авг-2006 17:16 [EMAIL PROTECTED] (Bernd Blaauw) wrote to
freedos-devel@lists.sourceforge.net:

 JvR MEM.EXE 1.9a2 seems to crash on a 8086.
  Where you get this version? CVS contains 1.6 (or is it 1.7? MEM_MINOR
 contains 7).
BB http://wiki.fdos.org/Main/Mem
BB points to:
BB http://www.fdos.org/ripcord/beta9sr1/other/misc/mem19a2.zip

 Thank you. I forget about this fork and think, that JvR talks about
Bart's version.

BB http://www.employees.org/~doshea/freedos/tmp/ contains:
BB http://www.employees.org/~doshea/freedos/tmp/mem19a3.zip

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [bug] mem.exe crashes on 8086

[Arkady V.Belousov]

Hi!

23-Авг-2006 07:57 [EMAIL PROTECTED] (Joris van Rantwijk) wrote to
freedos-devel@lists.sourceforge.net:

JvR MEM.EXE 1.9a2 seems to crash on a 8086.

 Where you get this version? CVS contains 1.6 (or is it 1.7? MEM_MINOR
contains 7).

JvR I believe the crash is caused by a bug in the 386-detection code
JvR inside MEM.EXE. The detection always gives false positive results
JvR on 8086 systems, leading MEM.EXE to execute a subroutine which
JvR contains 386-specific instructions.
JvR The 386-detection code basically tests whether it can set flag bits 12-14.
JvR On a 8086 however, bits 12-15 are always set. It may be possible to fix

 Yes, looks like you right: I check MEM 1.6 (1.7?) and found, that its
386 detection code is buggy, because tries to set 0x7000 in flags and
expects, that both bits will be set only in 386+ (whereas bits 12-15 always
set in 8086/80186; in 80286 bits 12-14 are IOPL and NT and always cleared in
real mode). Right code should be (excerpt from my MEMA):

/* try to change bits 12-15 (0xF000) in the FLAGS register...   */
I pushf; I pushf; I pop ax; _AH ^= 0xF0;
I push ax; I popf; I pushf; I pop bx; I popf;
/* ...then check whether any bit was changed */
count
type = 3; if (_AH ^ _BH) return type;
type = 2; if (_BH  0xF0) type = 0;
return type;

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [bug] mem.exe crashes on 8086

[Bernd Blaauw]

Arkady V.Belousov schreef:
 Hi!

 23-Авг-2006 07:57 [EMAIL PROTECTED] (Joris van Rantwijk) wrote to
 freedos-devel@lists.sourceforge.net:

 JvR MEM.EXE 1.9a2 seems to crash on a 8086.

  Where you get this version? CVS contains 1.6 (or is it 1.7? MEM_MINOR
 contains 7).
   
http://wiki.fdos.org/Main/Mem

points to:
http://www.fdos.org/ripcord/beta9sr1/other/misc/mem19a2.zip

http://www.employees.org/~doshea/freedos/tmp/ contains:
http://www.employees.org/~doshea/freedos/tmp/mem19a3.zip

-- 
Efficiency is intelligent lazyness



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [bug] mem.exe crashes on 8086

[Imre Leber]

Base list still shows: 

MEM 1.7 Bart Oldeman

Jim should decide wether to take the 1.9 from that other side. Was it ever 
contributed? Maybe the author should be contacted.

Imre

-Original Message-
From: Bernd Blaauw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 05:16 PM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] [bug] mem.exe crashes on 8086

Arkady V.Belousov schreef:
 Hi!

 23-Авг-2006 07:57 [EMAIL PROTECTED] (Joris van Rantwijk) wrote to
 freedos-devel@lists.sourceforge.net:

 JvR MEM.EXE 1.9a2 seems to crash on a 8086.

  Where you get this version? CVS contains 1.6 (or is it 1.7? MEM_MINOR
 contains 7).
   
http://wiki.fdos.org/Main/Mem

points to:
http://www.fdos.org/ripcord/beta9sr1/other/misc/mem19a2.zip

http://www.employees.org/~doshea/freedos/tmp/ contains:
http://www.employees.org/~doshea/freedos/tmp/mem19a3.zip

-- 
Efficiency is intelligent lazyness



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug in FreeCOM DIR command

[tom ehlert]

Hello kd4d,

 I believe I have found a bug in FreeCOM's implementation of the
 DIR command.  This causes a Divide by zero error and forces a
 reboot.

thanks for reporting and analyzing. code below (between  and ) works 
better.

tom


  rootname[0] = toupper(*path);
  segread(sr);
  sr.es = sr.ds;
  r.x.ax = 0x7303;
  r.x.dx = (unsigned)rootname;
  r.x.di = (unsigned)FAT32_Free_Space;
  r.x.cx = sizeof(FAT32_Free_Space);
  int86x(0x21, r, r,sr);
  
  if (!r.x.cflag  r.h.al != 0)
{
clustersize = FAT32_Free_Space.sectors_per_cluster * 
FAT32_Free_Space.bytes_per_sector;

if (clustersize)
  if (FAT32_Free_Space.free_clusters = 0x8000l / clustersize)
{

int shift;

for (shift = 21; --shift;)
{
if ((clustersize  1) == 0) clustersize = 1;
else
FAT32_Free_Space.free_clusters = 1;
}

convert(FAT32_Free_Space.free_clusters * clustersize, buffer);

strcat(buffer,  Mega);
goto output;
}
}  

 This renders NTFS4DOS difficult to use on many modern
 computers.

 Mark













 ---
 SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
 from IBM. Find simple to follow Roadmaps, straightforward articles,
 informative Webcasts and more! Get everything you need to get up to
 speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel


Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Bug in FreeCOM DIR command

[kd4d]

Good day, all:

I believe I have found a bug in FreeCOM's implementation of the
DIR command.  This causes a Divide by zero error and forces a
reboot.

Using the DIR command on an NTFS4DOS mounted NTFS partition
which should show

   0 File(s)  0 bytes
   7 Dir(s)  69,704,994,816 bytes free

causes the error.

This appears to be due to the following code in FreeCOM's
dir.c, function dir_print_free.  This from the CVS mirror download
http://www.fdos.org/kernel/freecom.HEAD.zip:

 rootname[0] = toupper(*path);
  r.r_ax = 0x7303;
  r.r_ds = FP_SEG(rootname);
  r.r_dx = FP_OFF(rootname);
  r.r_es = FP_SEG(FAT32_Free_Space);
  r.r_di = FP_OFF(FAT32_Free_Space);
  r.r_cx = sizeof(FAT32_Free_Space);
  intr(0x21, r);
  
  if(!(r.r_flags  1)) {
dprintf(([DIR: Using FAT32 info]\n));
clustersize = FAT32_Free_Space.sectors_per_cluster
 * FAT32_Free_Space.bytes_per_sector;

if(FAT32_Free_Space.free_clusters = 0x800l / clustersize) {
convert(FAT32_Free_Space.free_clusters / 
  ((1024l*1024) / clustersize), buffer);
strcat(buffer,  Mega);
goto output;
}
  }  

Specifically, the disk is reporting 64 sectors per cluster and
32768 bytes per sector.  This makes ((1024l*1024)/clustersize)
evaluate to 0!  This appears to be a relatively new change to
DIR.

I have duplicated this using a test program ported to 
open Watcom on this same disk.  That's the way I got the 
results of the intr(0x21, r) call.  The same error does not
occur using MSDOS.  It reports a disk size of  free bytes
(yes, a blank).

This renders NTFS4DOS difficult to use on many modern
computers.

Mark













---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

21--2004 23:20 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:

 A I remember one for instance: it was possible with a MDA to have 704k
 A lower memory. Not interesting anymore, after the advent of VGA.
  Why? Expanding base memory over VGA graphics segment is a nice feature.
A I cannot figure many situations where VGA without Graphics can be
A usefull. Let me say it otherwize: the only programs that I know of, that
A need more LowMemory are graphics ones...

 DBMS like Clarion, for example.




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Aitor Santamaría Merino]

Hi,
One more opinion on this topic. I don't think it's a good idea that the 
UMBs are chained into the main MCB chain.
UMBs are different from other memory blocks. For instance, if you are 
using EMM386 to provide UMBs, you may get troubles with DMA because of 
the mismatch of linear and physical addresses. This is the sort of 
reasons why most of the programs provide /NOHI switches and such to 
avoid being loaded high.
Thus, we might get into troubles if the UMBs are inserted into the main 
MCB chain, as it might be that current DOS algorythms allocate some 
memory unavoidably high.

Aitor
Alain escribió:

tom ehlert escreveu:
if the a000 block is ever merged into the lower memory area,
interesting things might happen.

I remember one for instance: it was possible with a MDA to have 704k 
lower memory. Not interesting anymore, after the advent of VGA.

So, my vote is that any workaround is as good as a fix for something 
that will never get used ;-)

Alain

---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - digital 
self defense, top technical experts, no vendor pitches, unmatched 
networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

RE: Re: [Freedos-devel] bug in UMB support

[aitor . sm]

(before someone, e.g. Eric complains, mind that I was forced to use webmail in this 
message, so I have no control over the format of the message)



- Mensaje Original -

Remitente: Arkady V.Belousov [EMAIL PROTECTED]

Destinatario: [EMAIL PROTECTED]

Fecha: Martes, Junio 22, 2004 11:41am

Asunto: Re: [Freedos-devel] bug in UMB support



ASM UMBs are different from other memory blocks. For instance, if 

you are

ASM using EMM386 to provide UMBs, you may get troubles with DMA 

because of

ASM the mismatch of linear and physical addresses.

FD currently compares buffer address (in dsk.c and blockio.c) with

explicit A000 when decising to use internal buffer for disk IO, so no

problems.



I didn't mean just the kernel, but the possible TSRs that might be loaded high and 
make use of DMAs or such things just because they chose to load in the uppermost 
position in the MCB chain.



Aitor


---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

22--2004 13:00 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
[EMAIL PROTECTED]:

ASM using EMM386 to provide UMBs, you may get troubles with DMA because of
ASM the mismatch of linear and physical addresses.
FD currently compares buffer address (in dsk.c and blockio.c) with
explicit A000 when decising to use internal buffer for disk IO, so no
problems.
ase I didn't mean just the kernel, but the possible TSRs that might be loaded
ase high and make use of DMAs or such things just because they chose to load in
ase the uppermost position in the MCB chain.

 Ha! First, I don't know such (useful) programs, which use DMA and load
itself into uppermost position (LAST_FIT). Second, _if_ you use such
program, just don't pass A000 segment for EMM386, say something like I=A001.




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

RE: Re: [Freedos-devel] bug in UMB support

[aitor . sm]

Hi!
22-éÀÎ-2004 13:00 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
[EMAIL PROTECTED]:
ASM using EMM386 to provide UMBs, you may get troubles with DMA 
because of
ASM the mismatch of linear and physical addresses.
FD currently compares buffer address (in dsk.c and blockio.c) 
withexplicit A000 when decising to use internal buffer for disk 
IO, so no
problems.
ase I didn't mean just the kernel, but the possible TSRs that might 
be loaded
ase high and make use of DMAs or such things just because they 
chose to load in
ase the uppermost position in the MCB chain.
Ha! First, I don't know such (useful) programs, which use DMA 
and load
itself into uppermost position (LAST_FIT).


Well, LBACACHE could eventually be a good candidate.


 Second, _if_ you use such
program, just don't pass A000 segment for EMM386, say something like 
I=A001.


True, but do you have to do the same with MS-DOS? What about MS-DOS compatibility?
Someone would complain that it isn't necessary to do that in MS-DOS.


Aitor


---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

22--2004 14:40 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
[EMAIL PROTECTED]:

Ha! First, I don't know such (useful) programs, which use DMA and load
itself into uppermost position (LAST_FIT).
ase Well, LBACACHE could eventually be a good candidate.

 Do you mean, that LBACACHE copies itself to (or allocates memory at)
end of MCB chain?! Bad behavior, it this is so. :( Anyway, reread my words
below:

 Second, _if_ you use such
program, just don't pass A000 segment for EMM386, say something like I=A001.
ase True, but do you have to do the same with MS-DOS? What about MS-DOS
ase compatibility?

 (Q/MS)EMM386 joins A000 segment to base memory notwithstanding running
OS (and _now_, with my patch, FreeDOS not hangs, but gets same expanded base
memory). Which other compatability do you mean?

ase Someone would complain that it isn't necessary to do that in MS-DOS.

 ? _Now_ behavior of FD is same as with MS-DOS (ie. it not hangs when
base memory size is more than 640k after loading some driver).

PS: My host OS is a MS-DOS and I permanently compare FreeDOS behavior with
MS-DOS whereas possible. For example, now FD menus look more like MS-DOS.




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Paul Berger]

On Mon, 2004-06-21 at 16:37, Alain wrote:
 tom ehlert escreveu:
 
  
  if the a000 block is ever merged into the lower memory area,
  interesting things might happen.
 
 I remember one for instance: it was possible with a MDA to have 704k 
 lower memory. Not interesting anymore, after the advent of VGA.
 
 So, my vote is that any workaround is as good as a fix for something 
 that will never get used ;-)

Well we use this on our dedicated MS-DOS based POWERLan server so that
we could have more active shares  uses.  Not not something that is used
commonly, but with 200 PCs using a P166 with SCSI drive in the mid 90s
it kept us from needing to upgrade to a real network operating system.

Not a totally unused feature, though we don't need to use it anymore
since we upgraded to Netware in '99 for the office and so have about
half the system talking POWERLan.

Regards.
Paul




---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

21--2004 12:31 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov
[EMAIL PROTECTED]:

 for example, as I understand, latest FD-EMM386 translates starting I= area
 address A000 to A001 because there is bug in (current) FD. Isn't it?
te right. ALL fd-emm386's translate a000 into a001;

 May be, all, but emm386x8.zip doesn't work for me.

te so it will never be merged into the lower memory block.

1. You lost one more paragraph (at A000).
2. You lost possibility to expand base memory (over 640k).

BTW, merging is performed by EMM386 driver - FD itself (yet?) doesn't joins
UMB to base memory. I not tested, how behaves MS-DOS - I not have EMM386,
which not joins A000 to base memory itself or not translates A000 to A001.

te if the a000 block is ever merged into the lower memory area,
te interesting things might happen.

 Sure, this works and very convenient. When me was not enough memory for
running Clarion programs, I increase available memory by reusing A000
segment for this.




---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Alain]

tom ehlert escreveu:
if the a000 block is ever merged into the lower memory area,
interesting things might happen.
I remember one for instance: it was possible with a MDA to have 704k 
lower memory. Not interesting anymore, after the advent of VGA.

So, my vote is that any workaround is as good as a fix for something 
that will never get used ;-)

Alain

---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Alain]

Arkady V.Belousov escreveu:
Hi!
21--2004 18:37 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:

if the a000 block is ever merged into the lower memory area,
interesting things might happen.
A I remember one for instance: it was possible with a MDA to have 704k
A lower memory. Not interesting anymore, after the advent of VGA.
 Why? Expanding base memory over VGA graphics segment is a nice feature.
I cannot figure many situations where VGA without Graphics can be 
usefull. Let me say it otherwize: the only programs that I know of, that 
need more LowMemory are graphics ones...

Alain
---
This SF.Net email sponsored by Black Hat Briefings  Training.
Attend Black Hat Briefings  Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

20--2004 00:16 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:

MD Unfortunately, there's been a death in the family,

 My condolences to you.

MD so all the planned tasks
MD listed above will be pushed back another week or so.

 Ok.




---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] bug with segment A000 as UMB fixed!

[Arkady V.Belousov]

Hi!

 Wow, I fix the bug with destroyed MCB chain, if (Q/MS)EMM386 joins
segment A000 to base memory. Result:

SegmentSize   Owner   Type / source
---   -   -   -
  1.00k   INT vectors table
 0040  256BIOS data area
 0050  512DOS data area
 0070 8.06k   system
 0274 55.8k   systemdata area
  -0282208FILES=
  -0E77   47.8k XMS0  DEVICE=HIMEM
  -0F3A   3.04k EMM0  DEVICE=EMM386
  -0F59496FILES=
  -0FE9   2.25k   LASTDRIVE=
  -106A   2.01k   STACKS=
 106A  112--free--
 1071 2.87k   COMMAND
 1129  667k   --free--
---
 B7FF 69.1k   system
 C94A 90.5k   --free--
 DFEF  272COMMAND environment
-E000-

 Memory typeTotal  -   Used   =  Free (largest)
   ---      ---
Conventional 736k  68.5k  667k (  667k)
 Upper (DOS)90.8k   272  90.5k ( 90.5k)

PS: Strange, but with MS-EMM386 (from MS-DOS 6.22) MS-HIMEM (from Win98)
uses 47k instead 2k (doesn't loads itself into HMA)? With FD-EMM386 it
smaller (as this shown in previous letter).

PPS: Unfortunately, this fix touches more than one source file: main.c,
initoem.c, config.c and init-mod.h.




---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

20--2004 14:28 [EMAIL PROTECTED] (tom ehlert) wrote to Michael Devore
[EMAIL PROTECTED]:

 I hope to have some free time later this weekend and will try to get caught
 up on a few FreeDOS items, including your requested test, a stand-alone UMB
 stress test,
te whatever arkady suggests - IMO its nonsense.
te I coded the original implementation for 2 good reasons as it was:
te a) to save my time
te b) to save code space.
te allocating/deallocating/resizing UMB's is plain nonsense in the 21'th
te century; UMB's are supposed to be used by DOS=UMB; that's it.

 ?! Who says about allocating/deallocating/resizing?! _I_ say that
2035 contains bugs, related to allocating UMB and making MCBs chain.

 One bug I prove and fix (I mean, join of A000 segment to base memory by
(Q/MS)EMM386 driver), other bugs I suspect and wish to prove (that I already
fix them also) - for example, as I understand, latest FD-EMM386 translates
starting I= area address A000 to A001 because there is bug in (current) FD.
Isn't it?

te please use your spare time for more sensible tasks instead of
te satisifying this russian mathemagician ;)





---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

17--2004 22:40 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:

MD I hope to have some free time later this weekend and will try to get caught
MD up on a few FreeDOS items, including your requested test, a stand-alone UMB
MD stress test, and code up an XMS block auto-grabber/releaser for Erwin
MD Veermans'  NWDSK if it proves feasible and fixes the immediate problem with
MD NIOS load limitations.

 Ok.

MD However, EMM386 may not necessary return a next higher block address
MD depending on the size and order of what has already loaded in UMBs.  It can
MD split large blocks and/or alloc a free block with a lower address than a
MD previously allocated one.

 Of course, I know. Moreover, it should do it: for example, B000-B800
32k segment is shorter than segment at C800-F000, thus should be returned
later.

MD If you're depending on that particular load/alloc behavior, you'll have to
MD let me know not to load anything else which uses UMB's

 No, this is not _my_ dependations, this is analyzation of _current_
umb_init() behavior when enumerated conditions satisfied. Of course, this is
low probable that last paragraph in returned block will contain 'M' in first
byte, but this is possible, and I wish to confirm my verification of code.

- at next call to XMS/AH=10h your EMM386 should return next _higher_ block
   (say, at 0xC800). This should force inifinite loop in prev_mcb().

 This should force if mean this will force, if I right analyze.




---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] bug in UMB support

[Arkady V.Belousov]

Hi!

 2Michael Devore: Michael, try to initialize UMB blocks, returned to
EMM386 caller (DOS in case of with DOS=UMB), by 'M' letter - after this
FreeDOS should allocate UMB memory incorrectly (because prev_mcb() in
umb_init() will walk after latest previously allocated block). (To be
precise, there is enough to place 'M' in first byte of last paragrpah of
returned block). May you confirm this?




---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in UMB support

[Michael Devore]

I hope to have some free time later this weekend and will try to get caught 
up on a few FreeDOS items, including your requested test, a stand-alone UMB 
stress test, and code up an XMS block auto-grabber/releaser for Erwin 
Veermans'  NWDSK if it proves feasible and fixes the immediate problem with 
NIOS load limitations.

However, EMM386 may not necessary return a next higher block address 
depending on the size and order of what has already loaded in UMBs.  It can 
split large blocks and/or alloc a free block with a lower address than a 
previously allocated one.  If you're depending on that particular 
load/alloc behavior, you'll have to let me know not to load anything else 
which uses UMB's

At 06:13 PM 6/18/2004 +0400, Arkady V.Belousov wrote:
Hi!
17-éÀÎ-2004 09:47 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
  2Michael Devore: Michael, try to initialize UMB blocks, returned to
EMM386 caller (DOS in case of with DOS=UMB), by 'M' letter - after this
FreeDOS should allocate UMB memory incorrectly (because prev_mcb() in
umb_init() will walk after latest previously allocated block). (To be
precise, there is enough to place 'M' in first byte of last paragrpah of
returned block). May you confirm this?
MD Not yet, because I don't understand what you want me to do.  Initialize
MD which blocks how returned where and check for what problem?  What does 'M'
MD have to do with it?  It sounds like an internal DOS memory allocation 
chain
MD process, rather than an XMS UMB allocation.

1. FreeDOS allocates UMB through XMS API function AH=10h (Request upper
   memory block). As I understand, EMM386 inserts itself into XMS handlers
   chain to perform this request.
2. If you fill memory block by 'M' letter (0x4D) before returning through
   AH=10h functions, then this should cause wrong memory allocation in
   FreeDOS. I wish to confirm this.
3. 'M' is indicator of valid MCB, which is not last in chain. When
   config.c:prev_mcb() function scans MCB chain, it checks this letter.
   prve_mcb() called in umb_init() when UMB_MCB chain is not terminated (by
   valid MCB with 'Z').
4. To make check more stable, next scanrio should be performed:
- at first requrest through XMS/AH=10h return some block (say, at 0xB000),
  where last paragraph (last 16 bytes) contain {'M', 0, 0, 0xff, 0xff,
  other unimportant}. This imitates valid MCB with size field equal to
  0x.
- at next call to XMS/AH=10h your EMM386 should return next _higher_ block
  (say, at 0xC800). This should force inifinite loop in prev_mcb().


---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Johnson Lam]

On Tue, 27 Apr 2004 21:28:19 -0500, you wrote:

Hi,

That's why I'd like to see the feedback conduit of Bugzilla  -- and Tracker if it is 
judged worthy of support -- made more attractive to the casual FreeDOS users.

I feel the idea of Bugzilla is good but it's terrible difficult for
me. I fail to report bug, there're too many empty fields to fill. I've
to admit I'm stupid and I don't like complex forms and tables.

If a simplified version available I'm sure it can improve the
communication between programmers and users.


Rgds,
Johnson.



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149alloc_id66op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Steffen Kaiser]

On Tue, 27 Apr 2004, Michael Devore wrote:

 Well, I can't really agree that a standard tab in a public SourceForge
 project is well hidden.  Or that 24 requests in an obviously one-way

The tracker had been disabled multiple times, in fact, I had disabled it
myself at one time. I do not know, why it springs to life now and then.
I always thought Bart or Tom did enabled it again.

Bye,

-- 

Steffen Kaiser


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Bernd Blaauw]

Johnson Lam schreef:

On Tue, 27 Apr 2004 21:28:19 -0500, you wrote:

Hi,


That's why I'd like to see the feedback conduit of Bugzilla  -- and Tracker if it is judged worthy of support -- made more attractive to the casual FreeDOS users.


I feel the idea of Bugzilla is good but it's terrible difficult for
me. I fail to report bug, there're too many empty fields to fill. I've
to admit I'm stupid and I don't like complex forms and tables.
If a simplified version available I'm sure it can improve the
communication between programmers and users.
Rgds,
Johnson.
at http://www.freedos.org/bugs/bugzilla/query.cgi ,
to list bugs, just hit the huge QUERY button.
That will show all non-fixed bugs.
then open up a bugreport, fill in your data in the huge empty comment box, and hit 
COMMIT button.
at the bottom of the page is a link for entering new bugs instead of responding to them.

Bernd

---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Johnson Lam]

On Wed, 28 Apr 2004 09:50:34 +0200, you wrote:

Thanks Bernd,

at http://www.freedos.org/bugs/bugzilla/query.cgi ,
to list bugs, just hit the huge QUERY button.
That will show all non-fixed bugs.

1st time to see the buglist :-)

then open up a bugreport, fill in your data in the huge empty comment box, and hit 
COMMIT button.
at the bottom of the page is a link for entering new bugs instead of responding to 
them.

Thanks for your instruction, much better than the originals ;-)


Rgds,
Johnson.



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149alloc_id66op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Aitor Santamaría Merino]

Hi Michael,

I support your concerns about the tracker. I admit that I had forgotten 
about it, although I knew of its existence.

Michael Devore escribió:

Absolutely agreed, Bugzilla is too complicated and busy, and the usage documentation is sub-par.  But, it's what FreeDOS has, so we need to make the most of it unless and until something better comes along.
 

There was a time in which we had bugtrack, a simple and quite good (for 
my taste) bug tracking system. I don't mean to go back to bugtrack (as 
it seemed to happen to that faq-o-matic stuff?), I'd say that porting 
the bugs to other system (bugtrack or others) would be now a lot of 
worthless work, that could be better spent in coding and patching bugs.
Just in case it helps, when I have to fill in the bugzilla form, I leave 
most of the fields empty (I just care about title and the comment, and 
forget about the rest). Seems to work ;-)

And last but not least, I am not picking mails for any bug recorded in 
bugzilla either (although it's harder to say because there were no bug 
reports lately, had one improvement request for KEYB time ago), so yes, 
there might be a bug in bugzilla, or something we are not doing right 
about it.

Aitor

---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Bart Oldeman]

On Tue, 27 Apr 2004, Michael Devore wrote:

 While idly browsing FreeDOS sites, I see that Tracker in SourceForge has
 development requests going back to 2001. Several requests have since
 come to fruition without any notice or follow-ups there.  Can (or
 should) the Tracker tab be turned off so people don't assume that posted
 remarks are providing useful feedback, or minimally, titled with an
 announcement about Tracker not being supported?

the tracker is well hidden indeed but I just see 24 requests there. I
never looked at it so far. It can be disabled indeed.

The good thing about SF's bug system is that it emails you automatically
when you're involved and there's an update. I think bugzilla is supposed
to do that too but it doesn't for me.

Anyway. Looking at
http://www.linuxjournal.com//article.php?sid=7216
it seems that the one at freedos.org is a little out of date now so
it might just be easiest to install a newer version.

Bart



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug/enhancement development questions

[Michael Devore]

At 09:28 PM 4/27/2004 -0500, I wrote:

That's why I'd like to see the feedback conduit of Bugzilla  -- and Tracker if it is 
judged worthy of support -- made more attractive to the casual FreeDOS users.

Alright, after talking the talk, I walked the walk by responding to three open 
Bugzilla reports and successfully restraining myself from commenting on several more 
open and closed entries.  If I stepped out of line with anyone there, well, I guess 
you get to yell at me.




---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel