http://tech.slashdot.org/article.pl?sid=08/09/07/1729255
I started this a few years ago to keep track of things I did using OS/2. Everything kind of fell to the wayside and I got bored. I think most blogs are like people yelling in the middle of nowhere with no one to listen and this one is no different. I have become un-bored for awhile and decided to play with Bogger again to keep track of nothing important.
07 September 2008
24 August 2008
More output...
I finally hooked up output from the detected serial port using a DosHelp routine, but it might short lived if I can't use it after relocation.
Guess the best part is that the IODelay matches what I see with a debug kernel on the same machine.
LDRINFO: Loader initialized and running ...
Serial out: COM1 Address 3F8 BPB 0X8800:0XB
FileTable 0X8800:0X124A Bootflags: 0X1481
LDR: 0X1000 microFSD: 0X8800 miniFSD: 0X7C endldr: 0X5000
COM: 0X3F8 0X0 0X0 0X0 LPT: 0X378 0X0 0X0
OS2LDR size: 19326 GenuineIntel Type: 0X6 Model: 0X8
IODelay: 244 T0: 0 T1: -2 T2: -263 A20 gate enabled INT15-C1 not supported
bus:dev:func 0:0:0 0:1:0 0:1E:0 0:1F:0 0:1F:1 0:1F:2 0:1F:3 0:1F:5
bus:dev:func 1:0:0* 1:0:1 bus:dev:func 2:3:0*
PCI BIOS 2.16 Number Bus: 3 Status: C00 :: EISA not found
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff06c0 (usable)
BIOS-e820: 000000003fff06c0 - 000000003fff66c0 (ACPI data)
BIOS-e820: 000000003fff66c0 - 000000003fffe700 (ACPI NVS)
BIOS-e820: 000000003fffe700 - 0000000040000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
LDRINFO: End message
Guess the best part is that the IODelay matches what I see with a debug kernel on the same machine.
LDRINFO: Loader initialized and running ...
Serial out: COM1 Address 3F8 BPB 0X8800:0XB
FileTable 0X8800:0X124A Bootflags: 0X1481
LDR: 0X1000 microFSD: 0X8800 miniFSD: 0X7C endldr: 0X5000
COM: 0X3F8 0X0 0X0 0X0 LPT: 0X378 0X0 0X0
OS2LDR size: 19326 GenuineIntel Type: 0X6 Model: 0X8
IODelay: 244 T0: 0 T1: -2 T2: -263 A20 gate enabled INT15-C1 not supported
bus:dev:func 0:0:0 0:1:0 0:1E:0 0:1F:0 0:1F:1 0:1F:2 0:1F:3 0:1F:5
bus:dev:func 1:0:0* 1:0:1 bus:dev:func 2:3:0*
PCI BIOS 2.16 Number Bus: 3 Status: C00 :: EISA not found
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff06c0 (usable)
BIOS-e820: 000000003fff06c0 - 000000003fff66c0 (ACPI data)
BIOS-e820: 000000003fff66c0 - 000000003fffe700 (ACPI NVS)
BIOS-e820: 000000003fffe700 - 0000000040000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
LDRINFO: End message
17 August 2008
DosHlp Routines
In brief, which is all I can do, the os2ldr contains some hardware dependent routines call DosHlp routines. Thanks to Pasha for pointing out that the ddk contains doshlp.inc which lists most of these (base\inc).
The os2ldr contains a table of offsets that is passed to the kernel. The following is a structure I put together from this information and what I saw from a disassembled os2ldr (SMP v104a). The unknowns are not listed in the doshlp.inc.
typedef struct _DOSHLPFUNCTIONS {
uint16_t TableVersion;
uint32_t DosHlpInit;
uint32_t DosHlpReboot;
uint32_t DosHlpNMI;
uint32_t DosHlpSizeMem;
uint32_t DosHlpConfig;
uint32_t DosHlpBaseDDList;
uint32_t DosHlpGetDriveParms;
uint32_t DosHlpInitSystemDump;
uint32_t DosHlpSystemDump;
uint32_t DosHlpReadSectors;
uint32_t DosHlpSerInit;
uint32_t DosHlpSetBaudRate;
uint32_t DosHlpSerIn;
uint32_t DosHlpSerOut;
uint32_t DosHlpToneOn;
uint32_t DosHlpToneOff;
uint32_t DosHlpGetMask;
uint32_t DosHlpSetMask;
uint32_t DosHlpSetRealMask;
uint32_t DosHlpSetProtMask;
uint32_t DosHlpSetDosEnv;
uint32_t DosHlpCallInt10;
uint32_t DosHlpProtGetMessage;
uint32_t DosHlpRealGetMessage;
uint32_t DosHlpRegisterTmrDD;
uint32_t DosHlpTmr16QueryTime;
uint32_t DosHlpEnableWatchdogNMI;
uint32_t DosHlpDisableWatchdogNMI;
uint32_t DosHlpInstallIRET;
uint32_t DosHlpDiscard;
uint32_t DosHlpInitInterrupts;
uint32_t DosHlpSetIRQMask;
uint32_t DosHlpSendEOI;
uint32_t DosHlpTmr32QueryTime;
uint32_t DosHlpTmrSetRollover;
uint32_t DosHlpInitNPX;
uint32_t DosHlpClrBusyNPX;
uint32_t DosHlpAckIntNPX;
uint32_t DosHlpWaitNPX;
uint32_t DosHlpValidNPXSwitch;
uint32_t DosHlpVNPXReset;
uint32_t DosHlpVNPXClrBusy;
uint32_t DosHlpWhyNMI;
uint32_t DosHlpAckNMI;
uint32_t DosHlpResetWatchdogNMI;
uint32_t DosHlpDisableCache;
uint32_t DosHlpFindParity;
uint32_t DosHlpEnableCache;
uint32_t DosHlpGetErrorLogPtr;
uint32_t DosHlpWriteErrorLog;
uint32_t DosHlpReadErrorLog;
uint32_t DosHlpResetParity;
uint32_t Unknown1;
uint32_t Unknown2;
uint32_t Unknown3;
uint32_t Unknown4;
uint32_t Unknown5;
uint32_t Unknown6;
uint32_t Unknown7;
uint32_t Unknown8;
uint32_t Unknown9;
uint32_t Unknown10;
uint32_t Unknown11;
} DOSHLPFUNCTIONS, *PDOSHLPFUNCTIONS;
The os2ldr contains a table of offsets that is passed to the kernel. The following is a structure I put together from this information and what I saw from a disassembled os2ldr (SMP v104a). The unknowns are not listed in the doshlp.inc.
typedef struct _DOSHLPFUNCTIONS {
uint16_t TableVersion;
uint32_t DosHlpInit;
uint32_t DosHlpReboot;
uint32_t DosHlpNMI;
uint32_t DosHlpSizeMem;
uint32_t DosHlpConfig;
uint32_t DosHlpBaseDDList;
uint32_t DosHlpGetDriveParms;
uint32_t DosHlpInitSystemDump;
uint32_t DosHlpSystemDump;
uint32_t DosHlpReadSectors;
uint32_t DosHlpSerInit;
uint32_t DosHlpSetBaudRate;
uint32_t DosHlpSerIn;
uint32_t DosHlpSerOut;
uint32_t DosHlpToneOn;
uint32_t DosHlpToneOff;
uint32_t DosHlpGetMask;
uint32_t DosHlpSetMask;
uint32_t DosHlpSetRealMask;
uint32_t DosHlpSetProtMask;
uint32_t DosHlpSetDosEnv;
uint32_t DosHlpCallInt10;
uint32_t DosHlpProtGetMessage;
uint32_t DosHlpRealGetMessage;
uint32_t DosHlpRegisterTmrDD;
uint32_t DosHlpTmr16QueryTime;
uint32_t DosHlpEnableWatchdogNMI;
uint32_t DosHlpDisableWatchdogNMI;
uint32_t DosHlpInstallIRET;
uint32_t DosHlpDiscard;
uint32_t DosHlpInitInterrupts;
uint32_t DosHlpSetIRQMask;
uint32_t DosHlpSendEOI;
uint32_t DosHlpTmr32QueryTime;
uint32_t DosHlpTmrSetRollover;
uint32_t DosHlpInitNPX;
uint32_t DosHlpClrBusyNPX;
uint32_t DosHlpAckIntNPX;
uint32_t DosHlpWaitNPX;
uint32_t DosHlpValidNPXSwitch;
uint32_t DosHlpVNPXReset;
uint32_t DosHlpVNPXClrBusy;
uint32_t DosHlpWhyNMI;
uint32_t DosHlpAckNMI;
uint32_t DosHlpResetWatchdogNMI;
uint32_t DosHlpDisableCache;
uint32_t DosHlpFindParity;
uint32_t DosHlpEnableCache;
uint32_t DosHlpGetErrorLogPtr;
uint32_t DosHlpWriteErrorLog;
uint32_t DosHlpReadErrorLog;
uint32_t DosHlpResetParity;
uint32_t Unknown1;
uint32_t Unknown2;
uint32_t Unknown3;
uint32_t Unknown4;
uint32_t Unknown5;
uint32_t Unknown6;
uint32_t Unknown7;
uint32_t Unknown8;
uint32_t Unknown9;
uint32_t Unknown10;
uint32_t Unknown11;
} DOSHLPFUNCTIONS, *PDOSHLPFUNCTIONS;
27 July 2008
Another utility...
First, good post The Top 50 Proprietary Programs that Drive You Crazy - and Their Open Source Alternatives.
Next, I finished a utility to compile message files, a mkmsgf clone. I uploaded the first version to hobbes. Dose not do DBCS, but I do not need it any way.
Next, I finished a utility to compile message files, a mkmsgf clone. I uploaded the first version to hobbes. Dose not do DBCS, but I do not need it any way.
15 July 2008
osFree...
I have joined the osFree Project at Sourceforge and will keep a mirror of my loader project there.
In the process of hooking in the freeLdr micro-FSD calls, I found a real pain in the ass with BootableJFS. Each call to open clears the screen and displays their copyright message. This messes up any messages anyone else wants to display...
The fix? Well in the newest BootableJFS (as of 2008) Pasha has a turn off. At the JFS uFSD segment and offset 0x1944 a check is made for the byte value 0x0F. If this is set to anything else the message is not displayed.
In the process of hooking in the freeLdr micro-FSD calls, I found a real pain in the ass with BootableJFS. Each call to open clears the screen and displays their copyright message. This messes up any messages anyone else wants to display...
The fix? Well in the newest BootableJFS (as of 2008) Pasha has a turn off. At the JFS uFSD segment and offset 0x1944 a check is made for the byte value 0x0F. If this is set to anything else the message is not displayed.
12 July 2008
02 July 2008
Waste of more time...
Simple? Sure, but better than nothing. Screen capture booting with a Virtual PC drive formated with Bootable JFS:
Big hang up is that the IODelay isn't coming up constant.
29 June 2008
My os2ldr project
I have had sometime to play and committed the results to the SVN page:
http://www.assembla.com/wiki/show/os2ldr
http://www.assembla.com/wiki/show/os2ldr
15 June 2008
Multiboot PC for FreeDOS, Linux and eComStation
We at ERACC installed FreeDOS and eComStation for the end-user. We offered to install the Linux as well but the end-user wanted to install the openSuSE 10.3 Linux himself. There is space set aside on the 147GB SCSI hard drive for him to install a /boot near the start of the drive and the rest of openSuSE 10.3 after the eComStation partitions.
read more | digg story
read more | digg story
07 June 2008
More stuff
Steven's page listing OS/2 Diagnostic Tools and Tips.
26 May 2008
JFS BIOS-parameter-block
I think I have the JFS BIOS-parameter-block complete and making sense.
A bit late but a fair article: eComStation: Not for Everyone
also: multiboot-pc-for-freedos-linux-and-ecomstation
Also, non-related, the Phoenix landing yesterday
A bit late but a fair article: eComStation: Not for Everyone
also: multiboot-pc-for-freedos-linux-and-ecomstation
Also, non-related, the Phoenix landing yesterday
22 May 2008
Entry into os2ldr
Using Bochs I have the entry values into os2ldr when booted with BootJFS. One important note is that any of the filetable structure len fields will depend on the module version. Also, the 0x8800 segment might vary with machine types in the real world. It is calculated:
DH boot mode flags == mini-FSD is present, micro-FSD is present
DL drive number for the boot disk == 0x80
DS:SI is a pointer to the BOOT Media's BPB 8800:000B (0x8800B)
ES:DI pointer to a filetable structure 8800:124A (0x8924A), filetable structure has the following format:
; module locations
8924A ft_cfiles dw 3
8924C ft_ldrseg dw 0x1000
8924E ft_ldrlen dd 0x0000AE00
89252 ft_museg dw 0x8800
89254 ft_mulen dd 0x00005000
89258 ft_mfsseg dw 0x7C00
8925A ft_mfslen dd 0x0000EAE9
8925E ft_ripseg dw 0
89260 ft_riplen dd 0
; microFSD vector table
89264 ft_muOpen_OFF dw 0x1A9C
89266 ft_muOpen_SEG dw 0x8800
89268 ft_muRead_OFF dw 0x1BD4
8926A ft_muRead_SEG dw 0x8800
8926C ft_muClose_OFF dw 0x1DAE
8926E ft_muClose_SEG dw 0x8800
89270 ft_muTerminate_OFF dw 0x1DD4
89272 ft_muTerminate_SEG dw 0x8800
- uses INT 12 to find the top of low memory in continuous 1k blocks
- subtract 0x54
- AND with 0xFFF0
- Shift left 6
DH boot mode flags == mini-FSD is present, micro-FSD is present
DL drive number for the boot disk == 0x80
DS:SI is a pointer to the BOOT Media's BPB 8800:000B (0x8800B)
ES:DI pointer to a filetable structure 8800:124A (0x8924A), filetable structure has the following format:
; module locations
8924A ft_cfiles dw 3
8924C ft_ldrseg dw 0x1000
8924E ft_ldrlen dd 0x0000AE00
89252 ft_museg dw 0x8800
89254 ft_mulen dd 0x00005000
89258 ft_mfsseg dw 0x7C00
8925A ft_mfslen dd 0x0000EAE9
8925E ft_ripseg dw 0
89260 ft_riplen dd 0
; microFSD vector table
89264 ft_muOpen_OFF dw 0x1A9C
89266 ft_muOpen_SEG dw 0x8800
89268 ft_muRead_OFF dw 0x1BD4
8926A ft_muRead_SEG dw 0x8800
8926C ft_muClose_OFF dw 0x1DAE
8926E ft_muClose_SEG dw 0x8800
89270 ft_muTerminate_OFF dw 0x1DD4
89272 ft_muTerminate_SEG dw 0x8800
18 May 2008
ah... BootJFS and the process
I’m going to plagiarize from www.osfree.org and modify the text to fit my adventures with BootJFS.
At the end of POST procedure the ROM BIOS initializes devices and gives control to int 19h interrupt routine, which loads 1st sector of the 1st boot device (a floopy, HDD or another). If the device was the HDD, then the Master boot record (MBR) is loaded from the 1st sector. The ROM BIOS loads it at address 07C0:0000. The MBR has a Non-System Bootstrap (NSB) routine in it, and the Partition Table (PT). The NSB code relocates MBR to 07E0:0000, jumps to 07E0:0020 and checks for a Boot Manager partition, and checks for a bootable partition on the first or second disk if present. Next the bootsector of boot HDD partition is loaded at 07C0:0000.
One of the interesting things that happens is the following:
1. Find the top continuous low memory (conventional 640k), number of 1K blocks. On my Bochs drive 639 is returned.
2. Calculate a load segment. The result of #1 – 54h, AND result with FFF0h, and then shifted left 6 bits. This will be the load segment and with the Bochs drive equates to 8800.
3. The bootsector of boot HDD plus an additional 31 sectors are loaded at the address (segment) calculated in #2, approximately 16K.
4. A jump to the segment from #2 offset 199Ch is made.
Now things have and continue to divert from IBM documentation. The code loaded in #3 contains MicroFSD. It loads os2boot and os2ldr using MicroFSD functions, which look like C code. Finally, the structure and registers are setup for entry into os2ldr.
One of my issues is that the structure I am finding does not seem to match documentation:
124A ft_cfiles dw 0
124C ft_ldrseg dw 0
124E ft_ldrlen dd 0
1252 ft_museg dw 0
1254 ft_mulen dd 0
1258 ft_mfsseg dw 0
125A ft_mfslen dd 0
125E ft_ripseg dw 0
1260 ft_riplen dw 0
1262 db 0
1263 db 0
; microFSD vector table
12641264 ft_muOpen_OFF dw 0
1266 ft_muOpen_SEG dw 0
1268 ft_muRead_OFF dw 0
126A ft_muRead_SEG dw 0
126C ft_muClose_OFF dw 0
126E ft_muClose_SEG dw 0
1270 ft_muTerminate_OFF dw 0
1272 ft_muTerminate_SEG dw 0
Notice 1262h and 1263h, I do not know what they are used for...
At the end of POST procedure the ROM BIOS initializes devices and gives control to int 19h interrupt routine, which loads 1st sector of the 1st boot device (a floopy, HDD or another). If the device was the HDD, then the Master boot record (MBR) is loaded from the 1st sector. The ROM BIOS loads it at address 07C0:0000. The MBR has a Non-System Bootstrap (NSB) routine in it, and the Partition Table (PT). The NSB code relocates MBR to 07E0:0000, jumps to 07E0:0020 and checks for a Boot Manager partition, and checks for a bootable partition on the first or second disk if present. Next the bootsector of boot HDD partition is loaded at 07C0:0000.
One of the interesting things that happens is the following:
1. Find the top continuous low memory (conventional 640k), number of 1K blocks. On my Bochs drive 639 is returned.
2. Calculate a load segment. The result of #1 – 54h, AND result with FFF0h, and then shifted left 6 bits. This will be the load segment and with the Bochs drive equates to 8800.
3. The bootsector of boot HDD plus an additional 31 sectors are loaded at the address (segment) calculated in #2, approximately 16K.
4. A jump to the segment from #2 offset 199Ch is made.
Now things have and continue to divert from IBM documentation. The code loaded in #3 contains MicroFSD. It loads os2boot and os2ldr using MicroFSD functions, which look like C code. Finally, the structure and registers are setup for entry into os2ldr.
One of my issues is that the structure I am finding does not seem to match documentation:
124A ft_cfiles dw 0
124C ft_ldrseg dw 0
124E ft_ldrlen dd 0
1252 ft_museg dw 0
1254 ft_mulen dd 0
1258 ft_mfsseg dw 0
125A ft_mfslen dd 0
125E ft_ripseg dw 0
1260 ft_riplen dw 0
1262 db 0
1263 db 0
; microFSD vector table
12641264 ft_muOpen_OFF dw 0
1266 ft_muOpen_SEG dw 0
1268 ft_muRead_OFF dw 0
126A ft_muRead_SEG dw 0
126C ft_muClose_OFF dw 0
126E ft_muClose_SEG dw 0
1270 ft_muTerminate_OFF dw 0
1272 ft_muTerminate_SEG dw 0
Notice 1262h and 1263h, I do not know what they are used for...
17 May 2008
Killing time...
Doing as little as possible. Have started a new project - taking things apart.
http://www.mgreene.org/wikka/BootableJFS
http://www.mgreene.org/wikka/BootableJFS
02 April 2008
OS/2 GIT? Is GIT better than Subversion
Hey! I am no expert, but now I go to get some source and I find that the version control is GIT. What the hell is GIT? Here's a couple links that I read to try and understand this stuff:
http://git.or.cz/gitwiki/GitSvnComparsion
http://issaris.blogspot.com/2006/10/why-git.html
Here's my take on it. I wanted to get the current NASM source to compile on OS/2-eCS and found out it uses a GIT repository. Ok, great there is no GIT port for me to use. What is the purpose of using a versioning system that not everyone has for a cross-platform project? MS-Linux.
Might as well just make this a rant post. I think the fact Pasha has provided a ACPI solution for OS/2-eCS even though it is not open source. However, I am sick and tired of providing feedback to get something fixed, have it work in the next version, and then a version after it find it doesn't work again. What's worse is it looks like regression.
http://git.or.cz/gitwiki/GitSvnComparsion
http://issaris.blogspot.com/2006/10/why-git.html
Here's my take on it. I wanted to get the current NASM source to compile on OS/2-eCS and found out it uses a GIT repository. Ok, great there is no GIT port for me to use. What is the purpose of using a versioning system that not everyone has for a cross-platform project? MS-Linux.
Might as well just make this a rant post. I think the fact Pasha has provided a ACPI solution for OS/2-eCS even though it is not open source. However, I am sick and tired of providing feedback to get something fixed, have it work in the next version, and then a version after it find it doesn't work again. What's worse is it looks like regression.
22 March 2008
Easy gcc build environment
Open Office for eCS-OS/2 2.4 Beta1 is available (news post) and I installed it on my old SMP PIII box. Seems to work well! I guess the big milestone was just getting it going in the previous version.
Also, Pasha has his updated os2ldr on hobbes (here). No chance to try it yet, but I wish it was open source. Guess that is up to ecomstation.ru.
I am in the process of rebuilding my sandbox system and I reached the point where I setup the gcc environment. The easiest way to do this, especially since I rarely use gcc, is to use Paul Smedley's build environment, currently buildenv_20071022.zip and a size of 234,635,207 bytes.
I know Paul has it on his U: drive and that the setup could be changed to use another drive, but I don't want to invest the time. So, I created a U: drive during the system setup.
First thing to do was to unzip the file. A quick dir /s gave me the unarchived space required:
686,439,038 bytes in 26,738 files and 8,057 dirs
So, plan ahead because the zip file contains gcc, qt, perl, and all kinds of other libraries and executables.
First thing was to cd into extras\lib and run makeomflibs, as instructed on Paul's site. I got this at the end but I believe it is expected:
warning: one or more operations failed, check the above output. :-).
Also, if you look in gcc335.cmd there are a bunch of e:\python25 statements, but python is not in the zip archive. I just grabbed Paul's Python v2.5.1 for OS/2 & eComStation. I just did:
unzip python-2.5.1-os2-20071223.zip
and changed the references in gcc335.cmd from e: to u:.
With that done I gave it an easy test, compiling nasm-2.02. I first ran sh ./configure
and after it finished make. The problem I ran into is that Paul's gcc335.cmd defines tmp to u:\tmp which did not exist:
'set tmp=u:/tmp'
'SET TEMP=%TMP%'
'SET TMPDIR=%TMP%'
I thought it was a good idea to keep the tmp drive on u: for my gcc stuff so a quick md \tmp and I was off to run make again. The result was an complete nasm.exe build so I was happy.
Things to note: Paul has a newer version of perl on his site and I think qt has been updated, but I have yet to download them. There may even be an updated gcc package on netlabs by now.
Anyway, that's it - short and sweet. Thanks to both Knut and Paul.
Other stuff:
100,000 customers tell Microsoft to save XP
Also, Pasha has his updated os2ldr on hobbes (here). No chance to try it yet, but I wish it was open source. Guess that is up to ecomstation.ru.
I am in the process of rebuilding my sandbox system and I reached the point where I setup the gcc environment. The easiest way to do this, especially since I rarely use gcc, is to use Paul Smedley's build environment, currently buildenv_20071022.zip and a size of 234,635,207 bytes.
I know Paul has it on his U: drive and that the setup could be changed to use another drive, but I don't want to invest the time. So, I created a U: drive during the system setup.
First thing to do was to unzip the file. A quick dir /s gave me the unarchived space required:
686,439,038 bytes in 26,738 files and 8,057 dirs
So, plan ahead because the zip file contains gcc, qt, perl, and all kinds of other libraries and executables.
First thing was to cd into extras\lib and run makeomflibs, as instructed on Paul's site. I got this at the end but I believe it is expected:
warning: one or more operations failed, check the above output. :-).
Also, if you look in gcc335.cmd there are a bunch of e:\python25 statements, but python is not in the zip archive. I just grabbed Paul's Python v2.5.1 for OS/2 & eComStation. I just did:
unzip python-2.5.1-os2-20071223.zip
and changed the references in gcc335.cmd from e: to u:.
With that done I gave it an easy test, compiling nasm-2.02. I first ran sh ./configure
and after it finished make. The problem I ran into is that Paul's gcc335.cmd defines tmp to u:\tmp which did not exist:
'set tmp=u:/tmp'
'SET TEMP=%TMP%'
'SET TMPDIR=%TMP%'
I thought it was a good idea to keep the tmp drive on u: for my gcc stuff so a quick md \tmp and I was off to run make again. The result was an complete nasm.exe build so I was happy.
Things to note: Paul has a newer version of perl on his site and I think qt has been updated, but I have yet to download them. There may even be an updated gcc package on netlabs by now.
Anyway, that's it - short and sweet. Thanks to both Knut and Paul.
Other stuff:
100,000 customers tell Microsoft to save XP
20 March 2008
slow..
Some funny Aussie anti-MS rant - http://forums.mactalk.com.au/28/46290-why-i-hate-microsoft.html
A svn page - http://www.mgreene.org/wikka/MySvnSites
A svn page - http://www.mgreene.org/wikka/MySvnSites
10 March 2008
Subversion hosting - free
I decided to try the free hosting provided by assembla. The first project I committed is rexxutil located here:
WIKI: http://www.assembla.com/wiki/show/rexxutil
TRAC: http://trac2.assembla.com/rexxutil
SVN: http://svn2.assembla.com/svn/rexxutil
Some misc blogs with recent OS/2-eCS content:
WIKI: http://www.assembla.com/wiki/show/rexxutil
TRAC: http://trac2.assembla.com/rexxutil
SVN: http://svn2.assembla.com/svn/rexxutil
Some misc blogs with recent OS/2-eCS content:
08 March 2008
More stuff...
I uploaded a fixed and working version of rexxutil.dll to hobbes.
Here's a free svn hosting site with trac, it looks like they give you 500 megs free:
http://www.assembla.com
Here's a free svn hosting site with trac, it looks like they give you 500 megs free:
http://www.assembla.com
16 February 2008
Big gap...
On top of being busy with work, home remodeling, and classes I finally got my pages moved to new hosting. The previous hosting service, Namesecure, might be a poster child for piss-poor support if they add anything that could pass for support. It took over a week to get a reply from them. Good riddance!
I did play on occasion with the rexxutil.dll and managed to screw-up sysstemsort which I need to fix. I also worked some on uniaud32 build system.
Gregg Young sent me his FTE source with changes which I want to look at soon. I do have a version I patched in UClip for fun.
First on the agenda is to finish my eCS RC4 install on the ZPro. I finally got tired of the ridiculous large file size crap that pops up on some installs. I firmly believe it is caused by the toolkit install.
During the install, again I was plagued by an ACPI version that would not work, but getting the debug info to Pasha fixed the problem. Version 3.07 should contain the fix. I still can't get APIC but that is no big deal.
On the whole this is interesting, Sun buying Innotek. Wonder if they will have to box up Bird and send hime to Sun?
Should IBM's SOM/DSOM Be Open Sourced? This seems to be a better option than IBM releasing OS/2 code which will never happen. It must have hit a nerve, it caught the fakesteve's eye The Secret Diary of Steve Jobs.
Article chain:
I did play on occasion with the rexxutil.dll and managed to screw-up sysstemsort which I need to fix. I also worked some on uniaud32 build system.
Gregg Young sent me his FTE source with changes which I want to look at soon. I do have a version I patched in UClip for fun.
First on the agenda is to finish my eCS RC4 install on the ZPro. I finally got tired of the ridiculous large file size crap that pops up on some installs. I firmly believe it is caused by the toolkit install.
During the install, again I was plagued by an ACPI version that would not work, but getting the debug info to Pasha fixed the problem. Version 3.07 should contain the fix. I still can't get APIC but that is no big deal.
On the whole this is interesting, Sun buying Innotek. Wonder if they will have to box up Bird
Should IBM's SOM/DSOM Be Open Sourced? This seems to be a better option than IBM releasing OS/2 code which will never happen. It must have hit a nerve, it caught the fakesteve's eye The Secret Diary of Steve Jobs.
Article chain:
Subscribe to:
Posts (Atom)