Banana said:
Interesting. I thought it was Windows component because it was a
MDAC component.
It's a Windows component because Active Directory uses it for
interacting with its data store (though that's the *other* Jet
format, not our familiar one; the details of that are not clear to
me, i.e., why they'd install the Jet Red engine to interact with a
Jet Blue data store is beyond me, but perhaps it's because of the
extreme versatility of Jet Red in interacting with all kinds of
data).
But the core point remains- there was more than one teams
involved which complicated the evolution. At least that's what I
hear cited as explanation for Jet's stagnation between 2000-2007
version.
There were *not* two teams involved, but only one. The issue was who
got control of it.
Also, keep in mind that the time frame when Jet was transferred to
the Windows team (by 1999, the release of both Windows 2000 and
Access 2000) was also the time frame when the fancy new Windows File
System based on SQL Server was planned. Why would Access need the
humble Jet database engine if the OS used SQL Server as a built-in
component?
That all turned out to be impossibly complicated and the WinFS was
abandoned, so there was no fall-back to replace Jet. I don't think
this is the sole reason that Access got its own private version of
Jet, but I do believe it's the reason MS thought it was OK to move
control of Access's traditional default database engine to another
development group.
I would agree that the porting Access is much bigger task than
Excel and I don't think it's all about VBA but also Access
objects. We know that Access controls is quite different from
controls used in MFC or .NET or whatever framework Windows
programmers may use and I remember running across an old post
claiming that Access controls are not derived from Windows
controls,
That's right. An Access control only has a window handle when it has
the focus. This is a design dating to the original implementations
of Access, back in the days of Windows 2.x and 3.x, when system
resources were so limiting that giving a window handle to every
control onscreen would have simply brought Access and Windows to a
screaming halt.
so getting those custom controls (if they are indeed
custom) will be much more of a challenge. Looking quickly in my
Mac Excel, I can create a UserForm so at least _part_ of work is
done. How much that is, I don't know but I'd wager not much!
I think standard Access forms/reports/controls would be a problem on
the Mac.
However, I don't think file system is really a significant barrier
because many applications has solved this problem by specifying
their own format and writing/reading it in the same format across
platform.
Hardwired into Jet are assumptions about how the file system
behaves. You can virtualize a Windows file system, but I don't know
how reliable it is under the hood. I simply don't trust it myself,
but it appears to be OK, since a lot of people are storing Jet
database on Samba servers and are not having corruption (so far as I
hear).
For example, you can port a MySQL data file between a
little-endian platform to a big-endian platform with no issue
because MySQL libraries enforce their own endianness in the file
and read it using their own specified endianness. There may be
other solutions I haven't heard of, but I would think that the
filesystem is less of a problem.
But that's quite a different situation. MySQL talks to the file
system and doesn't poke into the internal workings of file access.
My understand is that Jet crosses that line. That's not a great
thing, actually, but like the window handle-less Access controls,
it's likely a performance decision made back in the early days of
Jet.
Perhaps I'm incorrect on the details but at least we do agree that
the project will be far from trivial.
Certainly. I think it's complex enough to not be worth attempting.
Never say never.
In my POV, I actually thought that Mac Office were predominantly
used by students & at home and actually expected the VBA removal
to go all way the forward. I was shunned & surprised that there
was sufficient outcry from Mac users that they had to reverse the
removal of VBA. From what I gather, there are in fact business
users who may use Mac but need compatibility with VBA-driven Excel
spreadsheets or Word documents to share with their Windows
fellows.
Yep. Lots and lots of Mac users at home are Windows users by day.
If such cases exist in sufficient numbers to reverse a policy at
MS, I don't see why it can't hurt to at least ask for eventual
port, even if only a runtime for end users for cases where web
applications isn't the right or ideal solutions. I wouldn't be
surprised if the answer is still no, but what good does it do if
the question is never ever asked of the teams? I'm pretty sure
they don't have a crystal ball, after all.
Well, re-incorporating something that has been taken out is a very
different proposition than implementing it the first time, so I just
don't think it's comparable at all. On the other hand, without VBA
on Mac Office, it would be even less unlikely that Access could ever
be ported. But VBA on Mac is one of those "necessary but
insufficient" conditions -- it would be required but by itself
doesn't come close to enabling the port as a whole.
Furthermore, Mac Office has long used Entourage as a counterpart
to Outlook.
....and Entourage is being phased out because it's a pile of crap
that Mac users hate and only use because they work in an Exchange
environment.
I now understand they're dropping Entourage and working on
releasing an Outlook for Mac trying to achieve parity between
those platforms. Basically, it seems that MacBU are working on
achieving parity as opposed to merely having a comparable but
fundamentally different programs.
I think the replacement of Entourage with Outlook is a response to
the rejection of Entourage by Mac users more than it is a reflection
of MS's cross-platform compatibility concerns. After the MacWord 6
debacle (where WinWord6 was clumsily ported to Mac OS without
honoring the conventions of Mac applications), MS changed its
approach to the Mac versions of its applications. Without that
change, Entourage never would have existed. The abandonment of it in
favor of a Mac version of Outlook does not indicate a change, as I'm
sure Outlook for Mac will be quite different from the Windows
version in ways that reflect native Mac conventions.
Regarding FileMaker, I wouldn't necessarily that they have the
market sewn up -- they only have by the virtue of having no
serious competitor on Mac OS X. Not really a compelling argument.
Furthermore, unlike Access, FileMaker isn't a part of any kind of
bundle so to use it you have to buy licenses. Have you seen their
matrix? I'm having a hell of time figuring out what I need to buy
for what feature sets.
I haven't looked recently. If they've overcomplicated it, they are
shooting themselves in the foot.
But the first-to-market advantage is pretty important, and the
market share of Macs so small that it's not necessarily worth it to
invest in a huge project like porting Access would be. If FM were
not so entrenched and not such a versatile product (despite its
deficiencies in comparison to Access, it's still a pretty compelling
development platform as well as a marvelous end-user tool), then
perhaps it would be worth it for MS to attempt to capture that
market.
But as it is, I would say porting Access to Mac would simply not be
even close to profitable for MS, either on its own terms or as part
of a larger agenda to freeze out other Office suites.
Interesting. Can't speak to Parallels, as I only use VMWare but
I've been very happy with it, seamlessly sharing clipboard &
dragging'n'dropping files between worlds. The most significant
pain I had was with the I/O contention which a spare hard drive
fixed. I don't get the concern about the filesystem as VM uses
images which itself is then formatted as NTFS.
But that is stored on top of a Mac file system (I addressed that
issue above, actually).
I've yet to see any kind of corruption or bad
things from filesystem even though I've been this for 3 years, and
considering that I do development against Access and SQL Server as
well experimenting with Visual Studio & Sharepoint on it, I'd like
to think I'd have already seen it by then.
Like I said, I'm aware that there aren't reports of problems, but,
hey, I remember the bookmark bug, which had existed for years and
years before someone was able to figure out a reproducible scenario.
In that case, there were so many factors involved and so many
alternate explanations for the problems it caused that it was just
extremely difficult to pin down. I would expect problems with Jet
running on a virtualized file system to be equally subtle (i.e., I
wouldn't expect outright corruption). I just think it's easier to
avoid the possibility that something may go wrong and insist on
non-virtualized native Windows file systems. For now, that's not a
big deal, but I do expect that in the next decade, virtualized file
servers will become the norm at all levels and not just in big
enterprises. But I don't know if Jet as we know it will still be in
wide use, so it may not be an issue.
