Codes
WiiRd forum
March 28, 2024, 08:16:12 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Welcome on the new server

Update 4.3 - do NOT update!
Gecko 1.9.3.1
Should I get a USB Gecko, I wanna hack?
How do I use my USB Gecko
Where can I get WiiRd?
 
   Home   CODE DATABASE GAMEHACKING Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Building Gecko.NET from source  (Read 4733 times)
dcx2
Computer Engineer
Moderator
Legendary Member
*****

Karma: 165
Posts: 3468


WWW
« on: October 05, 2010, 04:53:13 AM »

(mirrored on the Google Code wiki: https://code.google.com/p/geckowii/wiki/HowToBuild )

Things you need first:

Visual Studio Express C# 2008 - http://www.microsoft.com/express/Downloads/#Visual_Studio_2008_Express_Downloads

I also suggest TortoiseSVN to get the source - http://tortoisesvn.net/downloads

EDIT2:

If you need the FTDI driver, go here.  http://www.ftdichip.com/Drivers/D2XX.htm

If you need vdappc, powerpc-gekko-*, etc they can be found in the official release on the Google Code download page.  Copy them to the /bin/Debug and /bin/Release folder.  The folders might not exist until you do your first build.  http://code.google.com/p/geckowii/downloads/list

---

Create an empty folder somewhere.  Right click on it.  You should see an SVN Checkout... option in the context menu.



The URL of the repository is http://geckowii.googlecode.com/svn/trunk/



You should see the list of files downloaded from the repository.



You should also see the Windows Explorer folder icons change to show SVN status.



So far so good!  Now open Visual Studio.  Go to File -> Open Project...



Navigate to the Gecko dNet.sln file.



You should see all the source files appear in the Solution Explorer tab.  Either press F5, or click the green triangle at the top.  You will see a little message in the lower left corner when the build succeeded.



There you go!  Gecko.NET should appear and start running.

EDIT:

If you're using VS2010 instead of VS2008 Express, you may have some issues.  Link resolved the issues, though.

Quote from: Link
I tested with Visual Studio 2010 - interesting phenomen: it tries to convert it to a .NET 4.0 project but then saves it as .NET 2.0 anyway. What you need to do: open the project file (Gecko dNet.csproj) in a text editor:

Make sure the tags inside there read:
<Project ToolsVersion="2.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<SchemaVersion>2.0</SchemaVersion>
« Last Edit: October 06, 2010, 09:38:00 PM by dcx2 » Logged

Panda On Smack
Hacker
Hero Member
*****

Karma: 39
Posts: 606


« Reply #1 on: October 05, 2010, 03:34:18 PM »

What version of .NET have you built this in?

Having a few issues (im running VS2010 pro)

Also have .NET 4 installed

ta

EDIT: might be a 64bit issue, i'm on Win 7 64
« Last Edit: October 05, 2010, 03:36:40 PM by Panda On Smack » Logged
dcx2
Computer Engineer
Moderator
Legendary Member
*****

Karma: 165
Posts: 3468


WWW
« Reply #2 on: October 05, 2010, 04:22:22 PM »

If you could describe the issues (exceptions?  compiler errors?), then I might be able to help.

Is it perhaps a BadImageFormatException?  I've had that problem with 64-/32-bit apps...right-click on the Project file in Solution Explorer, and then click Properties.  Go to the Build tab, and make sure that the Platform Target field is set to "x86".  If it is set to "Any CPU", then Visual Studio will compile the app for the native bit-ness (in your case, 64-bit), and then it will fail to load the 32-bit dll.  By setting x86, you force it to compile as a 32-bit app always.

I don't think .NET 4 affects anything.  It targets the .NET 2.0 CLR.  But all versions of .NET after 2.0 build on the it.  Unless you're running Windows XP SP1 or lower and have never contacted Windows update and hardly use your computer for anything other than a web browser, you have .NET 2.0.

In the event that you wish to use Gecko.NET with a different CLR, go to the Properties page again, but this time go to the Application tab.  You can change the Target Framework there.
Logged

Link
that dev there
Moderator
Hero Member
*****

Karma: 76
Posts: 1254

I hate everyone in this community. Except for you!


WWW
« Reply #3 on: October 05, 2010, 05:25:50 PM »

I do not know for "Any CPU" - that worked absolutely well for me and I AM on 64 bit. The Ionic.Zip thing is a .NET library and as of such works natively in both 32 and 64 bit mode.. the only library Gecko .net should use elsewise is ftd2xx.dll or did you change that? That library has a 32 bit and 64 bit version, a 64 bit system should contain both!

Edit: I tested with Visual Studio 2010 - interesting phenomen: it tries to convert it to a .NET 4.0 project but then saves it as .NET 2.0 anyway. What you need to do: open the project file (Gecko dNet.csproj) in a text editor:

Make sure the tags inside there read:
<Project ToolsVersion="2.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<SchemaVersion>2.0</SchemaVersion>

This will fix the project on .NET 2.0 - then it will compile even safely as a native application.
« Last Edit: October 05, 2010, 05:33:23 PM by Link » Logged

dcx2
Computer Engineer
Moderator
Legendary Member
*****

Karma: 165
Posts: 3468


WWW
« Reply #4 on: October 05, 2010, 05:32:56 PM »

It's still using the d2xx library.  But I looked around and I can't actually find the file anywhere.  Is there another prerequisite that must be installed to get that library?

EDIT:

If you guys are having trouble with the ftd2xx.dll then you can go here to get it.  Interesting...there's one for Linux, too.  I wonder if that might help with mono?

http://www.ftdichip.com/Drivers/D2XX.htm
« Last Edit: October 05, 2010, 05:35:25 PM by dcx2 » Logged

Link
that dev there
Moderator
Hero Member
*****

Karma: 76
Posts: 1254

I hate everyone in this community. Except for you!


WWW
« Reply #5 on: October 05, 2010, 05:34:19 PM »

It's still using the d2xx library.  But I looked around and I can't actually find the file anywhere.  Is there another prerequisite that must be installed to get that library?

The d2xx library is installed alongside the FTDI drivers. If the library is missing then the driver would have to be reinstalled.
It is installed in system32 as well as in syswow64 (64-bit OS only).

However, I repeat again: I can SAFELY confirm, that it works in native mode (32/64 bit mode) - that's how .NET is designed as long as you do not use 32-bit unmanaged DLLs - that's one of the reasons I went for C# when I created it.

The basic reasons were:
C#:
-easy to develop
-works well from Windows 98 to 7 (yes, I really tested it on Windows 98 with the oldest ftdi drivers availible - one of the reasons I went for .NET 2.0 - to retain backwards compatibility as far as possible - .NET 3.0 and 3.5 add cool features for databases, anonymous functions and related but I didn't feel these features would majorly impact the development of the application - still officially I would only support Windows 2000 and upwards (2000 is too similar to XP - besides I still have a 2000 machine to test on))
-64 bit compatible, no *32 extension in task manager
« Last Edit: October 05, 2010, 05:38:21 PM by Link » Logged

Link
that dev there
Moderator
Hero Member
*****

Karma: 76
Posts: 1254

I hate everyone in this community. Except for you!


WWW
« Reply #6 on: October 05, 2010, 05:39:56 PM »

If you guys are having trouble with the ftd2xx.dll then you can go here to get it.  Interesting...there's one for Linux, too.  I wonder if that might help with mono?

FORGET their Linux driver.. it's a piece of garbage, really.. I tried to work with it.. libftdi works MUCH MUCH better and well.. libftdi would also work on Macs - while I do not have a Mac to test, Gecko.net compiled for Mono against libftdi should also work on Mac.
Logged

dcx2
Computer Engineer
Moderator
Legendary Member
*****

Karma: 165
Posts: 3468


WWW
« Reply #7 on: October 05, 2010, 05:48:06 PM »

I don't think you need to worry about supporting anything before XP.  In fact, you can't even buy XP anymore...

Some classes add a few new interesting methods with .NET 3.0 and beyond.  But most of the time, you don't need them.  However, if someone wants to compile against a newer CLR there's no reason not to...in fact, it might be better performance...although newer versions of .NET usually contain service packs for 2.0 anyway.

Regarding the 64-/32-bit thing, it's good to know it builds on both.  Without details beyond "might be a 64-bit problem", I couldn't really narrow it down.  I just remember being bit by the BadImageFormatException before, because the AudioVideoPlayback class in Managed DirectX is 32-bit only.

Re: ftd2xx linux, Nuke's SetLatencyTimer call is a d2xx-specific API call.  I don't know if we could fake it with libftdi.  And they also have a Mac d2xx driver.
Logged

Link
that dev there
Moderator
Hero Member
*****

Karma: 76
Posts: 1254

I hate everyone in this community. Except for you!


WWW
« Reply #8 on: October 05, 2010, 06:17:47 PM »

For DirectShow: as most DirectShow codecs are 32 bit only, it is of no real use to create a 64 bit compatible DirectShow player.
For OS: I do know people who still use them.. and as I said: I personally even use .NET 3.5 for some applications, especially LINQ for database accesses. I really didn't see much use for Gecko.net back then though.

Well, I know they provide Mac and Linux drivers.. however, back then I really tried working with them.. and they are horrible.. for the SetLatency thing.. well, I will check libftdi. However, their Linux drivers were horrible, according to svpe from Team Twiizers their Mac drivers are not any better - they complain about them being instable as hell and praise libftdi - and I assume Team Twiizers knows what they are talking about. When I did the port of WiiRd (console only) for Linux I noticed the same - the Linux module is horrible, needs to be compiled for the Kernel - while libftdi runs if you have USB support activated in your kernel and then done. So I really had VERY bad experiences back then with the official Linux driver.
Logged

conanac
Hacker
Full Member
*****

Karma: 9
Posts: 114


« Reply #9 on: October 06, 2010, 03:23:57 AM »


I manage to compile and run successfully Gecko.NET (using Visual C# 2008). However, when I open the Disassembler tab, it says cannot find vdappc.exe. So you may want to include in the tutorial how to get such a file (e.g. asking the users to copy from their WiiRD folder to the Debug folder). For my case, I try to use the file distributed in the pyiiasmh googlecode site, and it works.

Many thanks for putting this in googlecode and have a nice and easy set-up.

Cheers.
Logged
dcx2
Computer Engineer
Moderator
Legendary Member
*****

Karma: 165
Posts: 3468


WWW
« Reply #10 on: October 06, 2010, 03:41:46 AM »

Yes, I sortof assumed that if you're building Gecko.NET from source, you've grabbed an official build, which contains vdappc etc.  I'll make a note in the first post, though.  I guess I shouldn't assume that users have the driver installed, either, so I'll make a note about that too.
Logged

Panda On Smack
Hacker
Hero Member
*****

Karma: 39
Posts: 606


« Reply #11 on: October 06, 2010, 08:49:36 AM »

Edit: I tested with Visual Studio 2010 - interesting phenomen: it tries to convert it to a .NET 4.0 project but then saves it as .NET 2.0 anyway. What you need to do: open the project file (Gecko dNet.csproj) in a text editor:

Make sure the tags inside there read:
<Project ToolsVersion="2.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<SchemaVersion>2.0</SchemaVersion>

This will fix the project on .NET 2.0 - then it will compile even safely as a native application.

This worked for me, ta Link

Thanks for sharing the source dcx. It's good to look out how things have been built and I tip my hat to the amount of work you've put in!

P.S. I've said this before but I highly recommend getting ReSharper
« Last Edit: October 06, 2010, 08:57:21 AM by Panda On Smack » Logged
giantpune
Hacker
Full Member
*****

Karma: 5
Posts: 129


« Reply #12 on: October 06, 2010, 07:34:12 PM »

If you guys are having trouble with the ftd2xx.dll then you can go here to get it.  Interesting...there's one for Linux, too.  I wonder if that might help with mono?
[/quote]

i posted code in the mono discussion thread that works in linux for reading from the gecko without any package or shared library or anything.
Logged
Nuke
Hacker
Hero Member
*****

Karma: 53
Posts: 661


« Reply #13 on: October 07, 2010, 02:59:51 AM »

I'm using libftd2xx.0.1.7.dylib on Mac OS X 10.6.4 and seems to works fine. I used the example program 'simple' and worked from there.

Does libftdi support d2xx correctly?





For DirectShow: as most DirectShow codecs are 32 bit only, it is of no real use to create a 64 bit compatible DirectShow player.
For OS: I do know people who still use them.. and as I said: I personally even use .NET 3.5 for some applications, especially LINQ for database accesses. I really didn't see much use for Gecko.net back then though.

Well, I know they provide Mac and Linux drivers.. however, back then I really tried working with them.. and they are horrible.. for the SetLatency thing.. well, I will check libftdi. However, their Linux drivers were horrible, according to svpe from Team Twiizers their Mac drivers are not any better - they complain about them being instable as hell and praise libftdi - and I assume Team Twiizers knows what they are talking about. When I did the port of WiiRd (console only) for Linux I noticed the same - the Linux module is horrible, needs to be compiled for the Kernel - while libftdi runs if you have USB support activated in your kernel and then done. So I really had VERY bad experiences back then with the official Linux driver.
Logged

0xFFFFFFuuuuuuu
Link
that dev there
Moderator
Hero Member
*****

Karma: 76
Posts: 1254

I hate everyone in this community. Except for you!


WWW
« Reply #14 on: October 07, 2010, 03:52:04 AM »

Well, I am not sure if d2xx is supported correctly. Basically I do not have a Mac personally, I was talking to 2 Team Twiizers back then and they literally complained about the official ftdi driver for being hardly supported, slow and unreliable (meaning it sometimes crashes). The major downside of it: rather than supporting to be a Virtual COM Port or a D2XX library at once you can choose one of both - D2XX outrules the COM port and vice versa.

As far as I can see libftdi is its own implementation: so libftdi is not 100% D2XX compliant and not 100% COM Port either. Internally libftdi uses libusb and directly communicated via USB.

@giantpune: your code seems interesting!
Logged

Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!