Aquisition, will it ever be available for Windows???

[amaru_10]

have used on a friends mac and was easy to use, layout was nicely done, and no complications with connection or hosts and sources.

[Jorge]

Not that we have heard.

[isus]

i think there was a thread like this on the acq forums. the answer? no.

[PuNiShErKiLl666]

well sense some windows p2p apps dont go to MAC. I guess us Windows users desereve not to get this.

[notbob]

even if it was the greatest app of all time, it's still just another gnutella client--aren't there enough of those for windows already?

player integrations, recommendations, all useless fluff that gets in the way of the applications real function, which i would say is to search for and download files (of course if you want a bloated gnutella app that has most of that crap, shareaza fits the bill)

[isus]

i found that thread... there is no acq for pc because there is no carbon for pc. and since acq is written in carbon... you won't get acq anytime soon either.

[stealthspy]

Well, it is availble. Commonly known as LimeWire :). They really are pretty similar.

[mybackhurts]

and now limewire is also clean , with no spyware or adware inside it

[Ken17625]

nd now limewire is also clean , with no spyware or adware inside it

And I can't tell you how happy I was to here/read that.

It's truly a step in the right direction, even if I don't use the Gnutella network anyway.

[isus]

and now limewire is also clean , with no spyware or adware inside it
can i have some of the pot you're smoking? since when did limewire pull that nasty adware out?

either way, limewire is java, and java is, for the most part, terribly slow. acq is carbon, and is much faster.

[Lehk]

can i have some of the pot you're smoking? since when did limewire pull that nasty adware out?

either way, limewire is java, and java is, for the most part, terribly slow. acq is carbon, and is much faster.
Well there is CleanLimWire. Also Java is not slow, Java GUI's are sluggish, the code is able to perform as well as anything, the GUI just doesn't have the instant response many windows users are used to (Microsoft put the GUI directly into the win32 Kernel)

[Siskabush]

damn spam threads! This guy already made 3 different ones earlier today!!

Ban his ass

[smokingbevel]

Java code is interpreted at runtime, and in some cases, is measurably slower than code compiled to "native" instructions. While the Java graphical user interface toolkit, Swing, is well-organized and exhibits a fair representation of model-view-controller architecture, compared to "native" user interfaces, it is perceivably slower and consumes a much greater amount of memory resources.
The good news is, the remarkable folks at Sun Microsystems are constantly working to improve the performance of Java. In some cases, Java code supposedly competes effectively in performance tests against "native" code.

[John W. Lindh]

Java code is interpreted at runtime, and in some cases, is measurably slower than code compiled to "native" instructions.
It's actually compiled at runtime. The difference is subtle but important. While an interpreter would interpret the same function again and again whenever it is called, Java compiles and caches it. That's why the difference between java and native code can become very small for some applications.

[John W. Lindh]

either way, limewire is java, and java is, for the most part, terribly slow. acq is carbon, and is much faster.
The larger part of Acquisition is LimeWire's java core, so the only noticeable difference in speed can be LimeWire's Swing GUI vs. Acquisitions Carbon GUI. If you minimize the LimeWire window, the difference is zero.

[smokingbevel]

It's actually compiled at runtime. The difference is subtle but important. While an interpreter would interpret the same function again and again whenever it is called, Java compiles and caches it. That's why the difference between java and native code can become very small for some applications.Are you stating that the JVM first interprets instructions, compiles those instructions to native instructions, caches the native instructions, and thereafter accesses the cache? Is it your intention to claim that the optimization is applied to all instructions, or only some instructions?
Java code is interpreted at runtime, and in some cases, is measurably slower than code compiled to "native" instructions. While the Java graphical user interface toolkit, Swing, is well-organized and exhibits a fair representation of model-view-controller architecture, compared to "native" user interfaces, it is perceivably slower and consumes a much greater amount of memory resources.
The good news is, the remarkable folks at Sun Microsystems are constantly working to improve the performance of Java. In some cases, Java code supposedly competes effectively in performance tests against "native" code.I admit that my statements, which exclude certain relevant specifics, are somewhat erroneous, and lack a degree of absolute truth.