reading DMF

[kerravon]

I think that's a fascinating subject. At its time, as far as I can remember Amiga computers were perceived almost as a game console with a keyboard. Of course, they were able to run business software and they were used as graphic stations, but that's the general perception I felt at the time... Even as a game console it was soon surpased by Sega Genesis and SNES.

Curiously, sometimes happened the opposite you are telling: for example, Deluxe Paint was written in C originally for the Amiga (link to source code). It was ported to IBM and it turned to be even more successful on this platform!

And I had another thought. If ANSI.SYS was too inefficient, and also application developers didn't want to add a complication to their product that a specific fast ANSI.SYS be installed, that fast ANSI.SYS could have been hidden in the C library and statically linked so that no-one would even know. No worse than doing direct writes to the screen buffer, which is what they did anyway.

And it just occurred to me that that's how I may be able to solve an existing problem I have - not being able to run my ANSI version of microemacs 3.6 under HX - I should be able to solve that with a custom msvcrt.dll (as opposed to the msvcrt.dll that I produced for pdos/386).

Which would come very close to making Freedos+HX my development platform. In fact, maybe the entire way - because the problem I currently have with HX - one program spawning another - may have gone away with the new linker (pdld). And even then - if I revisit the spawn issue, I might be able to work around the same thing with another change to the custom msvcrt.dll.

Stay tuned?

 

[kerravon]

And I had another thought. If ANSI.SYS was too inefficient, and also application developers didn't want to add a complication to their product that a specific fast ANSI.SYS be installed, that fast ANSI.SYS could have been hidden in the C library and statically linked so that no-one would even know. No worse than doing direct writes to the screen buffer, which is what they did anyway.

And it just occurred to me that that's how I may be able to solve an existing problem I have - not being able to run my ANSI version of microemacs 3.6 under HX - I should be able to solve that with a custom msvcrt.dll (as opposed to the msvcrt.dll that I produced for pdos/386).

Which would come very close to making Freedos+HX my development platform. In fact, maybe the entire way - because the problem I currently have with HX - one program spawning another - may have gone away with the new linker (pdld). And even then - if I revisit the spawn issue, I might be able to work around the same thing with another change to the custom msvcrt.dll.

Stay tuned?

No dice.

dw &= ~ENABLE_LINE_INPUT;
dw &= ~ENABLE_PROCESSED_INPUT;
SetConsoleMode(stream->hfile, dw);

That code isn't having the desired effect under HX.

I'm still getting echo. And I'm not getting anything at all for the cursor keys being pressed.

BFN. Paul.

 

[Timo W.]

The Commodore Amiga might have been more successful if IBM PC programmers had been writing their fullscreen applications in a portable manner so that supporting the Amiga required nothing more than a recompilation.

This was done for lots of software that came out on both Amiga and Atari ST. And that software showed the issue: it's not the code, but the assets. Since the ST could only do 16 colors, the Amiga versions got that limitation as well, as it was using the same code and assets. Also, using Assembler was a must in many cases, so code stayed portable only within the same CPU architecture.

Portability is great, but only if speed is not the most important thing and all target platforms have at least the same or better specs. With the fast changes of the PC - getting more powerful pretty much every few months - portability with the ever-staying-the-same Amiga wasn't really feasible.

What killed the Amiga from an end-user's perspective was the adherence of publishers that every game should run on a stock A500 with 512+512KB. This is why we got such desasters like Wing Commander. It was a catch-22: with no software targeted at faster Amigas, there was no need to upgrade the system. But with no one in need of an upgrade / faster Amiga, there was no motivation for publishers to target faster Amigas. So the A500 remained the gold standard, lacking behind the new competition.

 

[kerravon]

No dice.

dw &= ~ENABLE_LINE_INPUT;
dw &= ~ENABLE_PROCESSED_INPUT;
SetConsoleMode(stream->hfile, dw);

That code isn't having the desired effect under HX.

I'm still getting echo. And I'm not getting anything at all for the cursor keys being pressed.

BFN. Paul.

I realized I only need Freedos + HX for the build machine, where I run miscellaneous Windows software (like CVS), plus I have a workaround (separate version of Windows microemacs) for the ANSI issue anyway - so I'm back on this job.

 

[kerravon]

This was done for lots of software that came out on both Amiga and Atari ST. And that software showed the issue: it's not the code, but the assets. Since the ST could only do 16 colors, the Amiga versions got that limitation as well, as it was using the same code and assets. Also, using Assembler was a must in many cases, so code stayed portable only within the same CPU architecture.

Portability is great, but only if speed is not the most important thing and all target platforms have at least the same or better specs. With the fast changes of the PC - getting more powerful pretty much every few months - portability with the ever-staying-the-same Amiga wasn't really feasible.

What killed the Amiga from an end-user's perspective was the adherence of publishers that every game should run on a stock A500 with 512+512KB. This is why we got such desasters like Wing Commander. It was a catch-22: with no software targeted at faster Amigas, there was no need to upgrade the system. But with no one in need of an upgrade / faster Amiga, there was no motivation for publishers to target faster Amigas. So the A500 remained the gold standard, lacking behind the new competition.

I'm mainly interested in fullscreen applications for the IBM PC. Are they limited to 16 colors even if you do direct writes to the screen buffer?

And is there a reason they need to use assembler?

I guess you do need some extensions to C90 and ANSI X3.64 in order to make/remove directories on a FAT filesystem for many apps - even utilities like "zip" - so those need to be provided in a standard way. You could potentially say that Posix would be that standard way, but I think something derived from FAT/MSDOS would be better, and I have that with some Pos* (unrelated to Posix - actually inspired by OS/2 Dos* functions) wrappers on MSDOS calls that I used for PDOS/x86.

 

[doshea]

I guess you do need some extensions to C90 and ANSI X3.64 in order to make/remove directories on a FAT filesystem for many apps - even utilities like "zip" - so those need to be provided in a standard way. You could potentially say that Posix would be that standard way, but I think something derived from FAT/MSDOS would be better, and I have that with some Pos* (unrelated to Posix - actually inspired by OS/2 Dos* functions) wrappers on MSDOS calls that I used for PDOS/x86.

I might not understand exactly what you're trying to achieve so this may be a silly question - feel free to ignore if so - but have you considered trying to mimic the C run-time library calls from popular contemporary DOS compilers to ease porting code from them?

For example mkdir() is defined with compatible signatures in the following header files in the following compilers:

• the free (as in beer) Turbo C 2.01 and Turbo C++ 1.01, and the non-free Turbo C++ 3.0 and Borland C++ 4.5: dir.h
• Watcom C/C++ 11, Microsoft QuickC 2.5, Microsoft C 6/7 (not sure which version I was looking at the help for): direct.h

It wouldn't be too hard to make one header file #include the other so that you could support source files intended to be built with any of those tools. And I think the only difference from POSIX in the case of that function is that POSIX specifies it should be defined in sys/stat.h apparently.

 

[kerravon]

I might not understand exactly what you're trying to achieve so this may be a silly question - feel free to ignore if so - but have you considered trying to mimic the C run-time library calls from popular contemporary DOS compilers to ease porting code from them?

For example mkdir() is defined with compatible signatures in the following header files in the following compilers:

• the free (as in beer) Turbo C 2.01 and Turbo C++ 1.01, and the non-free Turbo C++ 3.0 and Borland C++ 4.5: dir.h
• Watcom C/C++ 11, Microsoft QuickC 2.5, Microsoft C 6/7 (not sure which version I was looking at the help for): direct.h

It wouldn't be too hard to make one header file #include the other so that you could support source files intended to be built with any of those tools. And I think the only difference from POSIX in the case of that function is that POSIX specifies it should be defined in sys/stat.h apparently.

I'm not really trying to port other people's applications. I'm after a couple of things:

1. Public domain
2. C90-compliant

With the intention of porting everywhere, not specifically MSDOS or Amiga.

So the question of mkdir doesn't even come up. However, there are a minority of cases where it does come up, so I need to cover them. I was inspired by OS/2's use of the "Dos" prefix rather than having words all over the place. But I didn't like their use of words like "LONG" to "abstract" "long", as if one day someone is going to do "#define LONG short" and anything at all is going to work. So I'm not exactly using OS/2. And anyhow, I want MSDOS, not OS/2. So I switched from "Dos" to "Pos" and then made a wrapper to any MSDOS function I needed.

If someone wants to create a dir.h and have a #define mkdir PosMkdir or whatever it is, that's fine, but it's not something I personally have needed so far. I have had a need to do something similar to that with my windows.h (actually kernel32.c) though.

Oh - an update on Freedos + HX - there were some technical issues which are still being debugged, so still waiting for a result on that. And another issue is that I want to be able to run "cvs", but the executable I downloaded is dependent on wsock32.dll, which HX doesn't provide. I don't think it is actually used though, if I only use it locally, so I just need a dummy DLL - but when I dumped cvs.exe looking for the function names I need to dummy, I didn't see any names!

DLL Name: WSOCK32.dll
vma: Hint/Ord Member-Name Bound-To
80000074 116 <none>
80000073 115 <none>
80000008 8 <none>
80000002 2 <none>
80000003 3 <none>
8000000a 10 <none>
80000039 57 <none>
80000009 9 <none>
80000034 52 <none>
80000017 23 <none>
8000000b 11 <none>
80000004 4 <none>
...

In the same executable I have:

DLL Name: KERNEL32.dll
vma: Hint/Ord Member-Name Bound-To
7235e 45 CreateDirectoryA
7234e 260 GetDriveTypeA
7233a 551 RemoveDirectoryA
7232c 87 DeleteFileA
72312 458 LocalFileTimeToFileTime
...

which is what I am used to.

But another issue - one program spawning another and then it spawns another, which bypassed my hack for a presumed HX bug - appears to have gone away. And it wasn't an immediate issue anymore anyway, since I have replaced ldwin (my modified binutils) with pdld, which doesn't do such a spawn I believe.

BFN. Paul.

 

[Svenska]

Since you are interested in Windows 95 specifically, I'd like to point Raymond Chen's "New Old Thing" blog - it contains many tidbits from the era, including issues they had to deal with and reasons for their design decisions. Would be worth looking into, although there is no guarantee of correctness (and since the location has moved, many internal links don't work).

Regarding the abstraction of standard types, I found that there is no common 32-bit wide C data type across all architectures and platforms: "short" is 16-bit everywhere, "long" is 32-bit except on unixy 64-bit systems, and "int" is 32-bit except on 16-bit systems. So if you ever intend to migrate any of your code in any future to a non-Windows 64-bit platform, you will need to abstract the data types yourself or use the C99 fixed-width types (uint32_t and friends) in places.

 

[kerravon]

Since you are interested in Windows 95 specifically, I'd like to point Raymond Chen's "New Old Thing" blog - it contains many tidbits from the era, including issues they had to deal with and reasons for their design decisions. Would be worth looking into, although there is no guarantee of correctness (and since the location has moved, many internal links don't work).

Regarding the abstraction of standard types, I found that there is no common 32-bit wide C data type across all architectures and platforms: "short" is 16-bit everywhere, "long" is 32-bit except on unixy 64-bit systems, and "int" is 32-bit except on 16-bit systems. So if you ever intend to migrate any of your code in any future to a non-Windows 64-bit platform, you will need to abstract the data types yourself or use the C99 fixed-width types (uint32_t and friends) in places.

Not sure what you mean by "everywhere". On some systems, short is 18 bits. Even with SubC on the UC386 distribution of PDOS, short is 32 bits (it's either that or it doesn't exist - and that's all (well, best) that is available in the public domain). The "uint32_t" will not exist on a 36-bit system that is C99-compliant. You can use int_least32_t - that will exist, but it won't necessarily be 32 bits.

 

[Svenska]

You are right. I did not anticipate you intending to build a Windows 95-compatible OS for an 18- or 36-bit machine, but I'd really like to know more. (In other words, I implicitly assumed x86. Sorry for being unclear.)

 

[kerravon]

And I had another thought. If ANSI.SYS was too inefficient, and also application developers didn't want to add a complication to their product that a specific fast ANSI.SYS be installed, that fast ANSI.SYS could have been hidden in the C library and statically linked so that no-one would even know. No worse than doing direct writes to the screen buffer, which is what they did anyway.

And it just occurred to me that that's how I may be able to solve an existing problem I have - not being able to run my ANSI version of microemacs 3.6 under HX - I should be able to solve that with a custom msvcrt.dll (as opposed to the msvcrt.dll that I produced for pdos/386).

Which would come very close to making Freedos+HX my development platform. In fact, maybe the entire way - because the problem I currently have with HX - one program spawning another - may have gone away with the new linker (pdld). And even then - if I revisit the spawn issue, I might be able to work around the same thing with another change to the custom msvcrt.dll.

Stay tuned?

The technical advances over the last few months, and a bug fix (to PDPCLIB) and another procedural change (the way gccwin is built) in the last 24 hours, have indeed made Freedos an apparently viable development/build environment. Or at least the main thing has been done - I can rebuild gccwin.exe with itself (plus other tools I build) under Freedos and get a byte-identical executable.

So now I need to see if the other tools I use can also be made to work under this environment (CVS, zip, unzip).

 

[kerravon]

The technical advances over the last few months, and a bug fix (to PDPCLIB) and another procedural change (the way gccwin is built) in the last 24 hours, have indeed made Freedos an apparently viable development/build environment. Or at least the main thing has been done - I can rebuild gccwin.exe with itself (plus other tools I build) under Freedos and get a byte-identical executable.

So now I need to see if the other tools I use can also be made to work under this environment (CVS, zip, unzip).

Update - I got the latest stable CVS to work, but had to recompile from source (took quite a lot of work). I had to drop back to an older zip for it to work, and recompile that with a minor change to the makefile. The latest zip had an issue with long filenames under Freedos+HX. unzip was already working. 7z I had to drop back to an older binary.

That's all I actually know about. I'll see what happens in the next day or so when I try to actually run my build process.

 

[kerravon]

My Book 8088 (wasn't advertised as that, but it was) arrived today (and it was a NEC V20 - I could see the chip!). The manual is here:

111book8088 hand386.zip

drive.google.com

I've made videos (vlog) of it, still being uploaded, at pdos.org.

Anyway, it comes with something called an "ISA-bus-expansion". Does this give me the ability to use a real floppy drive and thus be able to read the Win95 3.5" DMF floppy disks?

 

[Chuck(G)]

Depends on the handling of IRQ 6, DMA 2 and ports 3f2-3f5 on that ISA-expansion. If they're uncommitted and functional, sure--but you'll also need a HD-capable BIOS. Lotsa "if".