Freelancer working with Wine 1.1.20
-
-.-
why do you test it with an BETA version?
1.1.21 or 1.1.22 is already out!
For myself it worked perfectly and I only can tell you what worked for my system.
What distribution are you using? I use Ubuntu 9.04 and installed wine with an .deb package from the wine site.
and it was me that was flying around as Ubuntu_rockz or something like that!
-
1.1.20 Never fully worked. Â
And yes I know it was you who flew around with that name. Doesn’t mean you did anything for me. Â Just confirmed my claim to others that it could work. I seen you flying around and asked if you had it working completely. You said yes with some DLL files to be copied. Something I already knew. Â You also said the text was messed up at the time. Something I already knew and was working on a fix for. But this was all BEFORE your claim that this release worked out of the box… which is false. Â You just couldn’t stand the fact someone else came up with the FULL solution for the average user first. Â And then tried to claim the credit for my work. That is where you crossed me.
But regardless, your solution did not work and messed it up for me. Â So I resorted to falling back on a RELIABLE version.
Until wine releases a version that works as reliably as 1.0.1 it’s gonna stay beta. Because they are going to have to keep making corrections.
Look how many versions they’ve had since the initial version released after 1.0.1 Â Er go… beta. Â They are trying to make it work in a manner that isn’t fully tested or confirmed. Â AKA BETA.
Hence why wine itself will not claim anything other than that 1.0.1 is the latest STABLE release. Meaning all others are BETA Duh.
But if you really want to get technical… the entire project is Beta. In this aspect, we are speaking relativities. Â
-
I was wondering, why would something work on windows but not linux, is it due to the way data is processed, or is it due to the way the files are complied, or is it to do with the source code of the platform you’re working on, if that’s the case, why?
-
How about Crossover Games?
-
I was wondering, why would something work on windows but not linux, is it due to the way data is processed, or is it due to the way the files are complied, or is it to do with the source code of the platform you’re working on, if that’s the case, why?
For regular applications it’s due to using Windows API calls. Wine attempts to provide a bridge between the Windows API and the Unix API. For Windows games the situation is more complicated. Games on Windows usually use DirectX, which is a Microsoft-specific technology. Native Linux games have to use OpenGL, since that’s the only 3D graphics API supported. Wine also attempts to provide a bridge between DirectX and OpenGL.
-
You know, since we engineers let software nerds like you lot play with our hardware you all went different ways and could not agree, hence the mess we are in today.
In the good old days there was only machine-code language for each machine type. Assembler was the name of the first machine-code editor that made it easier to write and save programs than to enter reams of numbers by finger-poking directly into memory locations before hitting the “start” button. No deviations were possible, “add” was “complement and subtract” cos most big fast machines used negative NAND logic and ECL circuitry.
Since your forebears and you lot misunderstood that basic principle and messed up further trying to understand more of the stuff we had put in as deterrents to softie types like you,… Well! Here we are!! What else should we expect!?!!
;D
And - keep it cool, another difference between engineers and softies is we engineers don’t lay claim to much stuff we produced, even when it had life-saving consequences. Softies, on the other hand, have no such scruples… like Bill Gates who had the audacity to rip off IBM by wrecking OS/2 which they had commissioned MS to write for them, and bringing out Windows 3 in parallel at IBM’s expense… and IBM were stupid enough (yes, stupid is the right word here) to not buy MS for a puny $11million at that time when they could have, because the head man and his head-nurds saw the future of PCs as only terminal replacements for our “Real” big machines… Anyone remember their names? Not many, huh…
Here are a couple of snippets to whet your whistles… Bool and Babbage made the first proper computer, not IBM and not Intel. And then there was ENIAC, then several ILIACs which included the first-ever 64-way processor in 1964 by Burroughs - and Lyons Tea Houses built their own LEO mainframe computers to run their UK-wide tea house business. Burroughs built some very successful and fast commercial “data processors” (see Burroughs B6700, B7700) and bank telling machines (L4000) used by almost all UK banks, and a very high-speed Scientific processor (BSP) but sold only 3. ICL was a big UK mainframe manufacturer, sadly mostly only remembered for their huge fast mainframe printers. Sperry-Univac’s 1100 and 2200 ruled the roost too for a while. IBM came back with the S/360 range, the S/370, then 308x, 309x and Amdahl Corporation (founded by IBM’s S/360 & S/370 design chief Gene Amdahl) made more powerful fully-compatible mainframes at 1/3rd the price with the first Multiple Domain Feature back in 1980 (what you out their call “virtualisation”) and several other innovations, including the first commercial machine to break through 1000 MIPs and then the Millennium 2000 MIPs in 2000. In parallel, the Cray series T90 “real machine” power leaped through to over 90million MIPS, and then renamed TeraFlops and now on to PetaFlops cos there are no ways to say “Millions of Terra Million Instructions Per Second” in the same time!! Then good old IBM finally released the Z-Series in the early part of this decade which destroyed the market because they renamed it “Server” instead of “Mainframe Big Iron”, seriously believing that Sun’s SPARC servers were a real threat - nah, never! Hollerith made the first commercial card punching machine for entering programs into computers by punching code onto paper cards which would then be fed into a reader which was attached to a controller that wrote the data directly into the computer memory… Later the more successful machinery was much better, look up IBM 2540 for an interesting piece of hardware that I was very familiar with… Hmmm, I just noticed you’re all asleep…!! ::) Well anyway, he died virtually unknown too, as will the guy who designed the first IBM PC. But McCorquodale made millions from making punch-cards for pretty much the whole world.
End of history lesson. But afore ye go - look up the Cray series too, the Cray 2 was disguised as a seat for visitors and placed in the computer suite lobby for a laugh! And the Cray 4 is still a sight for sore eyes!
Have I given you a bit of light relief guys?
I hope so. You were getting too serious here.
Right, at this very time, I’m just an older fly-boy wanting to take off into the bright blue Linux skies with my fangly FL space-ship and explore the unknown universe with my pals! So - stop squabbling, get back on your heads and get together to find the ultimate solution to run FL Server with full normal connectivity a la mode de Windows XP!! NOW!! ::)
-
I was wondering, why would something work on windows but not linux, is it due to the way data is processed, or is it due to the way the files are complied, or is it to do with the source code of the platform you’re working on, if that’s the case, why?
For regular applications it’s due to using Windows API calls. Wine attempts to provide a bridge between the Windows API and the Unix API. For Windows games the situation is more complicated. Games on Windows usually use DirectX, which is a Microsoft-specific technology. Native Linux games have to use OpenGL, since that’s the only 3D graphics API supported. Wine also attempts to provide a bridge between DirectX and OpenGL.
Thankyou for that :), I know a little more about what I possibly would like to be doing.
-
Yep, me too - StarTrek on a mainframe. Just a big grid of I’s and _'s for each system, with an (O) for planets, an E for the Enterprise, K for a Klingon ship, R for a Romulan, and text entry for weaps - “T F5” = “Fire a Torpedo into sector F5”… then wait for a few seconds for the result!
In the meantime you had no idea if the enemy had fired and if you hadn’t moved too you could easily get blasted before you got your result.
Heheheheh - THAT was excitement!!
HEY! Have you lot cracked it yet??! ;D
-
- Possible string reference 5C9768h “…\OpenGL.cpp”
-
Last I checked it works pretty much fine with 1.3.14 and up.
http://appdb.winehq.org/objectManager.php?sClass=version&iId=2504&iTestingId=63035
(I’m actually a maintainer for this app)
There are two downsides.
1. Multiplayer is still a no-go.
2. Rendering is slower than running natively, you will notice that the entire screen is not being redrawn in a single pass at resolution like 1680x1050. -
masternerdguy wrote:
Last I checked it works pretty much fine with 1.3.14 and up.http://appdb.winehq.org/objectManager.php?sClass=version&iId=2504&iTestingId=63035
(I’m actually a maintainer for this app)
There are two downsides.
1. Multiplayer is still a no-go.
2. Rendering is slower than running natively, you will notice that the entire screen is not being redrawn in a single pass at resolution like 1680x1050.Actually, it looks like the first guy who got FL working under wine was on 0.9.44, Aug 28 2007.
I’m a super maintainer.
I don’t think any of the Wine devs are paying much attention to FL MP. Maybe there’s someone here who would be able to get it working and submit patches though.
Rendering in Wine is never going to be as fast, as it’s DirectX calls have to be reworked for OpenGL.