newLISP for OS/2 - eComstation

[newdep]

After some months of no OS/2 running i rebuild my machine and development
environment and started right away compiling the latest newLISP.

Funny thing is i'm now with a newer gcc 3.3.5 version en libc061.dll
instead of the older beta-5 and libc06b5.dll and it all compiles far more fluent.
Still the minor issues though because of some posix compilant issues in OS2..etc..

I hope to release newLISP 9.1 final also for OS/2 with gcc 3.3.5 and libc061.dll
when the official one does..

the 9.0.14 OS2 is not released yet.. its time for testing, Ill be back ;-)

Norman.

[newdep]

newlisp.exe for OS/2 9.0.15 will be posted soon on the website http://newlisp.nodep.nl
For those with the best OS on earth, you can try it out, for those with the second best
OS on earth please download the package from newlisp.org ;-)

Regards, Norman.

[newdep]

Exactly 2 years later now 2009 Im continuing the OS/2 eComstation port of
newlisp based on gcc. (perhpas later on OpenWatcom)

Ill notify here when the newLisp/2 release is done based on 10.0 or 10.1

Regards, Norman

http://www.eComstation.com
http://www.mensys.nl <- current development of eComstation (yes Dutch! together with the Russians and lots of others ;-)

[Lutz]

Start with 10.0.1 released later this week. It compiles better on the newer GCC 4.3.2, which is pickier than previous versions in some cases. Peter has also good experience with it on TRU64.

[newdep]

yes i have 4.3.2 around.. Ill start with 10.1 ;-)

[newdep]

version v10 of newlisp is running and compiled.

Without the use of 'Spawn' as it uses 'munmap' which does not exist yet in gcc 335.

Never the less its running :-) Testing continue's..


some proof ->

[E:\prog\nl\newlisp-10.0.0]newlisp
newLISP v.10.0.0 on OS/2 IPv4, execute 'newlisp -h' for more info.

> (sys-info)
(375 268435456 364 1 0 2048 1015 10000 7)
> ostype
"OS/2"
>

[newdep]

new newlisp2 website http://newlisp2.nodep.nl/

updates continue ill make the announcement today to the OS/2 world. ;-)

[newdep]

Oke.. with some tweaks and "digging into a personal gray history of C programming,
about 17 years ago" newlisp is now able to actualy call OS/2 routines. The first Vio
(Video IO) calls where just made to test it...

I want to do some testing on the Vio, Kbd, Mouse moving to Gpi and finaly
integrating the PM calls. (which means the graphical windows/Presentaion manager).
If those all work Ill try to make the OS/2 programming more smooth inside newlisp,
perhpas providing a os2.lsp library.. As for now the actualy OS/2 calls arnt included
yet into the newlisp/2 port with gcc/2.

What newlisp finaly will be is a Gnu based conpiled version which is able
to call/work on OS/2 based library's (work of gcc / emx) ..so the working continues...:-)

keep you posted...

Code: Select all

[E:\PROG\NL\newlisp-10.1.6]chk4dlls newlisp.exe
Loading DLL 'libc063' --> D:\ECS\DLL\LIBC063.DLL.
Loading DLL 'tcpip32' --> D:\MPTN\DLL\TCPIP32.DLL.
Loading DLL 'viocalls' --> D:\OS2\DLL\VIOCALLS.DLL.
All DLL's used by 'newlisp.exe' could be loaded.

[newdep]

Lutz,

Perhpas you can help me out a little ;-)

There are some ways to implement the VioCalls from OS/2 into newlisp.

* Try Loading the VIOCALLS and do all function handling in pure newlisp by use of (import)..
* Pre-program in C the functions to use (see below)
* Map the functions from the os2.h directly to newlisp symbols (not easy I guess)


Below Ive added VIOCALLS directly into the newlisp C code.

As the Calls from OS/2 travel outside segements they do a lot of
FAR * calling, Which is not particular handy when using (import)
and (pack) to assign far *pointers etc.. Or is that possible ?
(I got SIGSEGV all day next to me on the coffeee table trying that ;-)

Code: Select all

newLISP v.10.1.6 on OS/2 IPv4, execute 'newlisp -h' for more info.

> (VioGetMode)
(155 50 640 400)
> (VioGetAnsi)
true
>

As the above states these are pre-compiled funtions see here the (dump) ->

Code: Select all

...
address=551710 type=263 contents=net-interface <2F40C>
address=551720 type=263 contents=net-ping <2E80C>
address=551730 type=263 contents=net-error <2E748>
address=551740 type=263 contents=VioGetAnsi <40888>
address=551750 type=263 contents=VioReadCharStr <407F0>
address=551760 type=263 contents=VioGetMode <40740>
address=551770 type=256 contents=nil
...

I think, but perhpas you have an alternative which is easier, then I need
to include all the OS/2 calls I would like to use inside my own nl-os2.c file
(as I do now) and use it like that..Its a hell of a job programming these..
But I need to select only the once I would like to use..for now ;-)




* edited *
PS: Do you have an API document regaring integrating into newlisp with C code?
Or perhpas a newlisp-blue-print of your mind ;-)

[Lutz]

If OS/2 is similar to Win32 (assuming that an OS/2 segment is 64K), then FAR calls and FAR * are not a problem they are simply 32-bit calls and pointers handled well by newLISP 'import'.

I don't have a problem if you add a nl-os2.c, as long as you document the additional functions and modify the makefile_os2 appropiately.

Do you have an API document regarding integrating into newlisp with C code?

No, I don't have that, but here is a one-paragraph version:

For getting parameters look at getInteger(), getInteger64(), getFloat(), getString() etc. For returning values see stuffInteger(), stuffIntere64(), stuffFloat() and stuffString(). Then there is also stuffIntegerList() you could use in VioGetMode. These getXXX() calls do type verification and throw errors if required. The getInteger() and getFloat() calls also do type transformation to the target type you want to get.

[newdep]

If OS/2 is similar to Win32 (assuming that an OS/2 segment is 64K), then FAR calls and FAR * are not a problem they are simply 32-bit calls and pointers handled well by newLISP 'import'.

I don't have a problem if you add a nl-os2.c, as long as you document the additional functions and modify the makefile_os2 appropiately.

Do you have an API document regarding integrating into newlisp with C code?

No, I don't have that, but here is a one-paragraph version:

For getting parameters look at getInteger(), getInteger64(), getFloat(), getString() etc. For returning values see stuffInteger(), stuffIntere64(), stuffFloat() and stuffString(). Then there is also stuffIntegerList() you could use in VioGetMode. These getXXX() calls do type verification and throw errors if required. The getInteger() and getFloat() calls also do type transformation to the target type you want to get.

I dont know if Win32 is similar ..I never programmed on Windows..;-)
I need to check this out again with a 4 byte pack..
If I would use the import function I will need to rewrite this for OS/2..Not that difficult...

I do like indeed a merged nl-os2.c file, And I forgot to ask actualy if that is allowed to do..
But I prefer the import method.. lets see which one is more flexible...

Thanks for the Par. I ran indeed into most of these calls and already used them,
Ill manage that...

[newdep]

I descided to do the nl-os2.c version...

Ill make sure the nl-os2.c is documented well (newlisp-doc format)
and the makefile_os2 gets an extra entrypoint for the os2 api addon...
Perhpas even write an official patch routine for os/2 to add the functions
and return/erorcodes to the newlisp tree.

Ill be back...


* edited *
Its all gonna be done with runtime-dynamic-linking..