[Gambas-devel] More cygwin

[Brandon Bergren]

Quoting Benoit Minisini <gambas at ...1...>:

> On Thursday 18 November 2004 23:18, Brandon Bergren wrote:
> >
> > Ok, here's what I've found.
> >
> > I can't see any realistic way to beat the  GB_DESC *GB_CLASSES[] into
> > submission.
> > The {class description} sections aren't being constructed properly.
> >
> > Cygwin apparently doesn't like a pointer to an array made of extern
> > elements in a shared library.  I don't blame it.
> >
> > I have an idea for a workaround, but it's not finished yet.  Thinking of a
> > way to implement it without changing the class declaration syntax.
> >
> > On a positive note, the GB structure seems to work OK.  I've been running
> > tests in a hacked-up gbi.c in gdb, and was able to write to GB from a gbi
> > stackframe.
> >
> > :)
> >
> > Also, malloc() doesn't seem to allocate memory that can cross DLL
> > boundaries. I got bla = (type*)GlobalAlloc(GPTR,size) to work fine.
> Another
> > windows-ism.
> >
> > Hopefully, after all that, it'll just be small fixes.
> >
> > --Brandon
> >
> 
> Thanks for your investigation: I didn't imagine that there are so many 
> differences between Cygwin and "normal" unices! Maybe we should thank Windows
> 
> for that...
> 
> As for the pointer to the GB_DESC array: only the pointer to the array is 
> exported, so I think getting the contents of the array is just a matter of 
> some extra indirections. Am I wrong ? :-)

(gdb) up
#1  0x00402379 in analyze (
    path=0x4094b0 "/opt/gambas/lib/gambas/lib.gb.debug.la") at gbi.c:502
502           analyze_class(*desc);
(gdb) print desc
$1 = (GB_DESC **) 0x402000
(gdb) print *desc
$2 = (GB_DESC *) 0x92703d80
(gdb) print desc[0]
$3 = (GB_DESC *) 0x92703d80
(gdb) print *desc[0]
Cannot access memory at address 0x92703d80
(gdb)

desc[0] isn't anywhere near the allowed memory range for the process.
(gdb) print desc[1]
$4 = (GB_DESC *) 0x74000040
(gdb) print *desc[1]
Cannot access memory at address 0x74000040
(gdb)


GB_CLASSES is very confusing to me.  How exactly is the data (supposed to be)
laid out?

If GB_CLASSES is only used for gbi, would it be OK to change it to a function
call on Windows?

Here's an unfinished thought about that:

--------------------
main.c:

BEGIN_GB_CLASSES()
GB_CLASS(CFooDesc)
GB_CLASS(CBarDesc)
END_GB_CLASSES()

CFoo.c:

BEGIN_GB_CLASSDEF(CFooDesc)
GB_DECLARE("Foo", sizeof(CFOO))
GB_EVENT(....)
END_GB_CLASSDEF

CBar.c
BEGIN_GB_CLASSDEF(CBarDesc)
GB_DECLARE("Bar", sizeof(CBAR))
GB_EVENT(....)
END_GB_CLASSDEF

and use conditional macros to expand to

main.c, unix:
GB_DESC *GB_CLASSES[] =
  {
    CFooDesc,
    CBarDesc,
    NULL
  };

foo.c, unix:
GB_DESC CFooDesc[] =
{
  {"Foo", GB_VERSION, sizeof(CBAR)},
  ...
}

main.c, windows:

(pointer to array of arrays of GB_DESC) gbiGETCLASSES()
{
  (GlobalAlloc() some stuff)
  tmpclasses[0] = CFooDesc();
  tmpclasses[1] = CBarDesc();

foo.c, windows:
GB_DESC *CFooDesc()
{
  (allocate space for char* array, bla bla)
-------------------------------


Windows DLLs are a lot like individual programs, rather than libraries.  You
have to think of it more as modules calling each other through interfaces than
shared code.

Each dll has a DllMain(), where the DLL initialize your data and return 1 if
successful.  You aren't supposed to use static structures in Windows, because
the DLL is completely shared between all processes using it. (The dll actually
stores all its stuff related to a process *in that process* and can get a
handle to the memory blocks of the process currently using it.)

So DLL's are much more independent blocks on Windows.  It fits more in to the
event based structure of Windows.

Passing stuff from a DLL into a program works like this a lot.

Program > DLL: I need a copy of foo.
DLL > Program: (passes back a pointer) Here's a pointer to a copy I made in your
process space.
(DLL forgets all about pointer)
...
(Program finishes using data and deallocates the pointer.)

or like this

Program > DLL: Here's a pointer to a preallocated block of memory, fill it for
me.
(DLL fills it, and forgets the pointer)
...
(Program uses data and deallocates.)


As you see, in both cases, the memory is under the jurisdiction of the calling
program. DLL's have a context associated with the thread that is calling the
DLL function.

So static data and stuff is kinda the opposite of the idea of a DLL.


Hope enough of this is understandable.

As Dr. Who says,

"Did you understand all that?"
(yes)
"Oh, would you mind explaining it to ME sometime?"

--Brandon Bergren

> 
> -- 
> Benoit Minisini
> mailto:gambas at ...1...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel