17 November 2021, 08:45 | #301 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
As a reminder, it's 2021 now. Not 1983.
Advice: Don't use this. It is outdated. We're now almost 40 years after the release of MS-DOS. The only advice you should give to authors is not to depend on this design anymore. Then, by all means, please make it one. Poking into a screen memory is not a "C90 design". It is a 1983 design. |
17 November 2021, 09:04 | #302 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
The higher-level BIOS looks very similar to C, exporting a C library, which includes a stdout stream. It so happens that on the Amiga the BIOS is in fact a C library, and writing to stdout will pass that data on to the Amiga Write() function. The Amiga understands ANSI codes, so nothing further needs to be done. Does that sound more reasonable? |
|
17 November 2021, 12:41 | #303 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Actually, another place it could have gone is in the C library. Perhaps if a setvbuf to fully-buffered is done, the ANSI interpretation starts. Because if you unconditionally drive 0xb8000 it will prevent redirection from working.
|
17 November 2021, 13:19 | #304 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Does the speed argument even matter in 2021? Today's machines are by at least two powers of magnitude faster than machines back then.
|
17 November 2021, 16:36 | #305 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
C90 does 90% of the job of getting people to write "standard code". ANSI control sequences come close to doing the rest. Plus if you are manipulating files in a directory, as you often are, you need an API for that, which is where MSDOS comes in. The question then is what is the barrier to using these things. It is amazing that Windows only started supporting ANSI control sequences a few years ago. |
|
17 November 2021, 19:27 | #306 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
|
17 November 2021, 19:46 | #307 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
|
18 November 2021, 06:39 | #308 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
And why is that an important target, in year 2021? Furthermore, why is this even the right forum, given that eab is on Amiga?
|
18 November 2021, 09:38 | #309 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
To answer the question of what went wrong in the 1980s that saw people writing non-portable software.
Quote:
I've just modified micro-emacs so that the ANSI flavor works with PDPCLIB as the C runtime library for Win32. I think the same micro-emacs source code should work on PDOS-generic under the Amiga (since the Amiga already supports ANSI escape codes), but I need to write more code to handle setvbuf of stdin to no-buffering for both PDOS-generic and the Amiga version of PDPCLIB to make it accept a ctrl-x, ctrl-c sequence. I assume the Amiga is line-buffered when doing a Read() from standard input? |
|
18 November 2021, 12:17 | #310 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
IMO it didn't go wrong in the 80's. Rather, in the 90's. In the 80's machines didn't have enough horsepower to do otherwise : if you didn't tie your program to some specific architecture it would have been feature limited, lacked performance, or even didn't work at all. This has changed since. In addition, every vendor had own view and this led to fragmentation. This hasn't changed since. Software today suffers from unneeded complexity because it's marketing needs which controls the world, not technical needs. There is nothing wrong in wanting to examine the past so to avoid repeating past mistakes. There is nothing wrong in willing to adopt an ABI that's simple, portable and easy to use. And testing it on limited machines to see how good it performs. However, taking MSDOS for this task is betting on the bad horse. Same for C90. (Note that i won't blame you for that ; currently there is no good horse at all to bet on.) What we could do is to design new set of APIs that satisfies the "keep it stupid simple" paradigm. But it must be feature complete. |
|
18 November 2021, 17:43 | #311 | |||||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
It is in my nature to convert answers into code before I forget, so I need to prepare the code. :-)
Quote:
But first - do you agree that even in the 80s it was possible to make text mode programs portable? Or do you think memory was a constraint then? I think the correct solution for memory constraints was to upgrade to an AT. Quote:
Quote:
Quote:
#define ESC_CHAR '\x1b' so that I can control an ANSI terminal from both ASCII and EBCDIC. I was thinking of creating a c90ext.h Quote:
|
|||||
18 November 2021, 18:08 | #312 | |||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Quote:
Quote:
Yes, of course it was a constraint. There are plenty vendors, more than ever. Just nobody cares about outdated technology, because there are no customers for such software, quite simple. Quote:
Quote:
And no, nobody cares about XT or AT or (to bring it back on topic) Amiga anymore. XT even less. Today's hardware requires the power for more than "running windows". How do you want to stream a video in real time with an XT? Most internet traffic is video today. Quote:
Today? Graphics and cross-platform is pretty much "SDL" to me today. |
|||||
18 November 2021, 18:17 | #313 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
If it defines a '\a' for "alert", why not have something for the very important ESC char needed to write ANSI escape sequences? Rather than burdening the compiler with a '\e', it seems simple to have an ESC_CHAR and ESC_STR defined. The other character I need is XON.
|
18 November 2021, 18:34 | #314 | |||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
Yes memory was a constraint, but display capabilities were more important IMO. Say, if you want 80x25 -- impossible for my old Oric. Limited to 4 colors on Atari ST. How to be portable under these conditions ? Quote:
Quote:
Quote:
Consider how it handles arithmetic overflow, for example. Quote:
It must be so that just about every program in existence could be rewritten with it. I don't think a web browser could be written with just your current PDOS functions, for example. |
|||||
18 November 2021, 18:49 | #315 | ||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
|
||
18 November 2021, 19:03 | #316 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
Quote:
|
||
18 November 2021, 19:33 | #317 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Actually, it depends on the environment and the machine the code is executed on. For example, if adding two signed integers overflows, there is nothing the C standard guarantees. It is undefined behaviour, so anything can happen. C does not guarantee that numbers are represented in binary, and in two's complement representation.
|
18 November 2021, 20:35 | #318 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
PDOS/386 is a complete standalone OS - a 32-bit version of MSDOS, and also a mini Windows clone. It is 30,000 lines of code, plus there is another 20,000 lines of code for the C library.
|
19 November 2021, 07:46 | #319 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,351
|
Quote:
And perhaps not 100% standalone - I imagine you call BIOS for base i/o (disk block access) and only implement FAT file system yourself ? But granted - it's more complex than just a wrapper. Probably still not a good stress test for the programming language, though. That said, 30000 (+20000) lines seem excessive for this. What justifies such a big size ? In comparison, my system framework contains code for graphics, sounds, disk i/o, memory handling (including dynamic sized arrays/strings), resource tracking, command line parsing, keyboard, mouse, timer + vblank interrupts, amiga asl file/dir selector, and contains atari screen conversion + c2p + ham8 rendering. And it is (a little less than) 8500 lines. Yes, of asm. So ok, it works on top of AmigaOS, but nevertheless. |
|
19 November 2021, 17:01 | #320 | ||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
So I've proven the entire software suite I wish to run. All in C90. I don't know how other languages stack up against that - if you write the entire development suite in that language, what do you get? BTW, one thing I discovered while getting msged to build - I had to press ESC twice to exit because I don't use a timer (not part of C90), and the keyboard routine is looking for an ANSI escape sequence when it encounters an ESC, and it is exited if a second ESC is detected. Since I wish to write in standard C90 instead of making my code timing-sensitive and non-standard, I was thinking that what I should actually do is make the OS (PDOS) keyboard routine generate two ESC characters in response to the user pressing ESC. What do you think of that? |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
|
|