osfree.org

#491 From: "criguada@..." <criguada@...>
Date: Fri Aug 30, 2002 11:03 am
Subject: Re: Re: osFree criguada
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi Michal, Yuri,

> >>the _cdecl or _Optlink calling convention?
> >Hm... Any known compiler.
> >
> They all support all these calling conventions? I'm impressed.

Nah, unfortunately not. _cdecl is supported by all compiler I know of,
but the _optlink calling convention is only supported by IBM C/C++
compilers AFAIK, although I heard that the new GCC 3.x now supports
_optlink.
There is no _optlink support in either Virtual Pascal or Sibyl. Not sure
about FreePascal.

However, I have to say that OO pascal (the one used in Delphi, Sibyl,
Virtual Pascal and Free Pascal) is really a good language, and it
provides for higher productivity (for me at least) than C/C++. There are
really good pascal compilers out there, that can produce fast optimized
code comparable to C compiled code. Unfortunately most of the toolkits
are provided for C++ only these days.

Thankyou
Bye

Cris

#492 From: "Yuri Prokushev" <prokushev@...>
Date: Fri Aug 30, 2002 1:54 pm
Subject: Re: OpenSibyl & Lazarus prokushev
Offline Offline
Send Email Send Email


On Fri, 30 Aug 2002 07:52:11 +0200 (CDT), Bartosz Tomasik (Bart/2) wrote:

>btw are you familiar with lazarus project? They also use free pascal...
Yes.

#493 From: Cristiano Guadagnino <criguada@...>
Date: Sat Aug 31, 2002 12:13 am
Subject: Re: Re: osFree criguada
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi Yuri,

Yuri Prokushev wrote:
>>He initially said he didn't want to send it to Netlabs or to public
>>FTPs, but only to interested people (I applied). I thought he later
>>changed idea and sent it to hobbes, but evidently I was wrong.
>
> Ok. But how about 'he didn't want to send it to Netlabs or to public FTPs'? I
prefer to publish this sources. If not - not interesting, because I will make
all this thing from the
> scratch . I don't see Antony's e-mail in archive. Required Antony's
comfimation about publishing this sources under some opensource license.

I don't think he has problems. BTW, the best thing is for you to write
directly to him.

BTW, we're now off topic here. I'm subscribed to the OpenSibyl list, so
we better go talk there.

Bye

Cris

#494 From: "evgen_ek" <evgen_k@...>
Date: Sat Aug 31, 2002 7:55 pm
Subject: Re: osFree evgen_ek
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi,

--- In osFree@y..., "Bartosz Tomasik (Bart/2)" <bart2@a...> wrote:
> On Sat, 24 Aug 2002 16:18:39 -0000, evgen_ek wrote:
>
> >> >>a) The build environment is based on OpenWatcom and our toolset
> >I use VAC 3.08...
>
> VAC (avery version) is not supported anymore. And it still has bugs
which you can get
[...]
I am very conservative in changing my work compiler, I have Watcom 11
but can use it only for writing driver and for compiling OS/2-WinXX
cmd utils. I think that version 0.8 is not still my choice.
Once again, with sources I dont see any problem with VAC - OpenWatcom
(ex)change

SY,
EK

#495 From: Josй Francisco Garcнa Mtz. <jfgarcia@...>
Date: Sat Aug 31, 2002 1:13 pm
Subject: Re: Building of osFree jfgarcia_mx
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


"Bartosz Tomasik (Bart/2)" escribiу:

> On Mon, 26 Aug 2002 08:23:51 -0000, teahola wrote:
>
> >What stuff I need to compile osFree? Can I use VACPP?
>
> You need to get Watcom 11.0c (available for free, eg from osFree site) nad
> OS/2Toolkit (I use 4.,5).

Where can I find OS/2 Toolkit?
Thanks in advance.

Attachment: vcard [not shown]

#496 From: "evgen_ek" <evgen_k@...>
Date: Sun Sep 1, 2002 12:20 am
Subject: Re: FreePM thoughts evgen_ek
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi,
--- In osFree@y..., "Bartosz Tomasik (Bart/2)" <bart2@a...> wrote:
> and now pure-FreePM realated
> -. CVS on sourceforge suxx I ust cannot use it, and if you stay
> there, you'll cut me off

What about goto http://frepm.sourceforge.net/ and read "How to get CVS
tree" ?

> the project...
> - ad 10. "FreePM thargets": using C++ in api isn't good idea..
> unless you wan't to use
> SOM, but again, only C/C++ supports SOM now...

again, what is bad in using "traditional" API calls and "extended
++" API ? You want to use "traditional" API ? - use it! You want deal
with natural window classes as C++ classes ? - No problem - use
"extended ++" API !

Little stopy about Squid sources.
It is pure C sources, that deal with a number of entities that is
almost classes (structures with pointers to functions). Moreover, they
use even variables names such as "class", "private" etc, used
"methods" and so on. I asked them wy not use C++ - the answer was that
"This is the UNIX, sonny! we have a lot of xxx C++ compilers on
ancient machines that are not C++ compilers"

I think that we have not such a problem

> - ad 13. "FreePM thargets": recompilation is too much...
All will be in sources. Sources will be divide in some parts such as
lib, dll and client/server core.
Well. When and if the FreePM will can produce some "Hello world"
application, then somebody will can start develop patch to FreePM to
make it work with PM applications without recompilation

#497 From: "Bartosz Tomasik (Bart/2)" <bart2@...>
Date: Sun Sep 1, 2002 9:55 am
Subject: Re: Re: FreePM thoughts ihsiatko
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Sat, 31 Aug 2002 20:20:17 -0000, evgen_ek wrote:

>> -. CVS on sourceforge suxx I ust cannot use it, and if you stay
>> there, you'll cut me off
>
>What about goto http://frepm.sourceforge.net/ and read "How to get CVS
>tree" ?

heh, that's not problem, problem is time I am able to spent on internet
connection (and
monay I have to pay for that), and this is _very_ restricted for me nowadays.
sourceforge trabsfer is so worse, I will not even try to checkout anything from
there..

>again, what is bad in using "traditional" API calls and "extended
>++" API ? You want to use "traditional" API ? - use it! You want deal
>with natural window classes as C++ classes ? - No problem - use
>"extended ++" API

right, but... you do C++ api in VAC (and will probably pack them as dll
library), noone
without VAC won't be able to use them unless you provide these classes compiled
using their compiler. This will drasticly limit it's (C++ api) usability.

>Little stopy about Squid sources.
>[...]
>
>I think that we have not such a problem

Yea, but we got another: every compiler has it's own C++ ninary interface
uncompatible
with others, and without SOM it's unsolveable (if you wan't ask Michal Necasek -
he
explained me that, when I though I had an idea how to solve that)

>All will be in sources. Sources will be divide in some parts such as
>lib, dll and client/server core.
>Well. When and if the FreePM will can produce some "Hello world"
>application, then somebody will can start develop patch to FreePM to
>make it work with PM applications without recompilation

I have a proposal... can we do implementation for current (IBM) design first?
And that's
for VIO to save paying with GRE and drivers. Next step would be GPI,GRE. And
leaving client-server for the end?
-------------------------------------------------
Bart/2 irc:Ihsahn Bart2@... UIN:50890586
Asu'a Programmers Group http://www.asua.org.pl
TeamOS/2 Polska http://www.teamos2.org.pl

#498 From: "evgen_ek" <evgen_k@...>
Date: Sun Sep 1, 2002 12:48 pm
Subject: Re: FreePM thoughts evgen_ek
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi,
--- In osFree@y..., "Bartosz Tomasik (Bart/2)" <bart2@a...> wrote:
> heh, that's not problem, problem is time I am able to spent on
internet connection (and
> monay I have to pay for that), and this is _very_ restricted for me
nowadays.
> sourceforge trabsfer is so worse, I will not even try to checkout
anything from there..

hehe... I thinked that I have the worst connection via two modems, the
ancient soviet "Iskra" fone line (and 30 users on it) that drops every
10-30 min so that old squids fall once a day minimum and I have to
start squid2... On the other hand, I personally still not pay money

>
> >again, what is bad in using "traditional" API calls and "extended
> >++" API ? You want to use "traditional" API ? - use it! You want deal
> >with natural window classes as C++ classes ? - No problem - use
> >"extended ++" API
>
> right, but... you do C++ api in VAC (and will probably pack them as
dll library), noone
> without VAC won't be able to use them unless you provide these
classes compiled
> using their compiler. This will drasticly limit it's (C++ api)
usability.

First it will be used with developers compiler. i.e. VAC, Watcom or
what else ? Second it will be after things start work - with
OpenWatcom it will be possible to solve problems with name mangling...
Hehe...
======================
VisualAge C++ provides two methods of converting mangled names to the
original source code names, demangling functions and the CPPFILT utility.
The demangling functions are described in the appendix on Mapping in
the IBM VisualAge C++ for OS/2 User's Guide and Reference and in the
<demangle.h> header file. The CPPFILT utility is described in the
online VisualAge C++ Compiler Utilities Reference.

======================

>
> >All will be in sources. Sources will be divide in some parts such as
> >lib, dll and client/server core.
> >Well. When and if the FreePM will can produce some "Hello world"
> >application, then somebody will can start develop patch to FreePM to
> >make it work with PM applications without recompilation
>
> I have a proposal... can we do implementation for current (IBM)
design first? And that's
> for VIO to save paying with GRE and drivers. Next step would be
GPI,GRE. And
> leaving client-server for the end?

First will be debug logs from squid
Second will be client-server side. It is from pure fact that (free)PM
is separate task and we have to do IPC (interpocess communication).
The best way to do IPC is do it via pipes. Pipes lead to client-server
model.

SY,
EK

#499 From: "Bartosz Tomasik (Bart/2)" <bart2@...>
Date: Mon Sep 2, 2002 8:24 am
Subject: Re: Re: FreePM thoughts ihsiatko
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


On Sun, 01 Sep 2002 08:48:54 -0000, evgen_ek wrote:

>First it will be used with developers compiler. i.e. VAC, Watcom or
>what else ? Second it will be after things start work - with
>OpenWatcom it will be possible to solve problems with name mangling...
>Hehe...

not only name mangling is the problem. let me quote Michal:

> First and foremost, the entire object model is not standard and differs
>between compilers. That is, things like how exactly classes are constructed,
>where virtual method tables will be etc. etc. are different.
>
> Second, there is the question of runtime support. Global constructors,
>exception handling, RTTI, helper functions. Again, no standard. And these
>things are even different between different versions of the same compiler.
>
> To fix these problems you'd have to somehow decide which compiler
>does these things best (if any) and then rewrite the other compilers
.and modify their runtime libraries. This certainly isn't impossible,
>just not worth the effort IMO.
>
>[...]
> The problem with C++ is that it exposes far too
>much of its internals. As you noticed, if you want to call
>a C++ DLL from a C++ program, _everything_ has to match. This
>is exactly why technologies like SOM and COM were invented.
>SOM (among other things) solves exactly this problem - it hides
>the implementation details and class libraries are binary
>compatible between compilers and even between languages.

that's it




-------------------------------------------------
Bart/2 irc:Ihsahn Bart2@... UIN:50890586
Asu'a Programmers Group http://www.asua.org.pl
TeamOS/2 Polska http://www.teamos2.org.pl

#500 From: "evgen_ek" <evgen_k@...>
Date: Mon Sep 2, 2002 11:20 am
Subject: Q: how WinSendMsg works evgen_ek
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hi,

Toolkit doc:
========================
If the window receiving the message belongs to the same thread, the
window function is called
immediately as a subroutine.
If the window is of another thread or process, the operating
system switches to the appropriate thread that enters the necessary
window procedure recursively. The message is not placed in the queue
of the destination thread.
=======================
How it works -
"the operating system switches to the appropriate thread that enters
the necessary window procedure recursively." ?

SY,
EK