flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > DOS > Newbie : DOS program from a book wont run

Goto page Previous  1, 2, 3, 4, 5, 6
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14672
Location: Origae-6
New OSes require new CPUs. This isn't really a new thing. But whether or not 32-bit code will become like the dinosaurs is another matter. I personally don't want it to die, there are many advantages to keeping it viable. And I suspect many others feel the same, so my guess is it will still be usable for many years to come. Perhaps the only thing that will kill it is if CPUs no longer support 32-bit code. The two major CPUs on the market today, x86 and ARM, are still supporting the 32-bit code and I don't seen them making any threats to kill it. In fact with the latest 64-bit instructions from ARM almost all instructions can be either 32-bit or 64-bit wide even without switching to 32-bit legacy mode.
Post 07 Feb 2017, 01:50
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 501
Location: New Zealand

Trinitek wrote:
It's not good hardware if it's designed to fail.

That's just it, its only "failure" is its inability to run the latest version of the software. The hardware is still perfectly ok Mad

_________________
FAMOS - the first memory operating system
Post 07 Feb 2017, 01:54
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 290

rugxulo wrote:

Meh, I thought Arch was about choice as they advertise. Good to know they're full of bullshit too just like Ubuntu. It makes me cringe everytime I see 64-bit pointers or ints or whatever when you can't even fill 32 of them, just because certain individuals are obsessed with it.

Some of us use a lot of Virtual Machines. I'm so sick of their justifications always being as if OSes are never used in slim VMs. Mad

I want to be able to "print" my own hardware so I can have one good OS forever (because even if the hardware fails due to age, I can print another) instead of relying on others' whim. Really makes me mad right now.

(it doesn't mean I won't use the latest "trend" at all ofc, but I want to have a reliable and trusty one to keep forever, just like I keep my data, it doesn't mean I don't get new data of course...)
Post 18 Feb 2017, 17:31
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)
I hate to defend the industry and its overzealous deprecation, but in fairness, development is expensive, difficult, and time-consuming. So without volunteers to maintain 32-bit distros, it won't be done. Also, in fairness, the last of the 32-bit only cpus was made (more or less) many years ago, so those machines are dying out: breaking, being disconnected, etc. New hardware is relatively cheap these days (thankfully). There will still be 32-bit app compatibility atop 64-bit OSes (and of course VMs, as you mentioned). I know this is far from perfect and inconvenient in many ways, but they never truly pretended to keep 32-bit alive forever.
Post 19 Feb 2017, 09:17
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 290
Time consuming? Sometimes they port it to completely different architectures who are still less popular! It is beyond retarded to keep say PPC and not x86-32 no matter how you see it, nothing but an excuse.

It's as easy as recompiling with a switch, because if it does indeed work specifically only for x86-64, then the code won't work on PPC either. But it does, thus the code is indeed "portable". A flick of a switch (or command line option) is all that is needed. That's why Gentoo works on almost everything.

As for VMs, you missed the point. VMs need an OS to run. And that's the problem here. You can't use a VM if you don't have an OS, and where will you get the OS from?


So what's the problem? Building the ISO once every 6 months? That's pathetic excuse to be honest. Bandwidth? That's only a problem if a lot of people actually download it, which makes the deprecation retarded anyways.

It just needs to be there as an option for when you need it. BTW yes Volunteers can do it, the problem with Volunteers is that they are not official. People tend to look for official things, as they get popularity/advertisement and trust it better.
Post 19 Feb 2017, 18:07
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)

revolution wrote:
I think you are conflating real/protected with single/multi-tasking. They are separate things and can be mixed in any arrangement with each other.



DexOS (written with FASM) is 32-bit single-tasking. IIRC, he was loosely inspired by (original) XBox, which was one cpu running a single task and (up to) three threads.

Desqview supposedly had an 8086 version. DOSSHELL supported (286+ ??) task swapping, which wasn't nearly as good. But OS/2 1.x (286+) was multitasking yet had heavy penalty ("penalty box" ??) for real-mode DOS software due to "brain dead" lack of proper mode switching (LOADALL?). I think Win 3.x's "standard" (286) mode was task-switching only (where only Win16/NE apps multitasked?), hence 386 "enhanced" (with newfangled DPMI) was preferred for multitasking DOS stuff. Novell / DR-DOS 7 was similar in regards to task swapping (286+) vs. true multitasking (386+), the latter of which required its own EMM386 + DPMI.


revolution wrote:

Almost all CPUs support real mode (with only a very few exceptions that almost nobody will see in normal usage).



Intel 80376 (embedded) perhaps?? BTW, with computers that have UEFI but no CSM, i.e. no BIOS compatibility, what is the point? I guess it's just simpler to use the same fabs instead of trying to forcibly remove the obsolete functionality from the cpu?


revolution wrote:

But not all OSes allow real mode or v8086 mode.



Do literally any support "real" mode?? Besides DOS? I'm not sure how much "support" they could give. Bimodal code? Unlikely. Some old OS/2-friendly compilers used to output "bound" .EXEs, and you can still insert a (useful) DOS stub into a PE MZ these days, but that's not OS-level support either. In short, (386+) V86 mode was hugely popular and heavily utilized by OS/2 2.x, Win9x, WinNT (non-64-bit), DOSEMU (32-bit), etc.

For all intents and purposes, V86 mode is considered "real mode" (compatible). That was the whole point. (I know you know this, just saying.)


revolution wrote:

Notably, a CPU in 64-bit mode cannot support v8086 mode.



We do have (Intel) Nehalem-era "unrestricted guest mode" (circa 2010), aka (newer) VT-X (virtualization). AMD allegedly has "paged real mode".


revolution wrote:

A CPU in protected mode cannot support real mode.



Except (386+) V86 mode is considered a variation of pmode, allowing you to directly run old DOS programs.


revolution wrote:

And a CPU in (un)real mode cannot support 64-bit code.



Unlike 32-bit code, you cannot mix 64-bit code with other bitness. So there's no 64-bit DOS extender, no. Yet people genuinely either aren't aware or don't understand that DOS programs can be 32-bit and/or pmode (e.g. Doom, Quake, etc.) using 32-bit registers, accessing well over 1 MB of RAM. Well, even (hardware) EMS or (286+) XMS would let you do that years before (but not as good).

I've not seen any real attempts to provide PAE (36-bit?) memory support to DOS. At one time CWSDPMI planned to support it, but I guess nobody cared. 32-bit Windows hates PAE due to driver bugs, and the address space alone limits available RAM to 3.1 GB. Plus you can't (normally) mix 64-bit objs, libs, plugins, drivers, etc. on a 32-bit system or vice versa. So that makes things difficult and redundant. With Windows 10 requiring a late-model P4, I'm guessing that 32-bit will go away entirely eventually. If it isn't MS who kills it, it will be driver manufacturers or similar.

As far as registers, you could already use (FPU-ish) MMX for 64-bit numbers or SSE2 etc. in plain DOS. Or handroll your own (software-only) routines. I've seen 64-bit number crunching (or bignum) in DOS, too. DOS compilers long ago had the foresight to allow 32-bit numbers, e.g. Turbo C, Turbo Pascal, Oberon-M, etc. Hence the FAT12/16 limit of 2 GB files (which fit in a "signed long"). Obviously DOS just didn't have the infrastructure (or developer interest) to get further file systems, though, beyond FAT32 (which has larger capacity but still limited in individual file size, and even FreeDOS omits the quirky/unpopular 4 GB files and instead only sticks to 2 GB).

So, no, not in the traditional AMD64 sense can you use "64-bit", but in other contexts 64-bit is far from impossible (in DOS). Just use FreeDOS + DJGPP (32-bit DPMI) with -std=c99 ("long long") and a really big RAM drive and/or software cache! Cool
Post 24 Apr 2017, 08:43
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)

Furs wrote:
*grumbling*



Just thought you should know .... Laughing

https://blog.finnix.org/2017/04/18/the-future-of-finnix/

EDIT:

Furs wrote:

I want to be able to "print" my own hardware so I can have one good OS forever (because even if the hardware fails due to age, I can print another) instead of relying on others' whim.



Perhaps OpenRISC? EDIT: Maybe not, RISC-V sounds much better but still not nearly perfect.
Post 24 Apr 2017, 08:45
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 290
Well, at least there's the community initiative for now: http://archlinux32.org/ (idk how long it will last)

I guess I'll have to learn to use Gentoo for my VMs... kinda a pain to compile everything on updates for VMs tho. Sad
Post 12 May 2017, 11:09
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)

radarblue wrote:
I still regard Gary Kildall as the true inventor of the DOS. He even worked for Intel.



CP/M was before my time, so I don't really know anything about it from first-hand experience. Of course, it was still very influential to many others, to say the least.

Apparently Gary was only a part-time contractor, not really full-time working for Intel. Although he was indeed highly educated, skilled, experienced, etc. Besides, CP/M was originally only 8-bit for 8080, a far cry from 16-bit 8086. MS-DOS/PC-DOS v2 was vastly different to CP/M, and it only diverged further from there. DOS was not written in PL/M either.

LGR made a nice video summary about Digital Research.

Gary's kids recently (quasi-)published online (part of) his unpublished/unfinished memoir. Very informative.

Gary was also co-host of The Computer Chronicles for seven years (1983-90). Many of their old videos are also available on YouTube, and they even did a retrospective of him after he died.

EDIT: Oops, you already mentioned The Computer Chronicles (although you link to a different channel with other non-related stuff).

If you're really super interested in CP/M, you'll probably get more help from news://comp.os.cpm (or that one user around here who is unnaturally obsessed with CP/M-86 despite no attempted FASM port).


Quote:

From the site linked to above, microsoft provides these descriptions
d:\> command | more [/c] [/p] [/s] [/tn] [+n]
The Square Brackets are not typed in !
Paths uses \ this slash .
command features uses / this slash .



[ ] is just the documentation's notation (a common idiom). It means optional parameter, so you can omit those options upon use, if desired.

DOS v1 (same as CP/M) didn't have subdirs, so they used '/' for switch char (switchar). When subdirs were added in v2, they then used '\' for path separator.


Quote:

I can not load X86-64 programs like Native Instruments synths using CMD-prompt. Neither can I load the web browser Dos_Lynx on CMD-prompt, nor DOS-box.
However in DOS-box I can also load the old (16bit ?) DOOM game . Smile



If you have XP (or older), try SwsVpkt (virtual packet driver). Never tried it myself, but it may allow you to use suitable DOS networking programs (e.g. Links2 although Windows binaries also exist, apparently).
Post 20 May 2017, 15:07
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)

radarblue wrote:
I realize I need some more training. So at the moment I am concentrating on C. Bought in an Arduino to practice on some electronics too. it is very fun. in C, I wanted to do graphix on the console screen (like sinus curves and triangles), and more or less all searches ended up with "welcome to Windows API, C++, WPF, .NET and MFC". and I looked at it, didnt understand a thing ... alot of wierd handlers and fancy instructions. I decided to discard the win32 API for the moment.

Found some websites that have example codes on sinus and grids. gonna practice there for a good while. anyways happy newyear. You are a fine crew of people ! cheers.



Graphics? Windows? I don't understand either one! But you're presumably better off using/learning SDL and/or something like QB64. (Hmmm, apparently QB64 no longer uses SDL but instead FreeGLUT.) EDIT: Or maybe Allegro would interest you?
Post 20 May 2017, 15:28
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.