http://www.bttr-software.de/forum/ DOS ain't dead en Reply from cm, 30.08.2010, 21:51:

> > > > > The only way is just to terminate the application.
> > > > Correct.
> > > Not that much.
> > Well tell us.
>
> NO I won't. No need to duplicate Japheth's work, see above.

Using RM callbacks (which I did use too, but that's not the point) doesn't properly remove the "DPMI process" or "context", so you're not really back. In that state, it might be a bad idea to terminate the current DOS process. (Japheth probably knows more about that, regarding HDPMI.)

> > How bout you just execute your own executable?
>
> Bad hack.

Right, but it works well enough if you get the name.

> > Besides, this particular issue doesn't exist for a Windows process and
> > without a problem to work around, faking a child isn't useful anyway.
>
> Strange, how do you execute 3rd party crappy code then ? And why did
> Firefox ban crappy plugins (most notably Flash) into a separate process ?

I would think Firefox is not a DOS or DPMI program, so that this would not be the particular issue that we talked about.

> > In other news: lol if u b trollin b trollin r8 dude
>
> Is it 64-bit code ? Does it compile ???

Why would it even be 64-bit code. And yes, it does compile:

D:\>debug
Executed initcont
-a
0F88:0100 mov eax,cr0
0F88:0103 inc eax
0F88:0105 mov cr0,eax
0F88:0108
-u 100l8
0F88:0100 0F20C0            MOV     EAX,CR0
0F88:0103 6640              INC     EAX
0F88:0105 0F22C0            MOV     CR0,EAX
-


See? (True, it's not optimal and all the other preparations to properly go into PM are still missing, but better than not compiling at all.)

(EDIT: No, not all text that contains the token "r8" (or any other register name) is code.)

> > (BTW for ring 0 access I prefer JLMs.)
>
> Sure, and this works without external files.

Sure, and going into PM on your own works with an EMM, XMM or DPMI host installed.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8644 Mon, 30 Aug 2010 21:51:57 GMT Reply from cm, 30.08.2010, 21:40:

> This is probably because of all output formats enabled by default. You'll
> have to manually disable non-DOS targets (win32, macho) in NASM.H or
> OUTPUT.H or whatever (I forget), which is what was typically done in old
> 0.97/0.98 days. Then it should run a little better (but not much).

Already thought about that. I'll probably disable macho and elf (maybe rdf too), but win32 and coff might be useful for HX and DJGPP development. I'll also have to look into making these things optional via C preprocessor variables so that we might get these patches into the official NASM builds. That could be accomplished with an additional makefile for Open Watcom that only has 16-bit DOS as target. (The label dos is currently used for the DPMI output format in the Open Watcom makefile.)

> which lacks x86-64 support which isn't needed here anyways.

As I wrote, I already disabled post-686 instructions, including all IA64-emulation and AMD64 stuff. I'll look into disabling support for these architectures in other places except the expression evaluator (that would be too much work).

I thought about disabling post-386 instructions too. This way, one would be able to create basic 32-bit programs with the 16-bit build, but anything else would require the DJGPP build.

> Make sure to use -os or -oxs or whatever for OpenWatcom.

Yep, already done. I also tested other different options. I have to manually enter different data segment names to avoid overflowing the default segment. All the data needs to be handled as far too. (Large or Huge memory model.) Maybe Open Watcom can be talked into moving data to overlays, which may or may not enable segments or even single items larger than 64 KiB.

> EDIT: Oops, TC doesn't support C99, doh.

I really wasn't looking forward to extend my toolchain to the semi-free TC either. (You only get the binaries, and only from that one hidden museum site.)

> > Maybe time to throw out those 8086's and 80186, and raise the limit to a
> > more modern machine, like a 286 ? :-D :-D :-D

Actually, the oldest real machine I'm running has a 586-class CPU. Porting it to a 16-bit platform is just for fun.

> Yes, if he's using XMS at all in the future, it will be 286+ only.

It could be optional, with disk swapping if no XMM is installed. Because, you see, I did mention disk swapping and XMS.

> I guess he likes the new macro features or whatever.

Right. Besides, I'm usually with the latest daily build of NASM. Some of my code right now probably won't even assemble with 2.07, and I'm already planning to use the better preprocessor of the upcoming 2.10 release. 0.98.xx was a joke compared to what we get now. (Also, I don't know whether you are allowed to use 2.06 or older releases under the 2-clause BSD license. That's important to me for ideological reasons.)]]> http://www.bttr-software.de/forum/forum_entry.php?id=8643 Mon, 30 Aug 2010 21:40:01 GMT Post by j_hoff, 29.08.2010, 22:21:

Sorry folks, no exciting pictures of my little sister here ;-), i just want to direct your attention to my latest project: LANSTAT a LAN STATus monitor. Though it cannot compete with projects like "Big Brother" or "Big Sister", my "Little Sister" has got some interesting features. It runs under (MS-)DOS (but can be used under Windows as well), is rather compact in size, yet very flexibly configurable. Therefore it can be used with virtually any networking software available for DOS and can do even more that just ping a number of hosts.

Please feel free to download the package from here and try it yourself.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8642 Sun, 29 Aug 2010 22:21:56 GMT Reply from bretjohn, 29.08.2010, 17:59:

> the code is already 100% done, it just doesn't work the same on every
> platform.

Well, then, apparently it's not 100% done. :-|

If it were me, what I would probably do is create some subroutines that use GS:[ESI] as a real mode input parameter. For example, instead of:

MOV AX,GS:[ESI]

I would create a subroutine that does all of the necessary manipulations/calculations and:

CALL MovAxGsEsi

That approach should allow you to keep most of your code intact. You could also do it with macros instead of subroutines. I don't know exactly what your code looks like, but you probably wouldn't need to create very many of these types of subroutines/macros to "fix" the program so it would work on any 386+ platform.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8641 Sun, 29 Aug 2010 17:59:20 GMT Reply from Japheth, 28.08.2010, 19:20:

I played with this stuff, but am unable to link. olink.exe tells "Invalid target name":


        set ORANGEC=d:\orangec
        set PATH=d:\orangec\bin;
        olink.exe /c /T:CON test.o /otest.exe /Ld:\orangec\lib clwin.l climp.l
olink Version 4.1.3 Copyright (C) LADSoft 2006-2010
Error: Invalid target name


When I use ocl.exe instead of occ.exe - that is, the linker is called implicitely by the compiler - it works. But I need a separate link step.

Perhaps one of the smart guys here can help?

EDIT: problem solved, the olink parameter is /T:CON32, not /T:CON. This is an error in the docs.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8640 Sat, 28 Aug 2010 19:20:10 GMT Reply from bretjohn, 28.08.2010, 16:35:

> When copying to the same HD, you preferably use a BIG BUFFER
> (say 16 MiB), while in other cases (HD0->HD1, HD0->RAMDISK,
> HD0->USBstick0, USBstick2->USBstick2, ...) a small buffer (say 64 KiB)
> would be sufficient and maybe even faster.

Nice idea, but unfortunately won't work too well without adding another INT 13h extension. The maximum number of sectors (blocks) you can transfer to/from a disk in a single INT 13h transaction is 255, or 127.5 kiB (assuming the standard 512 bytes/sector). Also, the memory address provided for the transfer is always expected to be in segment:offset format, so that automatically limits it to 64 kiB.

You could load a "large buffer" with multiple INT 13h requests and then empty the buffer the same way, which may save a little bit of head thrashing on a real hard drive (with actual platters & heads & tracks) if the sectors were in fact contiguous.

> Also storage media durability should be reported (true for HD, sticks,
> floppy, false for RAMDISK).

I would probably use a term other than "media durability" for that concept. At least to me, HD's & CD's are more durable than flash disks (which by design have a limited lifespan and should be treated as unreliable & disposable like floppies are). To me, the concept you're trying to impart is more like "data durability" (or "permanence" or "stickiness" or something like that), not "media durability".]]> http://www.bttr-software.de/forum/forum_entry.php?id=8639 Sat, 28 Aug 2010 16:35:38 GMT Reply from Arjay, 28.08.2010, 11:44:

> I just didn't memorize all the 8550 posts properly :crying:
LOL

> > bug reports to be submitted either via email or the
> > forum (it would appear the preferred option)
>
> Do I really have to register to one more forum ??? :confused:
I know where you are coming from. Post here and I'll happily post a link to your report if you like. Although to be honest pretty painless sign-up process.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8638 Sat, 28 Aug 2010 11:44:48 GMT Reply from Arjay, 28.08.2010, 11:40:

> HWiNFO32 became freeware with version 2.20.
Darkened room typo :) The date was correct....

> And that's not hidden:
"Hidden" in the sense that it required a search of history.txt for "freeware" to find :-D

> HWiNFO version 5.2.5 available --> 5772 :-D
That post predates me here :)]]> http://www.bttr-software.de/forum/forum_entry.php?id=8637 Sat, 28 Aug 2010 11:40:51 GMT Reply from Rugxulo, 28.08.2010, 04:55:

> David Lindauer has released the Orange C compiler and toolchain version
> 4.1.3 on 02 May 2010. [It] is entirely new work that is heading in the
> direction of a completely retargetable optimizing compiler/toolchain.
>
> Home page & download: http://www.members.tripod.com/~ladsoft/orangec.htm

It's basically alpha state but the (heavily-improved) successor to CC386. It does produce better (faster) code but of course still needs some work. The output is exclusively Win32/PE in HX-compatible format.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8636 Sat, 28 Aug 2010 04:55:34 GMT Reply from Rugxulo, 28.08.2010, 04:53:

> > NASM.EXE is a 460 KiB file which means that it barely
> > runs at all and usually crashes if I try to assemble anything at all (at
> > least I hope the crash is only due to running out of memory).
> NDISASM.EXE
> > works fine though, and is just about 110 KiB.

This is probably because of all output formats enabled by default. You'll have to manually disable non-DOS targets (win32, macho) in NASM.H or OUTPUT.H or whatever (I forget), which is what was typically done in old 0.97/0.98 days. Then it should run a little better (but not much). Last 16-bit build is for 0.98.39, found on SourceForge, which lacks x86-64 support which isn't needed here anyways. (Turbo C will produce smaller code, I think, but I may be thinking of after UPX, which wouldn't help shrink RAM use. Make sure to use -os or -oxs or whatever for OpenWatcom. EDIT: Oops, TC doesn't support C99, doh.)

> > So NASM still can be compiled for 8086 systems. If I have time for that,
> I
> > might look into stripping it down better to get the executable's size
> down.
> > Maybe write some code to let it use disk or XMS swapping? Hmm.
>
> Maybe time to throw out those 8086's and 80186, and raise the limit to a
> more modern machine, like a 286 ? :-D :-D :-D

Yes, if he's using XMS at all in the future, it will be 286+ only. I believe cm is using NASM 2.04+ features in his port of RxDOS. While I don't personally see a huge need to have a 16-bit NASM just to assemble that, it would still be cool to have. I guess he likes the new macro features or whatever.]]> http://www.bttr-software.de/forum/forum_entry.php?id=8635 Sat, 28 Aug 2010 04:53:31 GMT Reply from DOS386, 28.08.2010, 01:29:

> Don't you read this forum?!

I do ... I just didn't memorize all the 8550 posts properly :crying:

> bug reports to be submitted either via email or the
> forum (it would appear the preferred option)

Do I really have to register to one more forum ??? :confused:]]> http://www.bttr-software.de/forum/forum_entry.php?id=8634 Sat, 28 Aug 2010 01:29:59 GMT Reply from DOS386, 28.08.2010, 01:26:

> Do you have a specific protocol in mind? If this is something you're
> wanting, you probably need to come with a design/API/protocol and

under progress :hungry:

> do an initial implementation for BIOS/kernel provided drives. Like I
> stated earlier, if I did it for USBDRIVE I would limit my scope to USB
> disks, and it sounds like you want much more than that.

Knowing whether 2 volumes are on same USB HD (use big buffer) or not would be useful.

> I'm guessing that you are referring to a drive using its internal buffers
> to do the copy instead of actually transferring the data across the bus
> into RAM and back across the bus again? If that's the case, it would take
> much more intimate knowledge of how the disk works than the
> volume-to-physical relationships. You would have to know specific hardware
> details, like whether the disk even has an internal buffer that you can
> manipulate or not (e.g., USB flash drives don't, but USB-attached hard
> drives might).

Interesting, but not what I was referring to.

When copying to the same HD, you preferably use a BIG BUFFER (say 16 MiB), while in other cases (HD0->HD1, HD0->RAMDISK, HD0->USBstick0, USBstick2->USBstick2, ...) a small buffer (say 64 KiB) would be sufficient and maybe even faster.

Also storage media durability should be reported (true for HD, sticks, floppy, false for RAMDISK).]]> http://www.bttr-software.de/forum/forum_entry.php?id=8633 Sat, 28 Aug 2010 01:26:10 GMT Reply from DOS386, 28.08.2010, 01:09:

> The compatibility issue that I'm worried about is that it seems that a "dos
> boot disk" as prepared by later versions of windows

don't use such "DOS" ;-)

> boots into some sort
> of emm386-like mode where the switch to unreal mode fails because the CPU
> has already been set in some mode that breaks my "switch to unreal" code

Right :-( But it breaks your "use of the unreal mode" too ...

> I've never really investigated what that problem is

V86 has the 64 KiB segment limit too and you can't do INC CR0 in V86 mode ...

> "switch from pmode to real mode" before switching to unreal mode might fix

YES, but "V86 to real" is difficult and depends from EMM386 version, there is no good official way ...

> it may be gone. One week ago today I suffered a HDD+motherboard+power
> supply failure

Voltage increase killed all the other stuff :crying: ???

> and lost everything. I have backups of all my good stuff,
> but I suspect that that update might have been tucked away in an unbacked
> up folder since it was just to test. IIRC, it was an easy change to make
> (just the device+vendor ID) so I can do it again once I get a new machine.

:-|]]> http://www.bttr-software.de/forum/forum_entry.php?id=8632 Sat, 28 Aug 2010 01:09:41 GMT Post by rr, 27.08.2010, 22:40:

David Lindauer has released the Orange C compiler and toolchain version 4.1.3 on 02 May 2010. [It] is entirely new work that is heading in the direction of a completely retargetable optimizing compiler/toolchain.

Home page & download: http://www.members.tripod.com/~ladsoft/orangec.htm]]> http://www.bttr-software.de/forum/forum_entry.php?id=8631 Fri, 27 Aug 2010 22:40:05 GMT Reply from rr, 27.08.2010, 21:55:

> > > Martin made the following post on the HWiNFO forum
> >
> > Doesn't reveal when other versions got freeware.
> Agreed. Basically the answer was fairly well hidden in history.txt file
> supplied with the HWiNFO32 or online
> on
> this page - HWiNFO32 became freeware in v2.10 (July-22-2008).

HWiNFO32 became freeware with version 2.20. And that's not hidden: HWiNFO version 5.2.5 available --> 5772 :-D]]> http://www.bttr-software.de/forum/forum_entry.php?id=8630 Fri, 27 Aug 2010 21:55:46 GMT