Tue, Nov 26, 7:49 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 26 1:43 pm)



Subject: Shoul PC users be nice to the MAC user or do thay have them self to blame?


HellBorn ( ) posted Thu, 28 October 1999 at 3:41 PM · edited Tue, 26 November 2024 at 7:40 PM

About 80 per cent of computerusers are running on "PC"s. So writing programs in a "Windows only" language comes natural. Should we PC users install languages such as JAVA TCL/TK in our computers just to be "nice" to the MAC users? I can't say that I have seen anyting created from MAC users here, exept from maybe a program converting things from PC to MAC. At the moment I have the option to write in Visual Basic or TCL/TK(runs on Windows Mac and Unix). Writing in JAVA doesn't interest me at the moment because I'm not so good at it yet. What's your opinion on this matter?


JeffH ( ) posted Thu, 28 October 1999 at 4:08 PM

Well, IMO, you write programs for the people you want to use them. I would hope that would include the two major operating systems. Some of the best 3D artists I've seen are on the MAC platform. -Jeff H. PC User


MartinC ( ) posted Thu, 28 October 1999 at 4:12 PM

I kept silent on this place here, but before this one is going to start another holy war, I'd like to get some things straight. 1) There is no "Windows only" language, there are just "Windows only" compilers. 2) JAVA is no "Mac language" - the opposite is true. Apple was very slow in supporting it, and we are still waiting for 1.2 or 2.0 or whatever its called. 3) There is only one Java program that I know, John Wind's excellent Compose. And that one was a nightmare on Mac, it was just enabled to run on a Mac some weeks ago for the first time. 4) You won't see Macintosh creators here because they are all so nice to post their stuff as .zip and not as .sit (which is typically smaller, by the way). This prevents the PC users from the trouble of installing a separate expander. 5) The converter not only converts PC to Mac, it also converts Mac to PC in order to make the files completely look like PC originals. Hmm... thinking about 5) I probably should dump this feature and turn it into a "this file will never never perform on a PC" conversion in order to get Macs better identified? (don't worry, just joking)


JeffH ( ) posted Thu, 28 October 1999 at 4:35 PM

Before this gets out of hand remember, make your point, but be civil about it. Thanks, -Jeff H.


matlock ( ) posted Thu, 28 October 1999 at 5:00 PM

Hey, everybody to do a lot with Poser (and other IMPORTANT 3D soft) knows that 20 % of users are Mac, not the other way round): so there are converters for converting PC to Mac, but I as a Pc user would love to give away ready-made stuff to the Mac crowd. So what ? No way. Those progs all run on Macs only. I understand why, still - Guys, thats racism ! Us PC bastiches would sure love to be compatible to you, too... but were too dumb to program this... or is there ANYBODY OUT THERE ??? Time for a decent folk to turn macho bout this !


MartinC ( ) posted Thu, 28 October 1999 at 5:25 PM

You can use the (very few) "Mac only" .sit files, you only have to get the expander for it. It is at http://www.aladdinsys.com/expander/index.html in a Windows version. The extracted files will have some restrictions - mainly missing thumbnail pictures. I think you can live with this, Mac users lived with it for a very long time. The reason why you can't create Mac versions on a PC are the different file systems. The Mac file system has some additions which the PC structure can't setup. Sorry for that. It's not my fault. And just to make it very clear: My remark to 5) was a joke. As in :-) I will never do such a nasty thing. Honestly!


HellBorn ( ) posted Thu, 28 October 1999 at 6:35 PM

Maybe the fact that English isnt my main language makes room for misunderstandings here! 1. Well a development tool that only develops Windows GUI and as far as I now only runs on Windows could be called a windows only language or have you seen MS Visual Basic for MAC or UNIX orI havent! 2. Im sure there is BASIC programming tools for the MAC but not Visual Basic. 3. As far as I know I havent said that JAVA is a MAC language. But by asking if we should install languages as JAVA and TCL-TK I wanted to know if we (the PC users) are ready to install runtime libraries or in the case of TCL-TK the language itself (not very big about 8Meg) so that the same programs could be run on both PC and MACs. Or will the PC community not use the program if they have to do these installs. (TCL is a powerful scripting language with exceptional string handling and TK is the GUI. AND ITS FREE! Check out: http://www.scriptics.com/ if you wants to know more). So the question remains. Would you PC user out there be ready to do this? HellBorn


TC ( ) posted Thu, 28 October 1999 at 8:38 PM

MAC vs PC -- Pointless arguement...I own both types of systems...Use both regularly...Move stuff between the two all the time...Don't care what the platform is...Just like to get the task at hand done...


Dr Zik ( ) posted Thu, 28 October 1999 at 9:05 PM

Hi Folks! I suggest we end this thread. I come to the Poser forum to get away from this kind of pointless debate. With a few exceptions, MaConverter allows me to download and use practically any files PC users create for Poser. If I want to wade into a Mac/PC flame war, I'll follow a link to the ZDNet columns or OSopinion. Peter (Dr Zik)


ratta ( ) posted Thu, 28 October 1999 at 9:20 PM

I don't know this for a fact, but my understanding is that RealBasic (Mac) can convert Visual Basic programs. Now, my experience (from years ago) says no conversions are without compromise. But, perhaps some enterprising coders can take your Visual basic stuff and get it to run on a Mac via RealBasic. --ratta


ecockrell ( ) posted Thu, 28 October 1999 at 10:02 PM

I think we are missing the point of the question here. From what I gather Hellborn is about to write an application for use with Poser. If the split of PC to Mac is 80/20 should he write the app so it's cross platform? As a PC user would you want to install a third party application(s) (i.e. TCL-TK) so the application would run on both platforms. It's not a question of which is better. If I had my choice between two applications that assuming everything else is equal, I'd use the one that's compiled to native code. Those interpreters tend to slow things down. Even on a fast machine, because I run more than one application at a time. I would suggest taking a good look at Java 2.0.


Dr Zik ( ) posted Fri, 29 October 1999 at 9:13 AM

Hi Folks! aarrgghh, your intentions certainly sound and altruistic. Might I suggest next time using a less incendiary title in the subject field when you post the message? Peter (Dr. Zik)


wiz ( ) posted Fri, 29 October 1999 at 2:01 PM

Hellborn, Check out Symantic C++. It uses an application framework and GUI class library based on TCL/TK, and is availaible in Windows or Mac compilers. So you should be able to take your TCL/TK expertise to build C executables for both platforms, and just distribute small executables. I made a much longer post, with this information, and other stuff about availaible class libraries for cross paltform development, but it disappeared from the forum minutes after I posted it.


wiz ( ) posted Fri, 29 October 1999 at 2:04 PM

Arrgghh wrote "I posted a long comment but it disappeared." Funny thing, so did I, and mine disappeared, too. Joe


JeffH ( ) posted Fri, 29 October 1999 at 2:07 PM

I think you have to make a long post in several smaller posts. -JH.


wiz ( ) posted Fri, 29 October 1999 at 3:46 PM

I have to disagree with one statement by Martin. There is no "Windows only" language, there are just "Windows only" compilers It depends on how you define a "language". Sure, basic K&R C is a programming language, but it only has 37 commands. You can't write much of an application in it without libraries. So, you learn the simple, 37 command language in a few days, then spend weeks mastering the standard libraries (stdio.h, math.h, etc). Then, when you move on to more complex programming tasks, you learn more complex libraries. By the time you're through, learning the library is much more work than learning the language. C++ makes the situation even worse. My favorite GUI library and C++ application framework is Borland's OWL. This library exists in a C++ and a Pascal (Delphi) version. I have an easier time transitioning from Pascal OWL to C++ OWL than I do staying in C++ and going from OWL to another class library, such as MFC (Microsoft Foundation Class). So, in the truest sense, OWL is the language, C++ and Pascal are implementation details.


wiz ( ) posted Fri, 29 October 1999 at 3:56 PM

Another library that I enjoy working with is wXwindows. wX is a "cross platform" application framework and GUI class library. If I write a wX program, I can compile it under Borland C and have a Windows program, or compile it on GNU C on my Linux PC or SGI workstation and have a UNIX X Window program. There's even a Mac version of wX, but I currently lack the Mac and compiler to try it out. There are also commercial cross-platform libraries. A particularly interesting one (PowerPlant) comes with the Motorola CodeWarrior compiler (probably the most popular C compiler on the Mac). I believe that's the framework and compiler used for Poser. Although the nice folks at Motorola said that they are going to stop the cross-platform stuff this year.


wiz ( ) posted Fri, 29 October 1999 at 4:05 PM

There are also interpreted languages like TCL/TK and Java that permit you to write a program that will run on any system (once you've loaded the 175 megabyte runtime library for your particular machine ;-) The problem with these (at least for my work) is speed. When your program is trying to manipulate 30,000 sets of 3D coordinates in real time, an interpreted language just does not measure up. One cross-platform system that I'm moving to is OpenGL, either within the wX windows framework, or in an OpenGL application framework called GLUT. Whatever I end up with (wX or GLUT) I'm still going to need a brave volunteer with a Mac and a compiler to compile the Mac version. Anyway, better to cross platforms than to cross swords.


MartinC ( ) posted Fri, 29 October 1999 at 4:57 PM

Wiz, about the "language" bit... I don't like it that words are extended and extended until every word means everything and nothing at the same time. I think if a developer says "language" he means it, and the same applies for "SDK" and "GUI". The words mean something specific, and I think it is useful this way. CodeWarrior is a SDK for me, and C++ a language. Sorry for being a bit fundamentalistic about this...


MartinC ( ) posted Fri, 29 October 1999 at 5:23 PM

I was just re-reading the whole stuff, and with all this mood of understanding and care in the posts (not to mention the thread title which shows nothing but good intentions) I realized that my last one may sound offending... It's not, I just wanted to explain why I probably misunderstood the "language" remark. If this board would allow to edit messages, I'd probably skip 1) right now. Apologies.


lbeefus ( ) posted Fri, 29 October 1999 at 7:18 PM

You should write your utility in whatever is easiest for you. If you plan on selling it, sure, you might want to support as many people as possible. If it's EASY to support both OSs, sure, do it. But when you provide something to the community for free, it's completely up to you. Heck, make it run only on Unix if you want. :) As far as cross-platform languages and the engines which compile/run them, most people here don't enjoy going through the effort of getting them running. Then again, I could be wrong... :) Tony


HellBorn ( ) posted Sat, 30 October 1999 at 2:43 AM

The most easy would be to use VisualBasic. But Im also god at TCL/TK , I also know some Java, but writing in languages such as c++ or Delphi means to learn a compleatly new language and thats not interesting. So if I write for both systems it would most certain use TCL/TK and this is a 8Mb install. Im sorry about my title. I wanted it to be a bit "on the edge" to attract readers with a Mac/PC opinion but I realy tought that they would read more than the title.;)


wiz ( ) posted Sat, 30 October 1999 at 6:56 AM

As far as cross-platform languages and the engines which compile/run them, most people here don't enjoy going through the effort of getting them running. Then again, I could be wrong... :) Tony, it's no more effort to get a cross-platform setup running (in general) than it is to get a non-cross platform setup running. On the Mac side of things, the most popular C compiler is already cross-platform, you just have to make the decision (before writing the application) to use the PowerPland application framework, instead of MacApp. If you are already experienced in MacApp, this is a pain, but if you're open to a new framework, then it's a snap. wX is more of a pain. It took me most of a day to get it running on the PC under the Borland C compiler. On the other hand, it just installed and ran on the Linux box. 10 minute job. Go figure.


TC ( ) posted Sat, 30 October 1999 at 10:50 AM

Hellborn, Given the tools that you're comfortable with, I'd recommend Java since those apps are a little kinder to downloaders, but there's nothing wrong with TCL/TK if you want to go that route... Depending on how complex the utility or app you're planning to write is, if decide to use VisualBasic and are willing to share source code, one of us "hybrid" MAC/PC Heads can generate a MAC version if demand is great enough... For my part, I'm just grateful that you're willing to be nice to PC users as well as MAC users by developing something to share with us...Ain't gonna quibble with you about how you go about it...


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.