On Friday, May 10, 2002, at 08:32 , Jenda Krynicky wrote:
[..]
>>
>> thanks, that had been my working assumption - but it's
>> this problem of sorting out which parts of what goes
>> into a 'windows system' deal with the GUI, the standard
>> construct of a kernel - as would be used in other OS's -
>> and all of that... And the general issues in that space
>> that are less clear to me about how they organize their
>> coding solutions.
>
> I do not think I understand what you mean.
I fear that is a part of the problem.... At times I feel like
that south park episode with the Marklar....
"your marklar is marklar...."
my first real professional introduction to the token 'win32'
was in perl, in a build system, that required that we be able
to get source out of perforce, and build it for multiple OS's
with NT4.0, win95 on that side - and Solaris variants for
both sparc and x86 cpu architectures - with the expectation
we would generalize later on to include other flavor's of *nix and such...
..
{ as perl has evolved - you can find the OS rev specific
tricks all neatly nested in the PM's - where they check to
see if this is an OS2/VMS/mac/<osDeviantToBeDetermined> and
hence need some OS specific detail.... }
So at one layer I have the token 'win32' tied to the notion of
'the operating system for windows machines'.
while if I write a windowing application in say perl/Tk - with the
expectation that it will work in an Xwindow environment - then I
really do not care if that Xserver is running on linux, darwin,
solaris, SunOS, hpux, aix, mac, win32 {as an operating system token} -
since the GUI itself is independent of the underlying 'kernel' -
except of course if I cut that perl/Tk windowing application to
run in Win32 - the windowing system - then i need to be using
the Win32 modules and keys....
But I have not figured a clean way to differenciate whether
the application should 'spin up' as a Win32 or X variant -
based upon some mystical key token in
use Config;
as well as the other interesting anomalies....
On the Other Side of that process - and part of why I like
perl, is that in the main I personally do not need to know,
in most cases, how the kernel is implementing things like
sockets and I/O layer issues... except of course if I really want to
use some neat POSIX trick, not yet implemented in OS_FOO.
{ eg: i really would have loved to simply have done
use Proc::ProcessTable;
for my psGrovellor - but that would have meant in at least
one case porting the underlying os-specific code to darwin....
and some testing.... rather than simply hack around it in
'pure perl' aware that the darwin ps is mostly a bsd derivative.
and once I could get the four columns of data I wanted, in a
way that I could simply configure it on the fly based upon
$Config{'osname'} we were out to breakfast.... }
Looking at some of the questions raised here on the list, and
the extension of perl into the win32 environment - it would
help me to be able to differenciate the marklar from the marklar.
ciao
drieux
---
rant to be named later:
i hate^H^H^H^H underappreciate sun for the solaris and sunOS -
because one is a BSD derivative, the other a SYS V - hence
implementing similarly different things.
{ I don't have an illustration on hand, but I thought that under
the older sunOS (pre-5.x by the uname -r) versions of perl
$Config{'osname'} eq 'sunos'
and that my current double check of $Config{'osvers'} - is,
well a bit paranoic.... in that it only makes sense to differenciate
between pre-2.7 and the follow ons.... in some edge cases....
OYE! I'm gonna get scragged when solaris 4.X comes out.... and I
still have to maintain backwards compatibility with SunOs 4.X .... }
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
