Luke-Jr wrote:
> Hmm... How about branching off JUST enough so it's not Windows-specific?
> For example, have programs refer to .so (I /THINK/ this is the *nix
> equivalent) instead of .DLLs and just temperarally ignore that Windows
> API using programs will break?
> And instead of OCXes, something else (does X have a similar
> component?)...
I know that other groups have tried implementing M$'s DB scheme on UNIX
(most notable, the StarOffice Suite), but have had a miserable time at
it. You could check the StarOffice source, I think that their MDB stuff
is still in there, although it's probably "IFDEF"'d out so it doesn't
compile in. In order to implement this we would most definitely have to
build an ODBC/DSN system for UNIX, and that would, IMHO, detract from
the otherwise noble goal of bringing a really-cool rapid application
development language/interface to the Linux/UNIX world. I guess it comes
down to do you want 95% of Windows-built VB apps to work 80% of the
time, or 80% of the Windows-built VB apps to work 95% of the time. :) I,
personally, think offering *nix database support using the same VB DB
interface is a far more noble/better goal, than offering M$DB support,
but then again, I'm biased. ;)
X itself has no OCX-equivalent, however the GTK programming language
does have a very OCXish object file model. .so's are, more or less, the
equivalent to .DLL's, the problem is that the only place where they are
used, really, is within the kernel and operating system. Apache web
server has .so support, and a couple of other packages, but most UNIX
apps prefer static linking libraries to dynamic ones.
--
Matthew Keller
Enterprise Systems Analyst
Computing & Technology Services
Information Services Division
State University of New York at Potsdam
Website: http://mattwork.potsdam.edu/
PGP: http://mattwork.potsdam.edu/crypto/
|