Gecko dotNET release thread (version 0.65 now!)

Started by Link, January 03, 2010, 01:33:37 PM

Previous topic - Next topic

Link

I'll most likely release a little update tomorrow..

For exceptions: I admit, I am very lousy on exception handling right now.. that will be changed later but so far I admit it isn't.. and certainly an exception just crashes the application as it does not handle it (only during the game start-up exceptions are handled).

For the current version: I changed some stuff in the FST tab (instant swap possible) and the ANSI/Unicode string search in the memory viewer is functional... other than that: just changed the notepad interface from the combobox interface it had to a tabbed interface!

dcx2

#76
Under USBGecko::Peek(), in the catch handler, you should throw up a messagebox that echoes the number passed into the EUSBGeckoException's constructor before re-throwing.  Also, I don't think you need "throw e;" because I think you can re-throw the exception with just "throw;", no argument necessary.

The default .NET stack trace dump does not display any of the exception's arguments.  Kudos on re-throwing the exception instead of swallowing it, though.  That's good behavior.  Better to bring the app down than leave it in an uncontrolled state.

EDIT:

Dump is definitely doing something naughty.  I had MemoryViewer auto-update running and it caused Dump to crash.  However, I clicked "continue" which swallowed the exception, and it didn't work until I re-connected to the USB Gecko, then the app continued to run just fine.

Link

Thanks for the input.. well, the exception would be passed on if I used try-finally.. I admittedly used try-catch which would normally catch an exception and handles it.. unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code. As of such I went this way.. for a messagebox: admittedly, no messagebox should be opened in usbgecko.cs as it does not belong there imo. I will handle exceptions in the main code though! Right now I am outlining a global exception handler which would give proper message boxes in case errors appear and handle the code accordingly.. it is admittedly a bit difficult as some functions like breakpoints run threaded and accessing main form elements from threads can be quite tricky.. I will be working on a solution for proper exception handling though!

dcx2

Quote from: Link on March 06, 2010, 08:18:42 PM
Unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code.\

I think I understand what you're saying.  I am pretty sure you can put a return in the try block of a try-finally statement and the finally is _always_ executed before you return.  The only thing that could possibly stop a finally block from executing is an exception in the finally block.

http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html

Link

Quote from: dcx2 on March 06, 2010, 08:26:23 PM
Quote from: Link on March 06, 2010, 08:18:42 PM
Unfortunately the structure itself can hardly be changed to try-finally because of the return command in the main code.\

I think I understand what you're saying.  I am pretty sure you can put a return in the try block of a try-finally statement and the finally is _always_ executed before you return.  The only thing that could possibly stop a finally block from executing is an exception in the finally block.

http://www.discussweb.com/c-programming/2448-if-i-return-out-try-finally-c-does-code-finally-clause-run.html

I checked MSDN too.. seems like try-finally works.. well, as I often mentioned this is my first big C# project, thanks university which only taught Java (which I personally dislike because of its horrible speed) and Delphi (which while being fast has the issue of expensive compilers and everything). But yeah, I'll change the block then!

Link

#80
Version 0.42 now:

changes since 0.40 are (so 0.41 changes also included):
-refining should be fixed (spotted the error)
-readme now included
-breakpoint fixes
-dec to hex buttons removed, context menu instead which also provides float to hex and such
-search within memory view added
-under-the-hood-changes
-notepad changed to a tab view
-GCT code list scrolls vertically now
-arrow navigation possible on GCT tab
-changed up/down buttons in disassembler tab (they were wrong way around!)
-auto-update in memory viewer fixed
-context menu in disassembler tab added (Breakpoint, Poke and GCT code)
-that nasty bug with VC/WiiWare games should be gone for good
-exception handling (the app shouldn't crash during a transfer error but show error messages)
-checks whether external exe files are there rather than just crashing if it tries to execute them and they are not there

Sources and binaries have been updated

Binaries: http://l0nk.org/gdnb.zip
Source code: http://l0nk.org/gdns.zip

dcx2

From WiiRD differences:

QuoteDisassembler:
No difference to WiiRd actually.. just replacing commands should instantly work this time not after 100 tries (strange bug in WiiRd GUI noone really understands!)

I found that if you pause, then hit update, then hit run, it would work every time.  The only time it wouldn't change is if the game not paused.  This was in contrast to poke, which would work while the game was not paused.

Zetta_X


Panda On Smack

#83
Thanks Link.

For all VS users out there I have started using a plug-in called ReSharper (http://www.jetbrains.com/resharper/index.html)

It's VERY useful

P.S. getting the following with the source:

Could not find type 'GeckoApp.BPList'.  Please make sure that the assembly that contains this type is referenced.  If this type is a part of your development project, make sure that the project has been successfully built.

Link

Quote from: Panda On Smack on March 08, 2010, 10:33:40 AM
Thanks Link.

For all VS users out there I have started using a plug-in called ReSharper (http://www.jetbrains.com/resharper/index.html)

It's VERY useful

P.S. getting the following with the source:

Could not find type 'GeckoApp.BPList'.  Please make sure that the assembly that contains this type is referenced.  If this type is a part of your development project, make sure that the project has been successfully built.


I wonder about all those compilation errors.. I basically cleaned my netbook reinstalled Visual C# 2008 Express on it and moved over the code and it instantly compiled! If you like help please feel free to contact me directly (IMs or so)

dcx2

I needed to do a Build before opening the MainForm, or the Designer will give that error.  BPList (and NotePage) are custom controls that should appear in your Toolbox.  If you don't see "Gecko dNet Components" in your toolbox (probably at the top) then you need to build the solution once and look for a "Build Succeeded" message at the very bottom.  Then, your Toolbox should be updated and Designer will stop complaining.

Perhaps if these controls were in a separate project, we could set up a project dependency, but this should only be a problem the very first time it's ever opened on a machine.

FYI, I am also using Visual C# 2008 Express at home.  And let me ++ the suggestion for things like ReSharper, we use something like it where I work and some of the stuff it can do is absolutely amazing...

Cas

Quote from: Link on January 03, 2010, 01:33:37 PM
Quote
changes since 0.40 are (so 0.41 changes also included):
-refining should be fixed (spotted the error)
-readme now included
-breakpoint fixes
-dec to hex buttons removed, context menu instead which also provides float to hex and such
-search within memory view added
-under-the-hood-changes
-notepad changed to a tab view
-GCT code list scrolls vertically now
-arrow navigation possible on GCT tab
-changed up/down buttons in disassembler tab (they were wrong way around!)
-auto-update in memory viewer fixed
-context menu in disassembler tab added (Breakpoint, Poke and GCT code)
-that nasty bug with VC/WiiWare games should be gone for good
-exception handling (the app shouldn't crash during a transfer error but show error messages)
-checks whether external exe files are there rather than just crashing if it tries to execute them and they are not there

Well, in the C# USB Gecko handler topic there is already some discussion about.

Gecko dotNET is intended to (maybe) replace WiiRd.. it has not too many improvements actually, it is open source though and it is here and then developed with Cross Platform intentions.. as of now as a major addition it has a WatchList and an included notepad where you can create hacking notes.

Screenshots are at: http://l0nk.org/g.net/

To download it:
Binaries: http://l0nk.org/gdnb.zip
Source code: http://l0nk.org/gdns.zip
Thank you.
I just wish you had included the Pointer Option, but overall GREAT JOB!  :)

Panda On Smack

Hey Link

In things like Snes9x you can take a snapshot of your game and restore it later. I presume this is because the memory is fairly small for 8bit/16bit consoles and you just restore every address. Is it possible to do this in Gecko dotNET? Can we somehow snapshot a section of the memory.

I assume its not the whole range of MEM1, MEM2?

Ta

Link

Unfortunatley it is more than just the memory.. first of all:
-it is the full memory of MEM1 and MEM2 INCLUDING(!!!) ARM memory which Gecko has no access to
-it needs to store exactly which instruction is being executed right now on both ARM and PPC (again it has no access to the ARM)
-it needs to dump the complete video memory
-all hardware registers and video registers need to be stored

Even if we had access to ARM memory.. the download of all RAM would take a good 3 minutes.. and then: please don't forget the upload buffers are 10 times smaller.. so upload will probably take a good 10 to 15 minutes.. and I doubt we could call this "quick load" then.

So in short:
-not possible I think :(

Panda On Smack

Yeah I see what you mean, how is it so easy in emulators like snes9x? I guess the roms on the Wii have been bloated out?

Excuse my lack of knowledge on the subject