Fidonet Portal






From: baden.kudrenecky@gmail.com (1:396/4)
To: n/a
Date: Mon, 22.06.20 02:06
OS/2 Compiling?
From: "baden.kudrenecky@gmail.com" <baden.kudrenecky@gmail.com>

As I know very little about this, I am inquiring about cross compiling appl=
ications 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 assum=
e that from Win 32, all the equivalent code could also be developed and com=
piled 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 depe=
ndant 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 D=
OS, 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? W=
ould 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 u=
se Watcom or GCC to develop and compile OS/2 PM applications. If he used t=
he 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 practi=
cable?

thanks for your input,
Baden
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Mon, 22.06.20 09:45
Re: OS/2 Compiling?
From: Dave Yeo <dave.r.yeo@gmail.com>

On 06/22/20 01:06 PM, baden.kudrenecky@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?Wink 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
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?
>

Sure, other then limits like file size, 8.3 name limits or memory limits
(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?

Yes. Though due to lack of SOM compiler, not WPS unless that step was
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?

It could, and people regularly cross compile for Windows on Linux using
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?

See above about needing a native port of the tool chain. In a virtual
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?

Sure, there are people today doing it, usually fully in a VM.

Dave
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: baden.kudrenecky@gmail.com (1:396/4)
To: n/a
Date: Thu, 02.07.20 00:27
Re: OS/2 Compiling?
From: "baden.kudrenecky@gmail.com" <baden.kudrenecky@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 c=
onstraint. With 'Mozilla', how much of that shared memory is used? I stil=
l have occasional problems, where I need to close programs.

2) While I often see 500 MB memory allocated (200 to start) while using Moz=
illa, 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 t=
he gcc ports. Should it be similar to native applications? The reason I a=
m asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey i=
f 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:
> On 06/22/20 01:06 PM, baden.kudrencky@gmail.com wrote:
> > As I know very little about this, I am inquiring about cross compiling =
applications for OS/2.
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mueller (1:396/4)
To: n/a
Date: Thu, 02.07.20 19:50
Re: OS/2 Compiling?
From: Marcel Mueller <news.5.maazl@spamgourmet.org>

Am 02.07.20 um 20:27 schrieb baden.kudrenecky@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).


> 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
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Thu, 02.07.20 10:24
Re: OS/2 Compiling?
From: Dave Yeo <dave.r.yeo@gmail.com>

Hi Baden,

On 07/02/20 11:27 AM, baden.kudrenecky@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 Smile

>
> 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.

--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Thu, 02.07.20 10:34
Re: OS/2 Compiling?
From: Dave Yeo <dave.r.yeo@gmail.com>

On 07/02/20 12:50 PM, Marcel Mueller wrote:
> Am 02.07.20 um 20:27 schrieb baden.kudrenecky@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
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.

The bugs are in the Mozilla code. It's crap, doing memset on objects
before creating them for example.
Dave

--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: baden.kudrenecky@gmail.com (1:396/4)
To: n/a
Date: Thu, 02.07.20 00:27
Re: OS/2 Compiling?
From: "baden.kudrenecky@gmail.com" <baden.kudrenecky@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 c=
onstraint. With 'Mozilla', how much of that shared memory is used? I stil=
l have occasional problems, where I need to close programs.

2) While I often see 500 MB memory allocated (200 to start) while using Moz=
illa, 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 t=
he gcc ports. Should it be similar to native applications? The reason I a=
m asking, is that often I have to use Ctrl-Esc/Watchcat to kill SeaMonkey i=
f 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:
> On 06/22/20 01:06 PM, baden.kudrencky@gmail.com wrote:
> > As I know very little about this, I am inquiring about cross compiling =
applications for OS/2.
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Marcel Mueller (1:396/4)
To: n/a
Date: Thu, 02.07.20 19:50
Re: OS/2 Compiling?
From: Marcel Mueller <news.5.maazl@spamgourmet.org>

Am 02.07.20 um 20:27 schrieb baden.kudrenecky@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).


> 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
--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Thu, 02.07.20 10:24
Re: OS/2 Compiling?
From: Dave Yeo <dave.r.yeo@gmail.com>

Hi Baden,

On 07/02/20 11:27 AM, baden.kudrenecky@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 Smile

>
> 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.

--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

From: Dave Yeo (1:396/4)
To: n/a
Date: Thu, 02.07.20 10:34
Re: OS/2 Compiling?
From: Dave Yeo <dave.r.yeo@gmail.com>

On 07/02/20 12:50 PM, Marcel Mueller wrote:
> Am 02.07.20 um 20:27 schrieb baden.kudrenecky@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
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.

The bugs are in the Mozilla code. It's crap, doing memset on objects
before creating them for example.
Dave

--- NewsGate v1.0 gamma 2
* Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

ABOUT

This forum contains echomail areas hosted on Nightmare BBS You can browse local echomail areas, italian fidonet areas and a selection of international fidonet areas, reading messages posted by users in Nightmare BBS or even other BBSs all over the world. You can find file areas too (functional to fidonet technology). You can browse echomail areas and download files with no registration, but if you want to write messages in echomail areas, or use fidonet netmail (private messages with fidomet technology), you have to register. Only a minimal set of data is required, functional to echomail and netmail usage (name, password, email); a registration and login with facebook is provided too, to allow easy registration. If you won't follow rules (each echomail areas has its own, regularly posted in the echomail), your account may be suspended;

CONTACT