-
Notifications
You must be signed in to change notification settings - Fork 0
/
readme.txt
1101 lines (844 loc) · 35.6 KB
/
readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
PDOS - Public Domain Operating System
-------------------------------------
Version 0.9X, released YYYY-MM-DD
Written by Paul Edwards, mutazilah@gmail.com
Released to the public domain
You may use this entire package for any purpose whatsoever
without restriction, as discussed here:
http://creativecommons.org/publicdomain/zero/1.0/
That includes, but is not limited to, closed-source,
proprietary commercial products. It is hoped that a
company (possibly an American company) will convert
PDOS into a commercial product that they sell to
compete with the Microsoft/IBM monopolies.
INTRODUCTION
------------
PDOS currently comes in quite a variety of flavors:
Mainframe:
1. z/PDOS - runs on an IBM mainframe (z/Arch), nominally
in AMODE 64, but (via the use of page tables) effectively
AMODE 32, giving a normal 32-bit environment for MVS
programs that would otherwise run as AMODE 31.
2. PDOS/390 - runs on an IBM mainframe (S/390 architecture).
Predominantly designed to be compatible with a subset of the
31-bit MVS interface, so it can run programs as AMODE 31,
RMODE ANY. Also intended to support Posix interface.
3. PDOS/370 - runs on an IBM mainframe (S/370 architecture).
Predominantly designed to be compatible with a subset of the
24-bit MVS interface, so that it can run programs as
RMODE 24, AMODE 24.
4. PDOS/380 - runs on Hercules/380 (S/380 architecture).
Predominantly designed to be compatible with a subset of the
MVS/380 interface, so that it can run programs as
AMODE 32 (not just 31), RMODE ANY.
PC:
1. PDOS/86 (aka PDOS16) - long-term goal is to be compatible with
MSDOS, and thus supports a subset of the 16-bit MSDOS API.
2. PDOS/386 (aka PDOS32) - designed to be a 32-bit version of MSDOS,
so API is similar to PDOS/86, except most values take a
32-bit integer that would otherwise normally be 16-bit. This
interface is not meant to be directly used, and is subject
to change. You should be using the Win32 API instead.
3. PD-Windows - similiar to how Windows 95 was built on top
of MSDOS, PD-Windows is designed to support Win32
applications, but built on top of 32-bit PDOS/386 instead of
16-bit MSDOS.
4. PDOS/x64 - runs under UEFI on an x86_64 processor.
Smartphone:
1. PDOS-generic runs on 32-bit ARM
For a version 1.0 to be created requires the following
enhancements:
1. PD-Windows should support the binutils compile chain
2. PDOS/380 and Hercules/380 should use the "separate
memory" proposal where Hercules/380 manages the ATL
memory.
MAINFRAME PURPOSE
-----------------
To provide an alternative platform to run MVS applications, that
can be expanded on as required. Also to experiment with different
techniques. Also in some ways it helps to simply test MVS
applications, as they get executed in a different environment.
PC PURPOSE
----------
The long term goal is to be a rival to both
Microsoft Windows (commercial) and React OS
(copyrighted freeware). It is hoped that this public
domain code can be picked up by some commercial
enterprises to produce commercial-quality
alternatives to the above. It is also hoped that
government research departments will take the
lead in updating the public domain base.
The package more accurately contains multiple,
mostly independent things:
1. BOS application programming interface, for
standardized access to the BIOS.
2. POS application programming interface, for
standardized access to MSDOS interrupts.
3. PDPCLIB, a C runtime library, for multiple
environments, e.g. MVS, MSDOS and any POS-compliant
operating system (e.g. MSDOS and PDOS are both
POS-compliant).
4. PDOS/86, an operating system which can be
considered a clone of MSDOS.
5. PDOS/386, a 32-bit operating system, which
can't be considered a clone of any existing
operating system (that I know of, anyway).
It shares similarities with MSDOS, except it
is 32-bit. It shares similarities with DOS
extenders, except the API is different, and
it doesn't require an OS for support. It shares
similarities with Unix (the executable format),
except it doesn't support the Posix API. So all
in all, it's a new operating system which thus
necessitates all applications to be recompiled,
although not necessarily rewritten. Note that
PDOS/386 is pure 32-bit. It doesn't have any
16-bit code in it, although it does call
16-bit BIOS functions by switching to real mode.
6. PD-Windows, a 32-bit operating system built
on top of PDOS/386, that is designed to run a
subset of 32-bit Windows applications so you
don't need to recompile. It is hoped that
Windows device drivers will also work on
PD-Windows one day, and that PD-Windows will
no longer be dependent on the 16-bit BIOS.
Note that PD-Windows and PDOS/386 ship as a
single product.
PC INSTALLING - TRADITIONAL
---------------------------
To get the 16-bit version on floppy disk, you need
to get hold of a program called "rawrite" from the
internet and then follow the instructions (from
rawrite) to get pdos16.img onto a 1.44 MB floppy disk.
pdos32.img will give you the 32-bit version. Both of
these files can be found in the "src" directory.
To install on hard disk, you need MSDOS (I tested
with version 5.0) to format a FAT-16 partition,
then edit the doinst.bat file, choose location of
executables you wish to use (use full path including
drive letter!), plus the drive you want to install
it on. PDOS will happily run from a logical
partition. You can't use Win98 or Freedos to do
this work, because the "sys" command produces an
incompatible boot sector. Although there is a
workaround for Freedos:
compb (after editing to switch to wasmr and tlink)
compbu
tcc sectread.c bos.c
tcc sectwrit.c bos.c
get xychop.c from OZPD at http://pdos.sourceforge.net
format d: /u
doinst
newboot (or newboota for floppies)
and to get a new MBR for a hard disk, go:
newmbr (after checking disk number)
PC INSTALLING - MODERN
----------------------
You can obtain a hard disk image in the form pdos.vhd.
You can mount this drive under Windows and copy extra
files onto it. Eject it, burn it to USB stick using
Win32 Disk Imager.
PC DEVELOPMENT ENVIRONMENT
--------------------------
I use the following bits of software.
MSDOS 5.0
Freedos
Turbo C++ 1.01 (for 16-bit C compiler)
https://web.archive.org/web/20060114221019/http://community.borland.com/article/images/21751/tcpp101.zip
Open Watcom 1.6 (for 16-bit wasmr assembler)
http://www.openwatcom.org
EMX 0.9d (which includes GCC 2.8.1) (for 32-bit C compiler and assembler):
http://hobbes.nmsu.edu/cgi-bin/h-browse?sh=1&dir=//pub/os2/dev/emx/v0.9d
Bochs 2.4.5
http://bochs.sourceforge.net/
Qemu 3.0.0
https://www.qemu.org/
I have a 900 MB C drive (FAT-16) under Bochs on which I do
development, and then install the newly-created executables
onto the D drive, then reboot using a slightly different Bochs
configuration to test PDOS.
raread/rawrite (unknown origin)
GCC 3.2.3 to do cross-compile from Windows:
https://sourceforge.net/projects/pdos/files/pdwdev/pdwdev-rel1.zip/download
refer to gccdos.txt for documentation
binutils 2.14a to do cross-assembly etc. from Windows:
https://sourceforge.net/projects/pdos/files/pdwdev/pdwdev-rel1.zip/download
dmake with -B option allows space instead of tabs in makefiles
https://github.com/mohawk2/dmake/releases
I use 4_12_2_2
other version of gcc to build Windows pdptest (makefile.w32)
jwasm to build winsupa.asm in pdptest (makefile.w32).
https://sourceforge.net/projects/jwasm/files/JWasm%20Windows%20binary/JWasm194cb.zip/download
Not used:
MASM 6.15:
http://msdn2.microsoft.com/en-us/vstudio/aa718349.aspx
https://web.archive.org/web/20070202015826/http://download.microsoft.com/download/vb60ent/update/6/w9x2kxp/en-us/vcpp5.exe
(go "vcpp5 /c" to extract and choose to install in any scratch
directory, then copy ml.exe and ml.err into your PATH,
and save MasmRef.doc as a reference)
Not used:
64-bit MASM from Visual Studio 2005:
https://www.microsoft.com/en-us/download/details.aspx?id=14477
6.1.6000.16384.10.WindowsSDK_Vista_Feb2007Update_rtm.DVD.Rel.iso
WinSDKCompiler-WinSDKCompiler_X64_VC8CppCrossCompiler-x86.0.cab
ren ml64_exe.DFB19EFA_5C47_43EC_95E0_F97ACB8E5B40 ml64.exe
HX DOS extender:
https://www.japheth.de/HX.html
PC RECOMPILING - TRADITIONAL
----------------------------
If you have the above software, you can just type "build"
and it will rebuild the two .img files used in the shipment,
except for kernel32.dll.
Note that you need to edit build.bat and put the proper
paths in before that will actually work.
The step by step guide is below...
To compile 16-bit version using Turbo C++ 1.01:
Go to pdpclib and type "compile"
Go to src and type "comp1" then "comp2" then "comp3".
Then "compw16"
To compile 32-bit version using EMX 0.9d and Turbo C++ 1.01:
Go to pdpclib and type "compp"
Go to src and type "comp4" then "comp5" then "comp6".
Then "compw32"
Run comp0 and then doinst (after editing it!!!)
to install either 16 or 32-bit version.
NOTE! Installing PDOS in this manner will use
the MSDOS boot sector rather than PDOS's one.
The MSDOS boot sector is potentially copyrighted
(but the funny thing is that if it is, even a
blank formatted disk is copyright!). Their boot
sector is better than PDOS's, but it's up to you
whether you use it or not.
The boot floppy (which uses PDOS's boot sector)
was created in the following manner:
format a floppy disk using MSDOS 5.0
run doinst using the 16-bit version
raread to get the floppy into a file, e.g. pdos16.img
compb (after editing to switch to wasmr and tlink)
compbu
bootupd pdos16.img pbootsec.com
rawrite pdos16.img back to floppy
To create kernel32.dll (so that you can run Win32
programs) you need to run "compk32" from a suitable
platform. You can also build the rest of PDOS/386
by using the comp4w (needs Watcom), comp5w and
comp6w (needs a cross-compiled GCC 3.2.3) and copy
the files across to the target platform.
To create the Windows version of pdptest you need to go:
pdmake -f makefile.msv
(and copy the msvcrt.dll to the target system too).
PC RECOMPILING - MODERN
-----------------------
You typically need to create a virtual hard disk (VHD)
under Windows, as MBR and FAT, and then use Freedos
under Bochs or whatever to delete the partition and
recreate it. The batch files below should be inspected
before executing them.
After obtaining the source for PDOS/386 go:
compsys (after editing to switch to the watcom version)
(to circumvent an presumed HX bug we need two steps)
pdmake -n -f makefile.wcd >temp.bat
temp
compimbr (after editing to switch to the watcom version)
XXXXX begin
cd src
compk32
cd ..\pdpclib
pdmake -f makefile.msv
pdmake -f makefile.pdw
cd ..\src
comp4w
comp5w
comp6w
XXXXX end
Transfer pload.com, pdos.exe, pcomm.exe, kernel32.dll,
msvcrt.dll (from pdpclib), sys.exe, instmbr.exe to Freedos,
format a drive (without /s, and I think you need /u),
doinst (don't worry about patchver error), instmbr.
For PDOS/86 you instead change the bit between XXXXX with:
cd pdpclib
pdmake -f makefile.wcd
cd ..\src
comp1w
comp2w
comp3w
and you don't need kernel32.dll and msvcrt.dll.
PC RECOMPILING - MODERN - MARK II
---------------------------------
The PDOS/386 distribution comes with a misc\master.bat
that contains the procedure now used to actually build.
PC RECOMPILING - INDUSTRY STANDARD TOOLS
----------------------------------------
You can build at least the basic system using standard
Visual C and MASM. Because there is a 16-bit component,
you need to use Visual C++ 1.52C or some level below to
do the 16-bit. Modern MASM still supports 16-bit OMF
output. The last version of MASM to still work under
MSDOS (6.11) also works. It is unknown how low you can
go. Anyway, since PDOS/86 is all 16-bit, here is the
procedure for building that using Microsoft tools:
cd pdpclib
pdmake -f makefile.msc
cd ..\src
pdmake -f makeio.vsc
pdmake -f makepdos.v86
pdmake -f makecomm.v86
And for PDOS/386, start with the 16-bit tools
cd pdpclib
pdmake -f makefile.msc
cd ..\src
pdmake -f makeio.vsc TARG=PDOS32
then switch to 32-bit tools (Visual Studio 2005 is known
to work)
cd pdpclib
pdmake -f makefile.vsp
cd ..\src
pdmake -f makepdos.vsc
pdmake -f makecomm.vsc
BOOTSTRAPPING
-------------
In order to recompile from source, you need an existing
C compiler capable of building an executable. This is then
used to build the "standard tools" used by PDOS. Those tools
can then be used to produce the PDOS executables, which should
be byte-exact. The only exception is pload.com (io.sys) which
needs to be built with either Open Watcom or Visual C++ (a
version capable of producing 16-bit executables), as we don't
yet have a compiler (capable of being built under PDOS/386
from source code) capable of producing 16-bit code.
There are makefiles available assuming you wish to go through
this process starting with Visual Studio 2005. Each executable
that is built should be put in some directory, e.g. c:\winpath,
that you have put in your PATH. The required source code is
all on the PDOS/386 disk, but you may obtain it from other
sources, ie Sourceforge and pdos.org. You will need to extract
the gcc source code from custom.zip in c:\misc. The procedure
(to be run under Windows) is:
cd \devel\ozpd\c
cl rm.c
copy rm.exe \winpath
cd \devel\pdos\pdmake
nmake -f makefile.vsc
copy pdmake.exe \winpath
cd \devel\gcc\gcc
pdmake -f makefile.vsc
copy gcc-new.exe \winpath\gccwin.exe
cd \devel\pdos\pdas
pdmake -f makefile.vsc
copy pdas.exe \winpath
cd \devel\pdos\pdld
pdmake -f makefile.vsc
copy pdld.exe \winpath
cd \devel\xar
pdmake -f makefile.vsc
copy xar.exe \winpath
cd \devel\as86
pdmake -f makefile.vsc
copy as86.exe \winpath
cd \devel\pdos\src
pdmake -f makek32.std
cd \devel\pdos\pdpclib
ren pdptest.c pdptest.bak
copy \devel\ozpd\c\rm.c pdptest.c
pdmake -f makefile.std
copy pdptest.exe \winpath\rm.exe
cd \devel\pdos\pdmake
del pdmake.exe
pdmake -f makefile.std
copy pdmake.exe \winpath
cd \devel\gcc\gcc
pdmake -f windows.mak
copy gcc-new.exe \winpath\gccwin.exe
cd \devel\pdos\pdcc
pdmake -f makefile.std
copy pdcc.exe \winpath
cd \devel\pdos\pdas
pdmake -f makefile.std
copy pdas.exe \winpath
cd \devel\pdos\pdld
pdmake -f makefile.std
copy pdld.exe \winpath
cd \devel\xar
pdmake -f makefile.std
copy xar.exe \winpath
cd \devel\as86
pdmake -f makefile.std
copy as86.exe \winpath
That actually completes the tools, but now we need
to verify everything.
cd \devel\pdos\src
pdmake -f makek32.std
cd \devel\pdos\pdpclib
pdmake -f makefile.std
fc /b \winpath\rm.exe pdptest.exe
del pdptest.c
ren pdptest.bak pdptest.c
cd \devel\pdos\pdmake
del pdmake.exe
pdmake -f makefile.std
fc /b \winpath\pdmake.exe pdmake.exe
cd \devel\gcc\gcc
pdmake -f windows.mak
fc /b \winpath\gccwin.exe gcc-new.exe
cd \devel\pdos\pdcc
pdmake -f makefile.std
fc /b \winpath\pdcc.exe pdcc.exe
cd \devel\pdos\pdas
pdmake -f makefile.std
fc /b \winpath\pdas.exe pdas.exe
cd \devel\pdos\pdld
pdmake -f makefile.std
fc /b \winpath\pdld.exe pdld.exe
cd \devel\xar
pdmake -f makefile.std
fc /b \winpath\xar.exe xar.exe
cd \devel\as86
pdmake -f makefile.std
fc /b \winpath\as86.exe as86.exe
And now that you have the tools you can compile
the individual elements of PDOS, ie:
cd \devel\pdos\src
comp4w
comp5w
comp6w
HISTORY
-------
Some years ago (circa 1988?) someone made a comment "until DOS is made
32-bit, DOS-extenders are just a kludge". I didn't understand the
comment at the time, and I'm still not sure what's classified as a
"kludge". A few years later (circa 1994?) I was in a job where I was
battling to try to get some DOS applications to run in 640k, moving
around device drivers, making use of the high memory area etc., all
very frustrating. On a machine with 32 meg of memory on it! I thought
it would make more sense to have DOS reside outside of real mode
memory, making more room for applications. Nothing had been done about
making DOS 32-bit. So, I decided to make my own 32-bit port of DOS.
But I don't like writing non-ISO C programs, so decided to start by
writing wrappers over all the DOS + BIOS functions. This was just one
of many projects I was working on so nothing much happened for years.
Then I bought a cheap ($80) second-hand computer for use in the bedroom,
and didn't have the energy to install anything other than DOS on it.
And there's not much I actually wanted to do with DOS. So I decided
to port another one of my projects (PDPCLIB) to DOS. After that was
done, the only other thing that I could do under DOS was write my own
DOS, so I proceeded to write a 16-bit version of DOS, but nice and
clean, i.e. don't use near/far pointers. With the intention that when
finished, all I needed to do was recompile under a 32-bit compiler and
voila!
The original point of contention was to free up real memory, but since
I am no longer in that position, the goal has instead changed to simply
producing a nice, clean 32-bit version of DOS, mainly for my own use
in writing my own ISO C programs. But that raises the question, what
does a 32-bit version of DOS actually look like? This is my interpretation
of that originally posed question "until DOS is made 32 bit". I figured
that you should be able to do things like write to location 0xb8000
without anyone complaining, but now you just addressed it as location
0xb8000! However, with the compiler that I was using (EMX 0.9b), the
a.out executable format didn't include fixups, it assumed that CS and
DS would be pointing to where the program was loaded! Rather than try
to change this, I just decided to provide an ABSADDR macro, so that you
can go "char *p = ABSADDR(0xb8000);" and then start writing directly to
screen memory. ABSADDR refers to an operating system provided variable
which is how many bytes need to be subtracted from an address in order
for it to be able to access that absolute memory location.
Since then I figured out how to make EMX produce an executable with
fixups, so ABSADDR was no longer required.
The next major breakthrough came when Alica Okano added support for
loading Windows PE executables, along with loading DLLs so that we
could start supporting a subset of Win32 programs.
VERSION HISTORY
---------------
On 1994-04-28 in the PUBLIC_DOMAIN Fidonet echo, the question
was asked what was required to replace MSDOS, and experimentation
began. By 1994-07-03 the POS/PDOS project was "formally" elaborated.
On 1994-07-12 focus was switched to the C runtime library (PDPCLIB)
to support it and to identify the high priority MSDOS interfaces
that would be required by PDOS. First beta of PDPCLIB was made
available on 1994-07-30.
0.00 Released 1994-12-29 consisting of just some BIOS interface
routines. Much more work was required on PDPCLIB before
coming back to do PDOS-type work.
0.10 Released 1997-05-18 together with PDPCLIB 0.51
0.20 Released 1997-05-24
0.30 Released 1997-09-04
0.40 Released 1997-09-13
0.50 Released 1997-12-18
0.60 Released 1997-12-28
0.70 Released 1998-01-05
0.71 Released 1998-01-11
0.82 Released 1998-09-12
0.83 Released 2001-06-02
0.85 Released 2002-07-26
0.86 Released 2007-08-23
0.90 Released 2019-10-01 now supports running some
Win32 applications.
PC POS INTERFACE
----------------
Instead of calling int 21h directly yourself (which will currently
still work), you should instead use the routines provided in header
file "pos.h", which is the official access to the OS, similar to
OS/2's "os2.h". For those who need to access the BIOS directly,
the routines are in "bos.h". As with normal DOS, you're not meant
to be accessing the BIOS directly, but there's nothing to stop you
anyway. You can access the hardware directly too, although you're
not meant to.
Here's an example of a BIOS routine, BosDiskSectorRead.
int BosDiskSectorRead(void *buffer,
unsigned int sectors,
unsigned int drive,
unsigned int track,
unsigned int head,
unsigned int sector);
This particular function is meant to be called instead of INT 13 function 2.
Now the first thing you should know is that because this is meant to be an
interface to INT 13 function 2, you should not expect to get more out of it
than INT 13 will give you. E.g. even though the sector number above is
given as an unsigned int, the interrupt has a limit of 255 for sector
number, so that's all you will get. The unsigned int is designed for
future expansion (i.e. where this interrupt is bypassed).
Potentially there will be multiple things that happen when you call
BosDiskSectorRead.
1. 16-bit program under 16-bit PDOS.
It simply calls the interrupt. This is designed for you to continue
writing DOS programs as you always have. Will even work on an XT.
Of course your parameters must be far pointers, which means they are
equally constrained to addresses in the first meg.
2. 32-bit programs under 16-bit PDOS.
All addresses are 32-bit. If your program is running under plain DOS,
the addresses will be translated to far pointers and the function will
be done. You do not need to make sure your addresses are in the lower
1 meg, the data will be buffered and converted accordingly.
3. 16-bit program under 32-bit PDOS.
It calls the interrupt, which is then intercepted, a switch made
to protected mode so that PDOS can handle it. PDOS may or may not
return to real mode to execute the original BIOS interrupt.
4. 32-bit program under 32-bit PDOS.
It calls the protected mode interrupt. PDOS may or may not return
to real mode to get the 16-bit version called, but IF it does, it
will translate all the 32-bit addresses, buffering them if required.
HANDS-ON USE
------------
To remain compatible with MSDOS 5's FORMAT, SYS + boot sector, the
operating system has been split up into the traditional 3 programs,
IO.SYS, MSDOS.SYS and COMMAND.COM, except they have been renamed to
PLOAD.COM, PDOS.EXE and PCOMM.EXE respectively. The mainframe
naming standard is quite similar, but is PLOAD.SYS, PDOS.SYS and
COMMAND.EXE. And since writing, on the PC MSDOS.SYS has been renamed to
PDOS.SYS and COMMAND.COM has been renamed to COMMAND.EXE, but IO.SYS
remains the same.
As far as possible, all code has been written in C, for portability
between 16 + 32 bit systems, plus portability to other CPUs. It is
even possible to compile the 16-bit version as an executable which
can then be debugged with Turbo Debugger etc. The goal has been
that as far as possible, all you need to do is recompile the code on
another machine and it instantly works.
PLOAD.COM is a COM program, that has startup code which assumes
the first 3 sectors are loaded. It then completely reloads PLOAD.COM
and PDOS.EXE, using the FAT-reading logic. It also has the logic to do
program relocation for use by PDOS.EXE. Also in the 32 bit version
it has the switch to/from protected mode facility.
PDOS.EXE is a large model EXE program (16-bit) or an a.out program
in 32-bit. It uses special startup code to ensure that it doesn't
attempt to access the non-existent PSP etc.
So far I have written cut-down versions of all three executables, so that
it boots (of floppy or hard disk, including logical partitions) and prints
"Welcome to pcomm" or similar, and then prompts for a command. Recognized
commands can be found by typing "help".
You can also launch other programs. The 16-bit version is very
wasteful of memory, so you can't do a lot with it. The focus is
on the 32-bit version. Also the program can't do any as-yet
unimplemented interrupts. However, it is sufficiently
implemented to run C90-compliant applications that have been
built using PDPCLIB.
PDOS currently (even in the 32-bit version) uses the BIOS to read from
disk and do screen I/O and keyboard input. This should hopefully make
it compatible with your existing hardware straight out of the box.
However, it is intended that as a non-default CONFIG.SYS option, you
can get PDOS to use internal device drivers.
MAINFRAME FILES
---------------
The "s370" directory contains the main files that comprise the
mainframe operating systems.
doit.bat - used to compile and everything
pload.c - standalone loader (PLOAD.SYS)
pdos.c - standalone operating system (PDOS.SYS)
pcomm.c - command processor (COMMAND.COM)
pdosutil.c - common utilities
pdossup.asm - assembler support routines for PDOS
ploadsup.asm - assembler support routines for PLOAD
world.c - example program
PC FILES
--------
pload.c - loader for PDOS (IO.SYS)
pdos.c - PDOS, the operating system (MSDOS.SYS)
pcomm.c - command processor (COMMAND.COM).
comp0.bat - used to compile PATCHVER.EXE (used by doinst)
comp1.bat - used to compile PLOAD.COM (IO.SYS)
comp2.bat - used to compile PDOS.EXE (MSDOS.SYS)
comp3.bat - used to compile PCOMM.EXE (COMMAND.COM)
comp4.bat - used to compile 32-bit-PDOS-supporting PLOAD.COM (IO.SYS)
comp5.bat - used to compile 32-bit version of PDOS.EXE (MSDOS.SYS)
comp6.bat - used to compile 32-bit version of PCOMM.EXE (COMMAND.COM)
compb.bat - used to compile boot sector
compbu.bat - used to compile program to update boot sector
compexe.bat - compiles PDOS + PCOMM into a single executable for debugging
doinst.bat - used to rename the 3 executables to the MSDOS-style names so
that the "sys" command can then be used to install them.
bos.* - bios functions
pos.* - dos functions
fat.* - fat access functions
pdpgoal.txt - not the license agreement
PC INTERNALS
------------
memory map:
4 gig
memory for protected mode applications (code & data)
200000
unused for 32-bit, presumably will hold 16-bit device drivers
110000
area of memory still addressable by 16-bit programs,
giving an extra 64k for any application that knows
how to do that. Unused by PDOS itself.
100000
used by i/o devices and bios on IBM PC, 640k limit
being created by the a0000 starting address.
a0000
space for application code
50000
64k completely wasted for memory chain control
blocks, to avoid having to drop the flat memory
model coding in the memory management class. (16-bit only)
40000
some unused space here, but the 16-bit MSDOS.SYS finishes
above 30000 since we started linking in the C library
30700 (approx.)
MSDOS.SYS data & stack (32-bit only), then below-the-line memory
20700
MSDOS.SYS
Note that the 32-bit a.out has a 0x20 byte header
so the actual code starts at 10720. For 16-bit,
the header is likely to be 0xc00 long, for a
code start of 11300.
10700
MSDOS.SYS psp
10600
IO.SYS stack (also used by 16-bit MSDOS.SYS)
07DFF
sector 0 & bpb
07C00
07BFF
IO.SYS
007FF
MBR + IO.SYS
00700
MBR
00600
00400
REAL MODE INTERRUPTS
00000
The BIOS loads sector 0 into locations 7C00 - 7DFF.
[if a hard disk, then it is actually the MBR that gets loaded
first, relocates itself to 0600-07FF, then loads sector 0 of
the active partition]
IO.SYS gets loaded between 0700 and 7BFF (58 sectors).
The stack is at 10600 and grows down.
MSDOS.SYS gets loaded starting at 10700.
On transition to protected mode, sp gets set to a value 0x8000
above the end of the module. When calling
other programs, the stack is changed and set to a larger amount. When
an interrupt is done, the previous stack is restored temporarily.
It is also restored when the program terminates. When doing a real
mode interrupt, ss & sp are temporarily set to what PLOAD was using.
The interrupt vectors for protected mode are provided as part of the
PLOAD executable - a length of 800 to give 256 8-byte interrupts.
For BIOS calls that require pointers, e.g. reading from disk sectors,
a translation is done so that the data is read to a location provided
by PLOAD and then transferred up.
Protected mode switching is done as follows:
runaout() runs an a.out executable, by doing the following:
load file
runprot()
runprot() runs a protected mode program by doing the following:
disabling interrupts
rawprot()
establishing protected-mode interrupts
reenabling interrupts
rawprot() does the actual protected mode switch and starts
executing code, blissfully unaware of what it is.
Note that that interface is designed to look clean, but in the case
of runprot(), the code's function is actually split between the
calling real-mode program and the protected-mode program. Earlier
on runaout was too, the relocation of the a.out executable being
done after the switch to protected mode and in the a.out code!
You would use rawprot() if you wanted to quickly execute some
protected mode code, say already in memory, and were happy for
interrupts to be disabled whilst it was being executed.
runprot() will establish interrupt handlers for long-running bits
of code.
runaout() is just one executable format that may be run.
The first bit of the pload executable must fit into 3 * 512 bytes,
as that is all the boot sector loads. When this was last measured,
2012-11-11, there were 542 bytes spare. 3*512 bytes corresponds to
a map reading of 0700h because of the org 0100h required for COM
files. There are 4 modules - ploadst, pload, int13x and near,
which are used to load the data beyond 3*512. And in "near", it is
only the first 3 functions that are actually called (by pload).
So in tlink you can change "-x" to "-m" to get a memory map, and
you look at the publics by value and then look for the __I4M which
is the first bit of unneeded code. Subtract 0100h from this value
to find out the amount of code in use. Then subtract that value
from 3*512 to find out how much space is still available.
When adding a new interrupt, you need to change handlers.asm,
pdos.c, protintp.c, protints.s, support.asm, support.s.
FUTURE DEVELOPMENT
------------------
PDOS/386 could actually execute 16-bit MSDOS
programs by dropping down to real mode and
executing until interrupt, then returning to
protected mode to execute that function.
But we'll probably just stick to running
Win32 programs and getting rid of dropping
down to 16-bit to use the BIOS altogether.
We'll need 32-bit device drivers to do that
though. Maybe Windows device drivers can
be used.
MSGED 4.00 and maybe later versions have support
for 80386 DOS programming. Look
at porting this and redefining PDOS/386 to match
this API.
It would be good to have a boot manager that runs
under PDOS/86 so that a PDOS boot floppy can be
flashed onto BIOS and allow the user to choose
what to boot. Note that the drive names are in
the boot sector of each partition, not in the MBR.
The Linux INT 80H calls could be supported by PDOS/386.
Along with ELF modules. To implement sbrk() PDPCLIB
needs to have MEMMGR defined and implement a ReSupply
function. PDOS needs to use memmgrRealloc(). However,
Linux only supports brk() as a syscall (sys_brk,
function 45 decimal) so it is not clear how that is
supposed to work. Also the way command line parameters
are pushed onto the stack in Unix is not very nice.
We'll probably just stick to Windows.
Use INT 15 AX=E820 to see how much memory is available.
http://www.ctyme.com/intr/rb-1741.htm
This has a problem in that protintp.c is only expecting
16-bit registers to be used in real mode, but this call
uses full 32-bit registers. A possible workaround would
be to pass the full 32-bit register values of
EAX/EBX/ECX/EDX down to the real mode interrupt.
New philosophy for PDOS:
Should be a poor man's Win 98 console mode.
Imagine someone has Windows/XP installed, but
something has gone wrong, Windows has stopped booting,
and thus they need a boot floppy to go and inspect the
hard disk, and copy some important files to a floppy.
Or maybe something has gone even more wrong than that,
and they need to write a small C program to repair some
damage and hopefully resurrect their system. Because of
space limitations, assume they have obtained PDOS, loaded
with 3rd party utilities, on a bootable CD instead.
Maybe they've even got a second hard disk, so after
booting off the CD, they go "sys d:" to install PDOS
onto that, and then change their BIOS to boot off
that disk, and hey presto, plenty of space and a
writable disk, great for recovery work.
So something that looks identical to DOS, but is in
fact 32-bit, and can handle Win-98 32-bit console
mode executables.
And 3rd party software, such as gcc, can be
optionally distributed on the disk, but if someone
needs something comprised of purely public domain
source code, that is available too, they can put
their own (proprietary) disk-repair utility on to
a PDOS disk.
Note:
1. Some utilities, such as "sys" are required.
2. microemacs for windows should work
3. Something as simple as DOS, not as complicated as Unix, is required.
The environment as described above can also be used
to develop Windows 32-bit console mode programs.
multitasking has been added to some extent
multiprocessing (using more than one CPU core)
graphical user interface
file handles should be separate for each process