# C# on 10.3



## davidbrit2 (Mar 11, 2004)

I tried searching for this, but the board has a 3 character minimum for search terms. Blah.

What are my options for running C# programs? I tried building mono and rotor, but neither of them compiled correctly as packaged.


----------



## brianleahy (Mar 11, 2004)

About the same as running a Cocoa program on Windows, methinks.

I may be wrong (for your sake, I hope so) but what I've heard about C# is that it's Microsoft's response to Sun's forcing them to abandon their proprietary corruptions of Java.   Hence, C# is MS effectively saying "screw you guys and your 'universal' language, we'll make our own version!"  As a result, I'd be surprised if MS would ever provide - or even allow - C# on a Mac.

That said, I guess Virtual PC might do it.


----------



## davidbrit2 (Mar 11, 2004)

Well, Microsoft actually makes rotor, which is a command line implementation of the language basics. And there's the mono project, which is some kind of open source variation of .NET. But like I said, I've never gotten either to build. Argh.


----------



## Captain Code (Mar 11, 2004)

I'd say you're SOL until MS makes a .NET Framework runtime for the Mac.  Even when they do, I'm sure it'll be much slower(.NET on Windows is quite slow) on the Mac.


----------



## Oscar Castillo (Mar 20, 2004)

davidbrit2 said:
			
		

> I tried searching for this, but the board has a 3 character minimum for search terms. Blah.
> 
> What are my options for running C# programs? I tried building mono and rotor, but neither of them compiled correctly as packaged.



I read somewhere Microsoft is porting .NET to FreeBSD.


----------



## kainjow (Mar 20, 2004)

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevgeneral.asp

"This implementation builds and runs on Windows XP, the FreeBSD operating system, and Mac OS X 10.2."


----------



## Viro (Mar 21, 2004)

Microsoft hasn't ported .NET to FreeBSD. Rotor doesn't support many of the namespaces (most notable, Windows.Forms so you can't have a GUI).

Have a look at http://homepage.mac.com/griffincaprio/mono/RunningMonoOnMacOSX.html


----------



## jove (Mar 31, 2004)

Why? No MS bashing but why would you want to write a C# program outside of the environment the language was designed for?


----------



## davidbrit2 (Apr 1, 2004)

jove said:
			
		

> Why? No MS bashing but why would you want to write a C# program outside of the environment the language was designed for?



I wouldn't. The CS professor probably wouldn't mind, though. ;-)


----------



## jove (Apr 1, 2004)

davidbrit2,
As it is my professor uses VC++6.0. There are enough standards and STL implementation differences to make it a pain. I turn in my HW early just so he can test compile and report back code changes required to make it VC++6.0 compliant.

Good luck.


----------



## Captain Code (Apr 1, 2004)

VC 7, AKA .NET is a lot more standards compliant.


----------



## Viro (Apr 2, 2004)

Make that the 2003 (aka 7.1) edition, not the 2002 edition of VS.NET. I can't remember what it was, but there was something that really bugged me about the implementation of the C++ standard in VS.NET 2002. But its been a long time since I use VS.NET so I can't remember what it was...


----------



## Lycander (Apr 2, 2004)

http://www.gnu.org/projects/dotgnu/

Snippet:

"Currently supported CPUs: x86, ppc, arm, parisc, s390, ia64, alpha, mips, sparc. Supported operating systems: GNU/Linux (on PCs, Sparc, iPAQ, Sharp Zaurus, PlayStation 2, Xbox,...), *BSD, Cygwin/Mingw32, Mac OS X, Solaris, AIX."


To CaptainCode:
.Net on Windows isn't that slow, it's at least faster than Java. The intermediate code gets compiled into native code only once (then gets stored for later retrieval), whereas Java has to JIT compile the byte code at every time of execution. Once it's in native code it's just as fast as a C/C++ program.


----------



## davidbrit2 (Apr 2, 2004)

Awesome. I'm downloading the OS X package right now, and I'll play with it later. Thanks for the link. I'm surprised I hadn't seen that before.


----------



## Captain Code (Apr 2, 2004)

Yeah, it's faster than Java, but it's in no way anywhere close to the speed of C++.  .NET is all managed code meaning it checkes all memory access all the time and slows it down.  I've written a number of .NET programs and it's no where near as fast as a C++ app.

It seems to depend on what type of app it is.  C# apps seem to be pretty quick but VB.NET apps seem to be slower.

That dotgnu looks interesting, but I see they brought the uglyness of Windows along for the ride


----------



## Lycander (Apr 2, 2004)

Well you can also say that if you write Assembly code yourself, it'll be faster than C++ code. There are benefits to managed code, especially in the area of memory management, as you pointed out. I'd say for simple GUI apps or front-ends, C#/.Net is good, it's more low level than VB.

I guess they brought the ugliness of Windows along for the sake of portability. It's easier for them to create their own widget rendering system, when it comes time to port it to another playform, all they need to do is rewrite the low level, underlying widget system to the native drawing API (Quartz, GDI, X windows). If they made it themeable, then you can make dotGNU apps look like Aqua apps, but then it'll be available on other platforms as well. Qt/Mac does the same thing, they do their own Aqua-like widget drawing because the library itself supports themeing.


----------



## Viro (Apr 2, 2004)

Lycander said:
			
		

> Well you can also say that if you write Assembly code yourself, it'll be faster than C++ code.



That's quite unlikely nowadays, unless you're a major assembly guru and know the hardware really well. No offense meant if you're one of these gurus, just that for the majority of the population, the C++ compiler will generate much better code than they could possibly hope for.

Emulating widgets brings a lot of problems of its own. The first thing that comes to mind is that the widgets will look out of place. A Qt/Mac app looks really out of place on my Panther system. Some of the text are misaligned (vertically), and the theme looks more like Jaguar than Panther. Given that Panther has been out for half a year, its a shame that Qt hasn't been updated to reflect the changes.

Speed is also going to be an issue since you aren't really using native widgets but drawing your own. Updates to native widgets will not be visible in your custom drawn widgets.


----------



## Lycander (Apr 2, 2004)

Viro said:
			
		

> That's quite unlikely nowadays, unless you're a major assembly guru and know the hardware really well. No offense meant if you're one of these gurus, just that for the majority of the population, the C++ compiler will generate much better code than they could possibly hope for.


The default compiler in VC++ is not aware of SIMD extensions, I've inlined Assembly instructions to make use of SSE/SSE2 extensions for speed ups. Prior versions of GCC don't make good enough use of Altivec, I did buy CodeWarrior 8 which has options to enable Altivec instructions. When in project builder, there's nothing to really indicate that the compiler will use AltiVec where it's available. We sort of "assume" that it's making the best optimizations possible. Further more, GCC and Project Builder creates binaries that should be able to run on various PPC chips, in this case both G3 and G4 CPUs. MCC is different in that you can target specific PPC CPU models for even more optimizations. I'm just not overly convinced that GCC is making use of Altivec. Granted the data set has to be organized in such a way that can be easily SIMD-ed, in which case I'd inline my Assembly code anyways right next to my C/C++ code.



			
				Viro said:
			
		

> Emulating widgets brings a lot of problems of its own. The first thing that comes to mind is that the widgets will look out of place. A Qt/Mac app looks really out of place on my Panther system. Some of the text are misaligned (vertically), and the theme looks more like Jaguar than Panther. Given that Panther has been out for half a year, its a shame that Qt hasn't been updated to reflect the changes.


I vaguely remember Qt/Mac 3.2 or 3.3 announced that brought it up-to-date with Panther. But you're right, it still looks out of place. But if you ask me, that brush metal look is what's out of place. I find that black text is very difficult to read when over the grey brushed metal windows, worst than having text over the pin stripes.



			
				Viro said:
			
		

> Speed is also going to be an issue since you aren't really using native widgets but drawing your own. Updates to native widgets will not be visible in your custom drawn widgets.


Not necessarily. Native widgets still use Quartz to do the drawing, compositing, then it gets shipped down the pipeline where hardware acceleration kicks in for alpha blending, scaling, etc. Qt/Mac uses Quartz to draw their custom widgets and then that image gets passed along the pipeline just like the native widgets.

From my perspective after using Qt/Mac, Carbon and Cocoa, Qt/Mac is about on par with Carbon based apps where UI speed/responsiveness is concerned. There is one thing I do like about Qt/Mac over Carbon though: in some rare situations Carbon apps will not render text with anti-aliasing. Example: I was using OSX 10.2 and Dreamweaver MX, which I believe it to be using Carbon. All the text in that app was non AA which bothered me (until I discovered Silk). I think the reason for that is because there's 2 flavors of Carbon. One reserved for backwards compatibility with older MacOS, and a newer Carbon that takes advantage of new features in OSX. Macromedia opted for compatibility so Dreamweaver MX lacked new features found in OSX.

Qt/Mac uses their own font AA to render their text. This alleviates the worry of the underlying Carbon font rendering.


----------



## Viro (Apr 2, 2004)

To my knowledge, GCC doesn't automatically vectorize instructions so even if Altivec is present, it won't be used. That's probably the reason why Apple had their veclib C interface to Altivec. You can specifically tune the application to certain processors via the -mtune -mcpu flags. Most decent compilers, including VC++.NET support generating SSE/SSE2 instructions. The Intel compiler supports auto vectorizing of code, which is even better. But even so, how many operations can be vectorized? 

Qt Mac still sticks up like a sore thumb on Panther  Among the problems include the very pronounced 'stripes' in an Aqua application. Panther still retains these stripes, but they aren't as visible as say in Jaguar. Panther removed tabs, and replaced them with 'lozenges'. Qt still hasn't done anything about this, and thus they look odd when running Panther. Otherwise, its a great toolkit and I use it all the time. You comment about Qt's speed is good to know. I don't use Cocoa, and I've always (wrongly) assumed that it would automatically be slower than pure native widgets.

Anyway, we've really strayed into off-topic areas. Better let the OP get his answers.


----------



## Lycander (Apr 2, 2004)

Well I did give him a link to dotGNU, whether or not it's useable I dunno


----------



## davidbrit2 (Apr 2, 2004)

Yeah, I think I've gotten all the answers I'll need. Carry on with the miscellanea. Heh.


----------



## Lycander (Apr 5, 2004)

Ooohh!! I just found this: http://www.osnews.com/comment.php?news_id=6611#220394

Quote:

*How to build Mono from cvs on OSX*
In mono_root/mono/mini comment out this line in Makefile.am: libmono_la_LDFLAGS=$(monoldflags)

Then rerun autogen.sh from the mono root directory. You need to install a current version of libgc. It's called the Boehm GC for those that have never heard of it.

Configure with

./configure --with-gc=boehm

It's not a good idea to specify a non-default location because if you don't install to that place again, the next go around might because you to get "corlib out of sync with runtime errors"


----------

