info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OS/2 Compiling?
41 views
Skip to first unread message
baden.ku...@gmail.com
Jun 22, 2020, 4:06:20 PM6/22/20
to
As I know very little about this, I am inquiring about cross compiling applications for OS/2.
For instance, I believe with 'Watcom C', I can develop and compile code for DOS 8, 16 or 32 bit, OS/2 16 or 32 bit, and Win 16 or 32 bit, all from OS/2. I am unsure what Win graphical code can be compiled from OS/2. I assume that from Win 32, all the equivalent code could also be developed and compiled for all the platforms. I also assume that from DOS, some code (VIO?) could be developed and compiled, including OS/2. Would that include any PM?
I am unsure whether the application code word size (8,16 or 32 bit) is dependant on the development platform. For instance, would Watcom on OS/2 1.3 only develop and compile OS/2 16 bit VIO and PM applications, 8 or 16 bit DOS, and Win 16 applications? Or, could OS/2 1.2 and Win 3.1 support 32 bit development?
Would Watcom on DOS 32 support OS/2 32 bit development, both VIO and PM? Would Watcom on Win 64 support OS/2 32 bit PM development? Would Watcom on Linux 64 support OS/2 PM development?
Branching from Watcom, what is the corresponding situation with GCC? Can a GCC IDE on a 32 bit machine develop and compile graphical code for all the supported 32 bit platforms? Would GCC on Win 64 or Linux 64 support OS/2 PM development?
If a developer had a high end 64 bit workstation (Win or Linux), could he use Watcom or GCC to develop and compile OS/2 PM applications. If he used the compiler natively under a OS/2 VM, would it help or hinder development?
Let's presume a 64 bit machine used Watcom C or GCC to develop OS/2 PM, and used an OS/2 VM to test the application. Would this be feasible or practicable?
thanks for your input,
Baden
For instance, I believe with 'Watcom C', I can develop and compile code for DOS 8, 16 or 32 bit, OS/2 16 or 32 bit, and Win 16 or 32 bit, all from OS/2. I am unsure what Win graphical code can be compiled from OS/2. I assume that from Win 32, all the equivalent code could also be developed and compiled for all the platforms. I also assume that from DOS, some code (VIO?) could be developed and compiled, including OS/2. Would that include any PM?
I am unsure whether the application code word size (8,16 or 32 bit) is dependant on the development platform. For instance, would Watcom on OS/2 1.3 only develop and compile OS/2 16 bit VIO and PM applications, 8 or 16 bit DOS, and Win 16 applications? Or, could OS/2 1.2 and Win 3.1 support 32 bit development?
Would Watcom on DOS 32 support OS/2 32 bit development, both VIO and PM? Would Watcom on Win 64 support OS/2 32 bit PM development? Would Watcom on Linux 64 support OS/2 PM development?
Branching from Watcom, what is the corresponding situation with GCC? Can a GCC IDE on a 32 bit machine develop and compile graphical code for all the supported 32 bit platforms? Would GCC on Win 64 or Linux 64 support OS/2 PM development?
If a developer had a high end 64 bit workstation (Win or Linux), could he use Watcom or GCC to develop and compile OS/2 PM applications. If he used the compiler natively under a OS/2 VM, would it help or hinder development?
Let's presume a 64 bit machine used Watcom C or GCC to develop OS/2 PM, and used an OS/2 VM to test the application. Would this be feasible or practicable?
thanks for your input,
Baden
Dave Yeo
Jun 22, 2020, 11:45:52 PM6/22/20
to
On 06/22/20 01:06 PM, baden.ku...@gmail.com wrote:
> As I know very little about this, I am inquiring about cross compiling applications for OS/2.
>
> For instance, I believe with 'Watcom C', I can develop and compile code for DOS 8, 16 or 32 bit, OS/2 16 or 32 bit, and Win 16 or 32 bit, all from OS/2. I am unsure what Win graphical code can be compiled from OS/2. I assume that from Win 32, all the equivalent code could also be developed and compiled for all the platforms. I also assume that from DOS, some code (VIO?) could be developed and compiled, including OS/2. Would that include any PM?
>
Yes, assuming you have the right SDK's installed, and OpenWatcom now has
> As I know very little about this, I am inquiring about cross compiling applications for OS/2.
>
> For instance, I believe with 'Watcom C', I can develop and compile code for DOS 8, 16 or 32 bit, OS/2 16 or 32 bit, and Win 16 or 32 bit, all from OS/2. I am unsure what Win graphical code can be compiled from OS/2. I assume that from Win 32, all the equivalent code could also be developed and compiled for all the platforms. I also assume that from DOS, some code (VIO?) could be developed and compiled, including OS/2. Would that include any PM?
>
most everything needed, you can cross compile for any supported
platform. Testing is still needed in a native environment.
I'm also not sure about things like the SOM compiler (needed for WPS
programming), which may only run on OS/2 and is not currently part of OW.
> I am unsure whether the application code word size (8,16 or 32 bit) is dependant on the development platform. For instance, would Watcom on OS/2 1.3 only develop and compile OS/2 16 bit VIO and PM applications, 8 or 16 bit DOS, and Win 16 applications? Or, could OS/2 1.2 and Win 3.1 support 32 bit development?
>
(some object files can require over a GB of memory space and over 2GB
file size support to compile, likewise for linking), you should be able
to compile 32 bit code on a 16 bit platform.
> Would Watcom on DOS 32 support OS/2 32 bit development, both VIO and PM? Would Watcom on Win 64 support OS/2 32 bit PM development? Would Watcom on Linux 64 support OS/2 PM development?
done natively.
>
> Branching from Watcom, what is the corresponding situation with GCC? Can a GCC IDE on a 32 bit machine develop and compile graphical code for all the supported 32 bit platforms? Would GCC on Win 64 or Linux 64 support OS/2 PM development?
Mingw. Currently for OS/2, the headers, libraries, and toolchain would
first have to be moved or ported to Linux. Our toolchain is a bit weird
compared to most GCC environments so would take some work which no one
has done.
>
> If a developer had a high end 64 bit workstation (Win or Linux), could he use Watcom or GCC to develop and compile OS/2 PM applications. If he used the compiler natively under a OS/2 VM, would it help or hinder development?
machine, it should work fine though things like VBox not supporting
multiple cores with an OS/2 client could slow things down. OTOH, disk
access may be quicker given things like a real fast SSD sitting in a
fast interface.
>
> Let's presume a 64 bit machine used Watcom C or GCC to develop OS/2 PM, and used an OS/2 VM to test the application. Would this be feasible or practicable?
Dave
baden.ku...@gmail.com
Jul 2, 2020, 2:27:39 PM7/2/20
to
Hi Dave:
Thanks so much for your detailed response.
As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory. Is that expected as an application or OS issue, or might it be unique.
3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
thanks for your help!
Baden
On Monday, 22 June 2020 22:45:52 UTC-5, Dave Yeo wrote:
Thanks so much for your detailed response.
As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory. Is that expected as an application or OS issue, or might it be unique.
3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
thanks for your help!
Baden
On Monday, 22 June 2020 22:45:52 UTC-5, Dave Yeo wrote:
Marcel Mueller
Jul 2, 2020, 3:50:46 PM7/2/20
to
Am 02.07.20 um 20:27 schrieb baden.ku...@gmail.com:
Otherwise it is in the order of 2GB (configurable).
> 2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory.
32 bit processes normally cannot use more than 2GB of private virtual
address space. This is not the same than used private memory which is
less. In case of Mozilla XUL is rather bulky.
The limit can be configured by the config.sys parameter VIRTUALADDRESSLIMIT.
If you want details install Theseus4 to inspect the virtual memory map
of the process in the shared and private arena.
> Is that expected as an application or OS issue, or might it be unique.
It is related to 32 bit software.
> 3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
Maybe there are some bugs in the OS/2 port.
Marcel
> Hi Dave:
>
> Thanks so much for your detailed response.
>
> As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
>
> 1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
AFAIK the constraint applies only to memory with 16 bit compatibility.
>
> Thanks so much for your detailed response.
>
> As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
>
> 1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
Otherwise it is in the order of 2GB (configurable).
> 2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory.
address space. This is not the same than used private memory which is
less. In case of Mozilla XUL is rather bulky.
The limit can be configured by the config.sys parameter VIRTUALADDRESSLIMIT.
If you want details install Theseus4 to inspect the virtual memory map
of the process in the shared and private arena.
> Is that expected as an application or OS issue, or might it be unique.
> 3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
Marcel
Dave Yeo
Jul 3, 2020, 12:24:08 AM7/3/20
to
Hi Baden,
On 07/02/20 11:27 AM, baden.ku...@gmail.com wrote:
> Hi Dave:
>
> Thanks so much for your detailed response.
>
> As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
>
> 1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
Actually with Warp server and Warp 4.5+, there is also the high shared
memory arena, which varies on how VIRTUALADDRESSLIMIT is set. Currently,
testing some new builds and having forgot to set the DLLs to load in
high memory, I currently have this,
H:\tmp>mem /v
Total physical memory: 12,169 MB
Accessible to system: 3,241 MB
Additional (PAE) memory: 8,928 MB
Resident memory: 166 MB
Available virtual memory: 3,111 MB
Available process memory:
Private low memory: 140 MB
Private high memory: 1,792 MB
Shared low memory: 39 MB
Shared high memory: 1,303 MB
This is going to soon crash due to running out of low shared memory :)
>
> 2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory. Is that expected as an application or OS issue, or might it be unique.
There's a few things happening. The Mozilla apps by default will try to
allocate memory in the high arena first, which is why it can allocate
1.5 GBs. There is also where the actual DLLs are loaded. By default in
low shared memory, a precious resource. They can be marked to load into
high memory, both code and data, best to only load the code high, eg
"highmem -c xul.dll" which helps a lot. Then we run into a kernel bug
where the memory is not released when unloading the DLL. Easy to see
with Theseus. Workaround is to use one of the mozturbo programs to keep
the DLLs loaded. This has made my system stable enough to have weeks of
uptime while repeatably loading, unloading and reloading all 3 Mozilla
apps. Once again it is important to have VIRTUALADDRESSLIMIT set to a
high value, at least 2560, if not 3072. Some hardware doesn't like 3072,
things like video cards using a lot of memory. AOS has way too low of a
default causing lots of crashes in the Mozilla apps.
Then there is the crappy coding that Mozilla has, things like using
objects before creating them. On all platforms OOM (out of memory
crashes) are the most common crash on 32 bit systems.
I've been experimenting with the new GCC 9.2.0. It shows a lot of
programming errors on Mozilla's part as it is not as forgiving and took
quite a bit if work to make it stable.
>
> 3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
>
The threading is the same as native apps. Mostly written into the native
app, though Bitwise often used pthreads, which is mapped to native
threads. Your hangs are likely memory related, though Mozilla doesn't
use threading that much.
> thanks for your help!
> Baden
In summary, have a high VIRTUALADDRESSLIMIT, mark the DLLs to load code
high, use the mozturbo programs to keep the DLLs loaded in high memory
and the Mozilla apps are quite stable. There's still JavaScript
problems/bugs, I run NoScript. uBlock Origin to block ads and a hosts
file to route ads into NUL: Ads are a resource hog and a security risk.
Dave
ps I'm using
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ,
recommended, route those ads to 0.0.0.0 before they make it to the browser.
On 07/02/20 11:27 AM, baden.ku...@gmail.com wrote:
> Hi Dave:
>
> Thanks so much for your detailed response.
>
> As you probably know a lot about large application (Mozilla) compilation, I have a few more questions, that were probably never covered in a Red Book:
>
> 1) IIRC, the shared memory pool is 384 MB, and this has always been an OS constraint. With 'Mozilla', how much of that shared memory is used? I still have occasional problems, where I need to close programs.
memory arena, which varies on how VIRTUALADDRESSLIMIT is set. Currently,
testing some new builds and having forgot to set the DLLs to load in
high memory, I currently have this,
H:\tmp>mem /v
Total physical memory: 12,169 MB
Accessible to system: 3,241 MB
Additional (PAE) memory: 8,928 MB
Resident memory: 166 MB
Available virtual memory: 3,111 MB
Available process memory:
Private low memory: 140 MB
Private high memory: 1,792 MB
Shared low memory: 39 MB
Shared high memory: 1,303 MB
This is going to soon crash due to running out of low shared memory :)
>
> 2) While I often see 500 MB memory allocated (200 to start) while using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla seems unstable and often abends when addressing too much memory. Is that expected as an application or OS issue, or might it be unique.
allocate memory in the high arena first, which is why it can allocate
1.5 GBs. There is also where the actual DLLs are loaded. By default in
low shared memory, a precious resource. They can be marked to load into
high memory, both code and data, best to only load the code high, eg
"highmem -c xul.dll" which helps a lot. Then we run into a kernel bug
where the memory is not released when unloading the DLL. Easy to see
with Theseus. Workaround is to use one of the mozturbo programs to keep
the DLLs loaded. This has made my system stable enough to have weeks of
uptime while repeatably loading, unloading and reloading all 3 Mozilla
apps. Once again it is important to have VIRTUALADDRESSLIMIT set to a
high value, at least 2560, if not 3072. Some hardware doesn't like 3072,
things like video cards using a lot of memory. AOS has way too low of a
default causing lots of crashes in the Mozilla apps.
Then there is the crappy coding that Mozilla has, things like using
objects before creating them. On all platforms OOM (out of memory
crashes) are the most common crash on 32 bit systems.
I've been experimenting with the new GCC 9.2.0. It shows a lot of
programming errors on Mozilla's part as it is not as forgiving and took
quite a bit if work to make it stable.
>
> 3) Maybe related to (2), I am wondering how thread management performs on the gcc ports. Should it be similar to native applications? The reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey if a tab hangs. Is the threading written into the application source code?
>
app, though Bitwise often used pthreads, which is mapped to native
threads. Your hangs are likely memory related, though Mozilla doesn't
use threading that much.
> thanks for your help!
> Baden
high, use the mozturbo programs to keep the DLLs loaded in high memory
and the Mozilla apps are quite stable. There's still JavaScript
problems/bugs, I run NoScript. uBlock Origin to block ads and a hosts
file to route ads into NUL: Ads are a resource hog and a security risk.
Dave
ps I'm using
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ,
recommended, route those ads to 0.0.0.0 before they make it to the browser.
Dave Yeo
Jul 3, 2020, 12:34:52 AM7/3/20
to
On 07/02/20 12:50 PM, Marcel Mueller wrote:
> Am 02.07.20 um 20:27 schrieb baden.ku...@gmail.com:
>> Hi Dave:
>>
>> Thanks so much for your detailed response.
>>
>> As you probably know a lot about large application (Mozilla)
>> compilation, I have a few more questions, that were probably never
>> covered in a Red Book:
>>
>> 1) IIRC, the shared memory pool is 384 MB, and this has always been an
>> OS constraint. With 'Mozilla', how much of that shared memory is
>> used? I still have occasional problems, where I need to close programs.
>
> AFAIK the constraint applies only to memory with 16 bit compatibility.
> Otherwise it is in the order of 2GB (configurable).
Actually up to 3GB plus kernel space plus PCI space equals 4GB. For a
> Am 02.07.20 um 20:27 schrieb baden.ku...@gmail.com:
>> Hi Dave:
>>
>> Thanks so much for your detailed response.
>>
>> As you probably know a lot about large application (Mozilla)
>> compilation, I have a few more questions, that were probably never
>> covered in a Red Book:
>>
>> 1) IIRC, the shared memory pool is 384 MB, and this has always been an
>> OS constraint. With 'Mozilla', how much of that shared memory is
>> used? I still have occasional problems, where I need to close programs.
>
> AFAIK the constraint applies only to memory with 16 bit compatibility.
> Otherwise it is in the order of 2GB (configurable).
while I could only link xul.dll with VIRTUALADDRESSLIMIT=3072. With 1.5
GBs of real ram, I could over flow the swap file, it has a 2GB limit
>
>
>> 2) While I often see 500 MB memory allocated (200 to start) while
>> using Mozilla, occasionally it uses 1.5 GB or more. However, Mozilla
>> seems unstable and often abends when addressing too much memory.
>
> 32 bit processes normally cannot use more than 2GB of private virtual
> address space. This is not the same than used private memory which is
> less. In case of Mozilla XUL is rather bulky.
>
> The limit can be configured by the config.sys parameter
> VIRTUALADDRESSLIMIT.
>
> If you want details install Theseus4 to inspect the virtual memory map
> of the process in the shared and private arena.
>
>> Is that expected as an application or OS issue, or might it be unique.
>
> It is related to 32 bit software.
>
>
>> 3) Maybe related to (2), I am wondering how thread management performs
>> on the gcc ports. Should it be similar to native applications? The
>> reason I am asking, is that often I have to use Ctrl-Esc/Watchcat to
>> kill SeaMonkey if a tab hangs. Is the threading written into the
>> application source code?
>
> Maybe there are some bugs in the OS/2 port.
before creating them for example.
Dave
0 new messages