#Mac/Win crosspltform Dev
8 messages in this thread
Again, I find you misrepresenting Microsoft and, this time, adding
Windows development.
I have been programming professionally on the Macintosh for five years
with a wide variety of tools (MPW Assembly/C/C++/Pascal, THINK
C/C++/Pascal, the TCL, MacApp, AppMaker, HyperCard/SuperCard, The
Debugger, and more) for an incredibly wide variety of software
solutions (LDEF, WDEF, and the whole DEF family, INITs, cdevs, rdevs,
applications, externals, databases, networking, and more). Early
last year I "broke thru Windows" by writing several import and export
DLLs for CorelMOVE (part of CorelDRAW). This is what _I_ found to be
the truth:
1) I don't need Jasik's debugger to debug non-application software —
CodeView will provide source level debugging for me.
2) I don't need to ask Microsoft any questions — their online help
system is exhaustive, and their sample code is practical and useful.
3) Windows doesn't go down when my application does — proper use of
protected memory (though, admittedly, not perfect).
4) MSVC is a better development tool than anything available on the
Mac — and MFC is getting better and better (not designed nor
implemented by one person, like the TCL and Power Plant).
5) The Windows API better facilitates "hooks" into which I can
provide customized features — no need for trap patches.
6) Windows' windows provide a natural "view" hierarchy which helps
when using non-object languages — no need for the MFC, MacApp, the
TCL, or Power Plant.
7) Microsoft gives me more than I need on their "E.T.O." equivalent —
I'm able to view any and all technologies with no problem.
8) I'm a better software engineer today because I now am competent on
two platforms — go to the bookstore and compare the technologies
exemplified in books and magazines in DOS/Windows research to that of
Macintosh (there _is_ no comparison).
9) enough already!
The biggest problem with Windows development is the memory model issue
– which do you use? That is being addressed with Win32s, Win32c,
Chicago, and, of course, NT. For Window 3.1 it's a necessary evil.
By years' end this will be coming to a well deserved death.
I love Macintosh. I like Windows. However, based on my experiences
I'd rather program under Windows than the Macintosh, and I'm nearly
as productive under both (with Windows being slightly lower due to a
5-to-1 ratio of experience).
Just my opinion…
>> Just my opinion…
By all means, please develop for Windows!
>> enough already!
Agreed!
Neil,
"By all means, please develop for Windows!"
My current project is a MacApp-based multimedia project!
Cheers,
David
I'm a multiplatform guy, too. I'll second your comments about the quality of
Microsoft's development tools. And then there's the price: I just dropped
$1300 on E.T.O, and got less stuff than I got from Microsoft for $400.
BTW, I saw that you work for Corel, and worked on CorelMOVE. I was one of the
original developers of the program once known as Harvard Draw for Windows,
which is now the F/X applet in Harvard Graphics for Windows. We sold this to
SPC several years ago. I consulted for them until late 1992 as the "import /
export guy", supporting file format DLLs. I also worked closely with
Imagemark, another well-known 2D file filter DLL company.
Apart from this work, I have a company called Syndesis that makes 3D file
format translators. We've been in the Amiga market since 1987. Some of our
translators are licensed in the Video Toaster. We're about to release the
WinNT / Win32s version of our translator program known as InterChange. We
translate between 3D formats such as AutoCAD DXF, Wavefront, 3D Studio,
Softimage, LightWave, Imagine, etc.
We recently started porting our code to the Mac. We've worked very hard at
code and architecture portability, and it's paying off. Several megs of code
are compiling cleanly on the Mac with no more than a few days' effort.
So, I'm very interested in hearing about your experiences in "comparative
anatomy" regarding DLL-like entities on the Mac versus Windows. ASLM doesn't
cut it, huh? What might be the best way for us to do Win-DLL-like things on
the Mac? Have you seen the freely distributable "XPIN" plug-ins in the library
here?
John,
>> ASLM doesn't cut it, huh?
It's history anyway. It's being replaced by SOM from IBM's technologies.
Neil Ticktin
Editor-in-Chief
MacTech Magazine
(formerly MacTutor)
John,
"BTW, I saw that you work for Corel, and worked on CorelMOVE."
I did work for Corel, but did not work _at_ Corel (nor would I!). It was
contract work for the company I used to work at.
"So, I'm very interested in hearing about your experiences in "comparative
anatomy" regarding DLL-like entities on the Mac versus Windows. ASLM doesn't
cut it, huh? What might be the best way for us to do Win-DLL-like things on
the Mac? Have you seen the freely distributable "XPIN" plug-ins in the library
here?"
Well, I've not yet written any ASLM/CFM-based code. However, it seems highly
possible that the APIs between ALSM/CMF-based code could mimic that of DLLs,
thereby producing the highest yield of coding time invested.
David
David,
<
Well, I've not yet written any ASLM/CFM-based code. However, it seems highly
possible that the APIs between ALSM/CMF-based code could mimic that of DLLs,
thereby producing the highest yield of coding time invested.
>
Actually, the aslm is really a subset of the CFM, and you'll have to implement
the aslm stuff all over again for the CFM, since the ASLM isn't native quite
yet. The ASLM isn't quite there as compared to windows DLLs, which are pretty
happening overall. Apple, seems to have learned from windows about dll version
problems, which is a plus. As a negative, you can't export random chunks of
code out of your application and use them from within an aslm library, which
you can do with the cfm (I think).
Manuel
David,
> 1) I don't need Jasik's debugger to debug non-application software — >
CodeView will provide source level debugging for me. > > 2) I don't need to ask
Microsoft any questions — their online help > system is exhaustive, and their
sample code is practical and useful. > > 4) MSVC is a better development tool
than anything available on the > Mac — and MFC is getting better and better
(not designed nor > implemented by one person, like the TCL and Power Plant). >
> 5) The Windows API better facilitates "hooks" into which I can provide >
customized features — no need for trap patches. > > 7) Microsoft gives me more
than I need on their "E.T.O." equivalent — > I'm able to view any and all
technologies with no problem. > > 8) I'm a better software engineer today
because I now am competent on > two platforms — go to the bookstore and
compare the technologies > exemplified in books and magazines in DOS/Windows
research to that of > Macintosh (there _is_ no comparison).
I am also a professional Mac/Windows developer for 6+ years, I agree 100% with
your above comments. In last year's MS Professional Developer Conference
93(very similar to Apple's WWDC…..only better and less religion/marketing BS
stuff…:-)), MS do reveal their VC++ V2.0 multi-platform plan. I suggest you
to GO WINBTU/WINDEV to join the Chicago PDK beta and maybe you can also get the
beta of VC++ V2.0.
Some people just love to live in the MPW/MacApp/Sym_C++/CW world and refuse to
understand "the other side"…… this is fine but I think MS VC 2.0 will
change the situation a LOTS!
Steve