Searching \ for '[OT]: How do you do a callback in a Windows DLL?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=how+you+callback
Search entire site for: 'How do you do a callback in a Windows DLL?'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: How do you do a callback in a Windows DLL?'
2003\11\23@092741 by Byron A Jeff

face picon face
I started this message the other day, but I don't think that I actually posted
it. So apologies if this is a repost.

One of my students is doing a port of picprg to Windows for a semester
project. picprg is Brian Lane's Linux software for programming PICs using
Tait style programmers hanging from the parallel port, such as my Trivial
Programmer. Our alpha version is working and we're planning on releasing an
interim version just as soon as the code to save the config settings is done.

The next stage is updating the programming algorithms so that all of the chips
that folks really want to use (18F, 16F819, 16F88, 16F648A, 16F87XA) can be
programmed. Our game plan is to separate each of the program/read/verify
routines into a DLL. That way a new programming algorithm can be included by
downloading a new DLL.

In order to maintain dual system compatibility, we are compiling with the
MingW GCC compiler which has a compatibility layer for translating Unix
specific calls into Windows equivalents. The DLL builder works fine BTW.

So here's the problem. The programming software is divided into a set of low
level routines that twiddle the parallel port (vpp_on, bit_on, bit_off and the
like), and the high level routines that read/program the chip using the low
level routines. Since the low level routines are used by every programming
algorithm, and are used for auto chip detection, we are trying to keep these
in the main executable, only moving the high level routines to the DLLs.

The problem is how do you make callbacks into the main application's low level
routines from the high level routines in the DLL? Quick example:

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

void vpp_on()
{
  // Code to turn the vpp bit on
}

main()
{
  // Load the DLL
  read_pic(); // A routine in the DLL
}
-----------------------------------

-----------testdll.c---------------
int read_pic()
{
  // Read the chip. Calls vpp_on
  vpp_on();
  // ....
}
------------------------------------

Under Linux it's possible to tell the linker to export symbols from the main
executable so that they are visible from loaded shared libraries. So the
routine set above works fine. main calls read_pic int testdll and testdll does
a callback to vpp_on in the main executable.

The documentation I've read on DLLs talks about import/export tables that
defines what the DLL uses or provides. But I can't find anything that talks
about an export table for an executable, only DLLs.

I have my backup solution if I can't figure out how to do this: take the low
level routines and put them in a separate DLL that's linked to the application.
Since the DLL can have a export table, when the high level DLL is loaded, the
exported symbols from the low level DLL should be visible to it, so that
these routines can be called.

Any suggestions on this would be appreciated. It's one of those situations
where I know what I want to do, I figure it can be done, but I just don't
program in Windows enough to figure out how to do it.

Thanks,

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@094443 by Wouter van Ooijen

face picon face
Why not use a second DLL that contains the common code?

But why use a DLL at all? Downloading a new application executable is
simple enough in these internet times, and it realy keeps things simple.
Or try to put most programming aspects in a (user-changeable) text file
that is read by the program.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@145033 by Mike Singer

picon face
Byron A Jeff wrote:
++++++++++++++++++++++++++++++
...The next stage is updating the programming algorithms so that all of
the chips
that folks really want to use (18F, 16F819, 16F88, 16F648A, 16F87XA) can
be
programmed. Our game plan is to separate each of the program/read/verify
routines into a DLL. That way a new programming algorithm can be
included by
downloading a new DLL.
...
So here's the problem. The programming software is divided into a set of
low
level routines that twiddle the parallel port (vpp_on, bit_on, bit_off
and the
like), and the high level routines that read/program the chip using the
low
level routines. Since the low level routines are used by every
programming
algorithm, and are used for auto chip detection, we are trying to keep
these
in the main executable, only moving the high level routines to the
DLLs...
++++++++++++++++++++++++++++++

Visual Studio 6 or VS.NET are you developing with?
And carefully use "callback" word.  Callbacks are used for
multithreading,
say, when ActiveX EXE need to launch  some Sub in main EXE.
You are talking about only DLL - in-process creatures. They are known
to fire events in the main App.

Under Visual Studio 6 I'd recommend to wrap chip-specific programming
matters into stand-alone ActiveX EXE with very basic forms just to test
programming process; so anybody could see if this thing works at all.
And User Interface should be created in any other way, say, the main
EXE windows App, or MS Office to control that ActiveX EXE.

Regards,

Mike.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@163814 by Byron A Jeff

face picon face
On Sun, Nov 23, 2003 at 03:43:13PM +0100, Wouter van Ooijen wrote:
> Why not use a second DLL that contains the common code?

I listed that as my backup option.

> But why use a DLL at all? Downloading a new application executable is
> simple enough in these internet times, and it realy keeps things simple.

Two reasons: Simplifying the code management aspect of a bunch of different
algorithms, and limiting what's loaded.

> Or try to put most programming aspects in a (user-changeable) text file
> that is read by the program.

Because it's a lot more difficult the track data than it is to track code.
The fact of the matter is that a programming algorithm is an algorithm, which
means that it naturally translates to code. In addition the current algorithms
are implemented as code, so the infrastructure is already in place while
switching to a data driven technique requires a total rewrite.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@164433 by Byron A Jeff

face picon face
On Sun, Nov 23, 2003 at 09:49:17PM +0200, Mike Singer wrote:
> Visual Studio 6 or VS.NET are you developing with?

Neither. I'm using the MingW GCC crosscompiler so that I can generate the
Windows executable from an essentially unmodified Linux based source.

> And carefully use "callback" word.  Callbacks are used for multithreading,
> say, when ActiveX EXE need to launch  some Sub in main EXE.
> You are talking about only DLL - in-process creatures. They are known
> to fire events in the main App.

I need to do what you described the AX EXE doing above, except I need to do it
from a DLL.
>
> Under Visual Studio 6 I'd recommend to wrap chip-specific programming
> matters into stand-alone ActiveX EXE with very basic forms just to test
> programming process; so anybody could see if this thing works at all.
> And User Interface should be created in any other way, say, the main
> EXE windows App, or MS Office to control that ActiveX EXE.

To reiterate the question: When I load a DLL, the DLL's symbols are visible
to "the main EXE windows App" as you call it. However the reverse is not true:
symbols in the main EXE windows App are not visible to the DLL. How can I make
that happen?

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@174148 by Denny Esterline

picon face
(!@#$%^& outlook ate the tag...)

> Just a thought, Why not put the low level stuff into it's own DLL? I
> would think that would leave the option of using different low level
> routines for different hardware.
>
> You mentioned Tait style parallel programmers, but what about JDM
> serial programmers, or some future USB or other programmers? I think
> we're all aware that the parallel port is quickly becoming obsolete
> (if not already), if your software only works with a p-port it'll be
> obsolete before it's finished.
>
> -Denny
>
> > I started this message the other day, but I don't think that I
> actually posted
> > it. So apologies if this is a repost.
> >
> > One of my students is doing a port of picprg to Windows for a
> semester
> > project. picprg is Brian Lane's Linux software for programming
PICs
> using
> > Tait style programmers hanging from the parallel port, such as my
> Trivial
> > Programmer. Our alpha version is working and we're planning on
> releasing an
> > interim version just as soon as the code to save the config
settings
> is done.
> >
> > The next stage is updating the programming algorithms so that all
of
> the chips
> > that folks really want to use (18F, 16F819, 16F88, 16F648A,
16F87XA)
{Quote hidden}

fine
> BTW.
> >
> > So here's the problem. The programming software is divided into a
> set of low
> > level routines that twiddle the parallel port (vpp_on, bit_on,
> bit_off and the
> > like), and the high level routines that read/program the chip
using
> the low
> > level routines. Since the low level routines are used by every
> programming
> > algorithm, and are used for auto chip detection, we are trying to
> keep these
> > in the main executable, only moving the high level routines to the
> DLLs.
> >
> > The problem is how do you make callbacks into the main
application's
{Quote hidden}

from
> the main
> > executable so that they are visible from loaded shared libraries.
So
> the
> > routine set above works fine. main calls read_pic int testdll and
> testdll does
> > a callback to vpp_on in the main executable.
> >
> > The documentation I've read on DLLs talks about import/export
tables
> that
> > defines what the DLL uses or provides. But I can't find anything
> that talks
> > about an export table for an executable, only DLLs.
> >
> > I have my backup solution if I can't figure out how to do this:
take
> the low
> > level routines and put them in a separate DLL that's linked to the
> application.
> > Since the DLL can have a export table, when the high level DLL is
> loaded, the
> > exported symbols from the low level DLL should be visible to it,
so
> that
> > these routines can be called.
> >
> > Any suggestions on this would be appreciated. It's one of those
> situations
> > where I know what I want to do, I figure it can be done, but I
just
{Quote hidden}

topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other
[BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@174549 by Bob Barr

flavicon
face
On Sun, 23 Nov 2003 16:43:17 -0500, Byron A Jeff wrote:

<snip>
>
>To reiterate the question: When I load a DLL, the DLL's symbols are visible
>to "the main EXE windows App" as you call it. However the reverse is not true:
>symbols in the main EXE windows App are not visible to the DLL. How can I make
>that happen?
>

IIRC, typically the address of the function to be 'called back' is
passed as a "pointer to function" parameter. The subroutine being
called can then use that address whenever it needs to invoke some
function in the calling code's scope.

I've seen this mechanism implemented on several multi-threaded systems
that I've worked with but I can't say for certain that this is allowed
with a Windows DLL.


Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@180911 by William Chops Westfield

face picon face
On Sunday, Nov 23, 2003, at 06:26 US/Pacific, Byron A Jeff wrote:
> So here's the problem. The programming software is divided into a set
> of low
> level routines that twiddle the parallel port (vpp_on, bit_on, bit_off
> and the
> like), and the high level routines that read/program the chip using
> the low
> level routines. Since the low level routines are used by every
> programming
> algorithm, and are used for auto chip detection, we are trying to keep
> these
> in the main executable, only moving the high level routines to the
> DLLs.
>
> The problem is how do you make callbacks into the main application's
> low level
> routines from the high level routines in the DLL?

It sounds a bit backward to me - libraries generally contain the low
level functions, rather than calling low-level functions in the main
code.  So making the low level functions another library seems to make
sense (a DLL is still a
library, right?)

However, you COULD use pointers to functions...  sorta standard
run-time linkage, I guess:

in the DLL:

static int (*v_vpp_on)(int) = uninitialized_vector_error;
#define VPP_ON(i) (*(v_vpp_on)(i))
static int (*v_bit_on)(int) = uninitialized_vector_error;
#define BIT_ON(i) (*(v_bit_on)(i))
static int (*v_bit_off)(int) = uninitialized_vector_error;
#define BIT_OFF(i) (*(v_bit_off)(i))

void initialize_vectors (int (*f_vpp)(int) f_vpp, int (*f_vpp)(int)
f_on,
                         int (*f_vpp)(int) f_off)
{
    v_vpp_on = f_vpp;
    v_bit_on = f_on;
    v_bit_off = f_off;
}


BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@201149 by Mike Singer

picon face
Byron A Jeff wrote:
> > Visual Studio 6 or VS.NET are you developing with?
>
> Neither. I'm using the MingW GCC crosscompiler so
> that I can generate the Windows executable from an
> essentially unmodified Linux based source.

I'm sure that developing the production software with
non-MS crossplatform tools is rather delicate work that
will get you into a lot of unpredictable troubles.
Better save your students time for doing other stupid
things, student's specific stupid things: drinking beer
for example :-)

Mike.

P.S. Is not Visual Studio 6 Learning Edition free for
students?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@202358 by Byron A Jeff

face picon face
On Mon, Nov 24, 2003 at 03:10:15AM +0200, Mike Singer wrote:
> Byron A Jeff wrote:
> > > Visual Studio 6 or VS.NET are you developing with?
> >
> > Neither. I'm using the MingW GCC crosscompiler so
> > that I can generate the Windows executable from an
> > essentially unmodified Linux based source.
>
> I'm sure that developing the production software with
> non-MS crossplatform tools is rather delicate work that
> will get you into a lot of unpredictable troubles.

Actually it was a tool that facilitated porting a working piece of software
to another platform by adding little more that the Windows specific I/O port
DLL.

> Better save your students time for doing other stupid
> things, student's specific stupid things: drinking beer
> for example :-)
>
> Mike.
>
> P.S. Is not Visual Studio 6 Learning Edition free for
> students?

Irrelvant because then the app would require a total rewrite to work.
The specific task was to create a crossplatform application from a single
codebase. If you switch to VS, it's the VS way or the highway.

Also VS certainly isn't free for non students and there actually may be
a developer or two who may want to work on this.

We have a tool that does the job exactly the way we want it done. It would
be stupid to switch, not the other way around.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@202812 by Byron A Jeff

face picon face
On Sun, Nov 23, 2003 at 02:43:51PM -0800, Bob Barr wrote:
> On Sun, 23 Nov 2003 16:43:17 -0500, Byron A Jeff wrote:
>
> <snip>
> >
> >To reiterate the question: When I load a DLL, the DLL's symbols are visible
> >to "the main EXE windows App" as you call it. However the reverse is not true:
> >symbols in the main EXE windows App are not visible to the DLL. How can I make
> >that happen?
> >
>
> IIRC, typically the address of the function to be 'called back' is
> passed as a "pointer to function" parameter. The subroutine being
> called can then use that address whenever it needs to invoke some
> function in the calling code's scope.

Similar to the process of accessing symbols of a hand loaded DLL. I could
live with that, but there are about a dozen symbols that would need to be
mapped.

I guess I got spoiled because the GNU linker has an option that exports
symbols from an executable, so when a shared library is loaded, any symbols
used by the shared library that's in the main executable are automatically
linked. I was just trying to find similar functionality.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@203227 by Byron A Jeff

face picon face
On Sun, Nov 23, 2003 at 05:41:20PM -0500, Denny Esterline wrote:
> (!@#$%^& outlook ate the tag...)
>
> > Just a thought, Why not put the low level stuff into it's own DLL? I
> > would think that would leave the option of using different low level
> > routines for different hardware.

That's my backup thought, and the option of using different hardware interfaces
is interesting.

> >
> > You mentioned Tait style parallel programmers, but what about JDM
> > serial programmers, or some future USB or other programmers? I think
> > we're all aware that the parallel port is quickly becoming obsolete
> > (if not already), if your software only works with a p-port it'll be
> > obsolete before it's finished.

It's obsolete now. However I still have folks actively building and using my
Trivial programmer. So I'm just trying to support it. It's really sad that
Parallel and Serial Ports are dying. Simple, well known, and easy to use
hardware interfaces such as those will be sorely missed in the coming years.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@203436 by Byron A Jeff

face picon face
On Sun, Nov 23, 2003 at 03:08:42PM -0800, William Chops Westfield wrote:
{Quote hidden}

Right.

>
> However, you COULD use pointers to functions...  sorta standard
> run-time linkage, I guess:

I was looking for a magic bullet that would auto link when the DLL was loaded

{Quote hidden}

I think I'll simply package the low level stuff into an autolinked DLL
so that the symbols are visible to the high level DLL when it is loaded.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@214156 by William Chops Westfield

face picon face
On Sunday, Nov 23, 2003, at 17:33 US/Pacific, Byron A Jeff wrote:
>
> I think I'll simply package the low level stuff into an autolinked DLL
> so that the symbols are visible to the high level DLL when it is
> loaded.

I'm not entirely sure what the point of using a DLL is in the first
place.
For most people, its more difficult and mysterious to update just a DLL
than to update a full executable.  DLLs and executables always seem to
have
ways of getting out of sync with one another :-(

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\23@214404 by William Chops Westfield

face picon face
On Sunday, Nov 23, 2003, at 17:10 US/Pacific, Mike Singer wrote:
>
> I'm sure that developing the production software with
> non-MS crossplatform tools is rather delicate work that
> will get you into a lot of unpredictable troubles.
>
I certainly hope not.  In the absence of intensive GUI development, I
don't think that even microsoft is THAT gratuitously incompatible.

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\11\24@001735 by Herbert Graf
flavicon
face
> Irrelvant because then the app would require a total rewrite to work.
> The specific task was to create a crossplatform application from a single
> codebase. If you switch to VS, it's the VS way or the highway.
>
> Also VS certainly isn't free for non students and there actually may be
> a developer or two who may want to work on this.
>
> We have a tool that does the job exactly the way we want it done. It would
> be stupid to switch, not the other way around.

       I don't know if I'd go so far as calling it stupid, however I most
certainly agree that moving from an open and perfectly functional platform
to a closed crippled platform like VS is NOT a good idea. I have always
stayed away from MS development tools because of the "you're stuck" factor,
once you get used to doing it the MS way, which of course doesn't work with
any NON MS stuff, it's hard to switch. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\11\24@051234 by Mike Singer

picon face
Herbert Graf wrote:
>        I don't know if I'd go so far as calling it stupid, however
>  I most certainly agree that moving from an open and perfectly
> functional platform to a closed crippled platform like VS is
> NOT a good idea. I have always stayed away from MS
> development tools because of the "you're stuck" factor,
> once you get used to doing it the MS way, which of course
> doesn't work with any NON MS stuff, it's hard to switch. TTYL


  Byron has made a decision already: he'll sell the software
to those unfortunate men who "are stuck" at MS Windows,
old, current and future versions.
  If you're to sell the software, you must guarantee
Max compatibility; I doubt that cross-platform development
tools  could help this much (did he tell he wanna use system
Windows things, DLLs, callbacks and all?) .

  Just market considerations, not an attempt to glorify MS.

Mike.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\11\24@081918 by Bob Ammerman

picon face
This is really very simple:

Step 1: The main program calls an initialization point in the DLL, passing a
pointer to a structure containing the addresses of all the routines of
interest.

Step 2: The DLL uses the pointer to call the routine.

In more detail:

in a header file common to the main code and the DLLs:

typedef struct HelperFuncs {
      void (*one_function)(int something, char another);
      int (*another_function)(void);
   ... etc ...
};

In the main program:

void (*one_function)(int something, char another);
int (*another_function)(void);

struct HelperFuncs  helpers = {
   one_function,
   another_function
};

InitializeDLL( ..., &helpers, ... );

In the DLL:

struct HelperFuncs *hf;

void InitializeDLL(..., struct HelperFuncs &helpers, ... )
{
   hf  = helpers;
}

(hf->one_function)(123,'a');
i = (hp->another_function)();

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\11\24@090326 by Byron A Jeff

face picon face
On Mon, Nov 24, 2003 at 08:17:33AM -0500, Bob Ammerman wrote:
> This is really very simple:
>
> Step 1: The main program calls an initialization point in the DLL, passing a
> pointer to a structure containing the addresses of all the routines of
> interest.
>
> Step 2: The DLL uses the pointer to call the routine.
>
> In more detail:

[Snipped]

Thanks Bob. I knew that actual pointer passing was always in the cards. I
was really hoping that there was some automatic symbol linking that could
be specified like two DLLs can automatically link to one another.

I think I'll take a stab at the two DLL technique first. If that doesn't work
I'll fallback to function pointer passing.

Thanks again,

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\11\24@164536 by Bob Ammerman

picon face
I already answered this once, but here is another way....

A DLL can see a symbol in the main app. It just can't dynamically link to
it.

If you the Windows API

GetProcAddress( HANDLE hModule, "NameOfFunction") you can retrieve the
address of the function in the main program.

The main program can supply its 'hInstance' as the value for the DLL to use
for hModue in calls to GetProcAddress.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\11\24@200129 by Byron A Jeff

face picon face
On Mon, Nov 24, 2003 at 12:10:05PM +0200, Mike Singer wrote:
> Herbert Graf wrote:
> >        I don't know if I'd go so far as calling it stupid, however
> >  I most certainly agree that moving from an open and perfectly
> > functional platform to a closed crippled platform like VS is
> > NOT a good idea. I have always stayed away from MS
> > development tools because of the "you're stuck" factor,
> > once you get used to doing it the MS way, which of course
> > doesn't work with any NON MS stuff, it's hard to switch. TTYL
>
>
>    Byron has made a decision already: he'll sell the software
> to those unfortunate men who "are stuck" at MS Windows,
> old, current and future versions.
>    If you're to sell the software, you must guarantee
> Max compatibility; I doubt that cross-platform development
> tools  could help this much (did he tell he wanna use system
> Windows things, DLLs, callbacks and all?) .
>
>    Just market considerations, not an attempt to glorify MS.

Who said anything about selling? The software is Open Source. It's free in
both senses of the word.

And since the source is available, no one is "stuck" with any version at all.

I have no interest in selling a student built product.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...