I also put the 4os2 source into my svn site to make to easier to grab. It is version 3.05A and includes all changes up to 31 May 2009 change number 34617. All the changes entered can be viewed here. The svn source can be viewed or pulled from: http://svn.assembla.com/svn/os2utils/4os2/.
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.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
13 June 2009
pmvnc and 4os2
Finally got Dmitry Steklenev's changes inserted into pmvnc and uploaded to hobbes today. The source is at svn.assembla.com.
I also put the 4os2 source into my svn site to make to easier to grab. It is version 3.05A and includes all changes up to 31 May 2009 change number 34617. All the changes entered can be viewed here. The svn source can be viewed or pulled from: http://svn.assembla.com/svn/os2utils/4os2/.
I also put the 4os2 source into my svn site to make to easier to grab. It is version 3.05A and includes all changes up to 31 May 2009 change number 34617. All the changes entered can be viewed here. The svn source can be viewed or pulled from: http://svn.assembla.com/svn/os2utils/4os2/.
15 April 2009
pmvnc
I had a little spare time and, lucky me; I get an email about patches to PMVNC. Eugene ported this years ago and all I did was add a couple fixes – I hate the POS. But Dmitry sent the patches, so I’ll pull it up and see what is what. Hell, maybe I should put the fixes in that GG has been pissing about for a year…
> 1. After an upgrade to the SMP computer I have many problems with the image of the remote desktop. As I understand, this is thread related problem. Two PMVNC thread try to access to the hpsBitmap simultaneously. I have serialized access via mutex in rect32.c, rect4.c and rect8.c modules. Now all works well.
I never saw this on my SMP systems but sounds good.
> 2. During testing, if I have used "Tiny Color" and "Gray Scale" modes, I have received SYS3175 crash in PMMERGE.DLL. I have replaced in rect4.c:
pbmiBitmap = malloc(16 + sizeof(RGB2) * 16) ;
to
pbmiBitmap = malloc(16 + sizeof(RGB2) * 256) ;
And now this works well also.
Never did this either… again sounds good.
> 3. Missed comma after ID_PMVNC in IDD_ABOUT resource template.
Hmmm…. Ok. I guess I should fix and try to use wrc rather than rc just to find if it works.
> 1. After an upgrade to the SMP computer I have many problems with the image of the remote desktop. As I understand, this is thread related problem. Two PMVNC thread try to access to the hpsBitmap simultaneously. I have serialized access via mutex in rect32.c, rect4.c and rect8.c modules. Now all works well.
I never saw this on my SMP systems but sounds good.
> 2. During testing, if I have used "Tiny Color" and "Gray Scale" modes, I have received SYS3175 crash in PMMERGE.DLL. I have replaced in rect4.c:
pbmiBitmap = malloc(16 + sizeof(RGB2) * 16) ;
to
pbmiBitmap = malloc(16 + sizeof(RGB2) * 256) ;
And now this works well also.
Never did this either… again sounds good.
> 3. Missed comma after ID_PMVNC in IDD_ABOUT resource template.
Hmmm…. Ok. I guess I should fix and try to use wrc rather than rc just to find if it works.
07 March 2009
OS/2 Zip 3.0 and Unzip 6.0f
I got a version of zip 3.0 and unzip 6.0f compiled with Open Watcom 1.8 for OS/2. Supports bzip compression and files > 2 gig.
http://www.mgreene.org/pub/ziptest.zip
A readable page of compiled in options is located here: http://www.mgreene.org/wikka/ZipInfo
http://www.mgreene.org/pub/ziptest.zip
A readable page of compiled in options is located here: http://www.mgreene.org/wikka/ZipInfo
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.
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
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
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
09 September 2007
Couple good links
Since I bricked the NAS, I have been killing some time on ASM again.
Couple good links:
Removing the Mystery from SEGMENT : OFFSET Addressing
Assembly Tutorial
Couple good links:
Removing the Mystery from SEGMENT : OFFSET Addressing
Assembly Tutorial
24 August 2007
Storm...
Lucky me! While I was out of town Tuesday night we had the mother of all storms. It didn't whack me through the power cords, but rather through a hub. My 8 port hub was fried and every network item attached to it was trashed. This includes the network card on my old server, the network connection on the old MPro, a 5 port hub, and (Damn it!) the network connection on the xbox 360. So, I have been recovering the last couple days.
But, on the bright side Brendan released uniaud rc3. This comes after a lot of work and testing by Allan, Andy, Steven and others. My build system for uniaud16 was committed using all Open Watcom tools. But all the credit goes to Brendan who picked up this project.
Last, Open Watcom 1.7 has been released! In a world of gcc, Open Watcom is a breath of fresh air...
But, on the bright side Brendan released uniaud rc3. This comes after a lot of work and testing by Allan, Andy, Steven and others. My build system for uniaud16 was committed using all Open Watcom tools. But all the credit goes to Brendan who picked up this project.
Last, Open Watcom 1.7 has been released! In a world of gcc, Open Watcom is a breath of fresh air...
18 July 2007
Better late than never...
Knut released gcc 3.3.5 csd3 12 June 2007 ftp://ftp.netlabs.org/pub/libc/
Open Watcom v1.7, RC1 is now available July 10, 2007 ftp://ftp.openwatcom.org/devel/
Also, made some progress on a Hello World device driver
Open Watcom v1.7, RC1 is now available July 10, 2007 ftp://ftp.openwatcom.org/devel/
Also, made some progress on a Hello World device driver
Subscribe to:
Posts (Atom)
