Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: Updating OxyScheme
« Last post by Mike Lobanovsky on December 14, 2019, 02:02:48 PM »
I can recollect vaguely the late Robbek used to upload a few Lisp apps here bundled with some GUI framework DLL that hung in memory so tightly we had to use the Task Manager to kill the process...
2
General / Re: Updating OxyScheme
« Last post by Charles Pegge on December 14, 2019, 03:54:52 AM »
Before the PC, every home computer had its own hardware, and came with its own built-in version of BASIC and integral operating-system. So diversity was there from the start :)

However R5RS Scheme is, in my view, an incomplete language, so the standardisation is a bit of a cheat.

I would like to see how Scheme would encode a Windows GUI app.
3
Development / Re: Compliant 64-bit compiling
« Last post by Charles Pegge on December 13, 2019, 05:10:47 AM »
Hi Roland,

Yes, end extern is normally inserted after external declarations, and all functions and their declarations are considered 'internal' by default until the next 'extern' statement.

extern statement direct the compiler to use standard (DLL) calling conventions instead of the more efficient internal calling conventions.

Individual procedures are also made 'extern' by any of the following tags:
external extern callback export
4
Development / Re: Compliant 64-bit compiling
« Last post by Arnold on December 13, 2019, 02:37:42 AM »
Hi Charles,

this solution of declaring sprintf is indeed brilliant. Now something like this will be possible:

Code: [Select]
char strg
int a = 10, b = 38, double c
c = a / b

sprintf(strg, "Value of Pi = %15.10f" + chr(10) + "Division of %d by %d is: %15.10f", pi, a, b, c)
print strg   

I see that I will need 'extern' for compiling to 64-bit. Is there also a need for 'end extern' or is this not necessary?

Roland
5
Development / Re: Compliant 64-bit compiling
« Last post by Charles Pegge on December 12, 2019, 02:31:10 AM »
Hi Roland,

In 64bit mode, variadic params 1..4 are passed in cpu registers regardless of float types. Therefore a prototype is required to declare the variadic types:

uses corewin
...
! sprintf (char *s,*f,...) at @sprintf


Code: [Select]
'10:12 12/12/2019
'float variadic params are passed in cpu in 64bit mode
$filename "o.exe"
uses rtl64
uses corewin
char c[64] 'string buffer
double v1=123
extern
 'create an overlay of sprintf with variadic prototype
! sprintf (char *s,*f,...) at @sprintf
#show sprintf (c,"%4.2f",v1) '123.00
print c
6
Development / Re: Compliant 64-bit compiling
« Last post by Arnold on December 11, 2019, 07:52:36 AM »
Hi MIke,

probably I can apply sprintf in combination with print and get the same result. Some functions of msvcrt.dll seem to work quite nice in Win64. Unfortunately I have not yet found some more extensive documentation about this dll, many links seem to be broken.

Roland
7
Development / Re: Compliant 64-bit compiling
« Last post by Mike Lobanovsky on December 11, 2019, 04:31:01 AM »
Roland,

Though both C and Win32 provide access to consoles to read from or write to, their console systems are not interchangeable.

For instance, C provides STDIN, STDOUT and STDERR consoles that are regarded as pure files, and printf()/fprintf()/etc. functions, to manage their text. On the other hand, Win32 provides indirect access to its consoles through their read/write buffers that bear no resemblance to files/streams.

Therefore, changing the mini-/nanoscheme printing technique from C to O2 Win32-based printing seemed to me too much error-prone PITA. A 32-bit msvcrt.dll runtime is supposed to provide several exported functions that return an array of pointers to STDIN/-OUT/-ERR "files" usable for printing with C file handling functions. Unfortunately, some of the exports turned out to be mere stubs, and __p__iob() was the only one function whose return I was able to use in Oxygen as valid pointers to the console "files".

64-bit C STDIN/-OUT/-ERR "file" access seems to be a little different from 32 bits, and it wasn't actual for me at the time I worked on the 32-bit oxy-/nanoscheme code.

If you feel you can spare your time on switching from C-style printing over to Oxygen-style Win32 printing, you are free to modify the oxyscheme code (it's Public Domain anyway) as you like. But I can't guarantee it won't have any unexpected side effects on the oxyscheme code that's yet unproven functioning in the latest Oxygene builds.
8
Development / Re: Compliant 64-bit compiling
« Last post by Arnold on December 11, 2019, 03:26:04 AM »
Hi Charles, Mike,

I would like to refer to \projectsB\Console\Printf.o2bas. The demo works in 32-bit and failes in 64-bit mode. I tried this code snippet:

Code: [Select]
$ Filename "Test_iob.exe"
'uses rtl32
'uses rtl64

uses corewin
'uses console

'sys _iob = __p__iob()
'print _iob

print __p__iob()

Must __p__iob() be applied differently in 64-bit mode or is it not available in this mode? The structure FILE is used in stdio.h of tcc also, and printf works with tcc in 64-bit too. But it seems there is another approach used. I simply do not understand this piece of code in stdio.h:

#ifdef _WIN64
  _CRTIMP FILE *__cdecl __iob_func(void);
#else
#ifdef _MSVCRT_
extern FILE _iob[];     /* A pointer to an array of FILE */
#define __iob_func()    (_iob)

Is there a solution to run the different printf functions of msvcrt.dll in 64-bit also? It would be a pity if it is not possible in O2.

Roland
9
General / Re: Updating OxyScheme
« Last post by Mike Lobanovsky on December 11, 2019, 02:20:43 AM »
BTW let me note again that oxy-/nano-/mini Schemes are not yet fully R5RS compatible as-is. They still lack vector (= array) and char data type functionality. I lost interest in developing the code before I had a chance to add those features to the core language.
10
General / Re: Updating OxyScheme
« Last post by Mike Lobanovsky on December 11, 2019, 02:09:07 AM »
Hehe, unlike anarchist BASICs, Scheme dialects are not allowed to expand the language core vocabulary at the developer's volition. Standard library extensions are supposed to first stay in the library in the form of macros for years if not decades to get their functionality (as set forth by RnRS recommendations) and usefulness field-proven by the community. Implementations may differ from dialect to dialect but not the interface or place in the language keyword hierarchy.
Pages: [1] 2 3 ... 10