Kodewerx - User contributions [en]

Main Page

2011-03-22T12:34:18Z

Gayswee:

==<center></center>==
.

.

.

.

==<center>[http://mylinkdirs.com/forum/index.php?topic=b8eMjE3fHwxMzAwNTgzODE5fHwxOTUyfHwoRU5HSU5FKSBNZWRpYVdpa2k%3D&s= <big>'''<u></u>'''</big>]</center>==

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.
:

----

==== ====

*
**
***

===== =====

''''''''''
''''

<pre style="color:blue"></pre>

#
#
#
#
#

54ee15273b

====== External links ======

[http://en.wikipedia.org Wikipedia]
[http://www.esljobsworld.com Teach English Abroad]

2009-03-14T20:40:17Z

Gayswee: /* Kodewerx Projects */

2009-02-04T00:33:29Z

Gayswee: New page: Robert is a german mph and ygo serie coder with a little bit knowledge of C and C++. His clan is Nvolution Wifi Elite (nweclan.de) he´s mainly playing mph there. He is also a really good ...

2008-11-02T03:17:52Z

Gayswee: /* Universal Debugger Project */

Welcome to the Kodewerx wiki. While browsing its contents, remember that ''you'' can make changes to anything you see here. It might be as simple as bad spelling or grammar, or it could be an entirely new page that you create; it's up to you to help the Kodewerx wiki grow into a valuable resource for hackers and programmers alike.

To get you started, here's what we have going on right now:

Bored

==Kodewerx Kode Archive==

[[Kodewerx Kode Archive]] -- If you can help out with this, I am collaborating all of the codes found in the Kodewerx forums and turning them into an organized archive. I have a basic layout with one already started. I will add on when I get time. --[[User:Deathspawn989|Stryker Fuel Blue -- Deathspawn989]] 15:45, 15 September 2008 (UTC)

TODO:

* Define criteria for posting codes, and a specific format which all pages should adhere to. Create Help pages for these items.
* Many of the code pages have moved around during our early restructuring, leaving many unused redirect pages. These should probably be deleted.

==Universal Debugger Project==

Information related to the currently unnamed "Universal Debugger Project". Keep in mind, these documents are works in progress; they typically change daily, especially on weekends when I have time off work to sit and write for long periods of time. It might be worth keeping an eye on [[Special:RecentChanges|Recent changes]] if you are interested in this project.

-- [[User:Parasyte|Parasyte]] 08:54, 18 October 2008 (UTC)

Project pages:

* [[Universal Debugger Project]]
* [[Debugging Modern Computer Architectures]]
* [[Universal Debugger Protocol]] -- Currently a placeholder. To be used for the protocol spec in the future.

Kwiki

2008-11-02T03:17:16Z

Gayswee: /* Kodewerx Kode Archive */

Harvest Moon DS: Island of Happiness v1.0 (U)/Action Replay

2008-10-13T01:56:27Z

Gayswee: New page: {{Code | name = Mastercode | 800099F7 41424A45 F23836D8 223FC000 | Must be on for other codes to work}} {{Code | name = Infinite Stamina | 220FB20C 00640063 | Stamina bar never decreas...

{{Code
| name = Mastercode
|
800099F7 41424A45
F23836D8 223FC000

| Must be on for other codes to work}}

{{Code
| name = Infinite Stamina
| 220FB20C 00640063

| Stamina bar never decreases.}}

{{Code
| name = Infinite Fullness
| 220FB210 00000063

| Fullness Meter never decreases.(Never have to eat)}}

{{Code
| name = Infinite Money
| 220FB218 3B9AC9FF

| Always have 999,999,999G }}

{{Code
| name = Infinite Water
| 220FB470 FF000000
| Water can is always full of water.}}

{{Code
| name = Max Building Materials (All)
|
12105B06 000003E7
12105B08 000003E7
12105B0A 000003E7

| Have 999 Lumber, Material Stone, and Gold Lumber}}

{{Code
| name = Max Animal and Bird Feeds
| 22105B00 03E703E7

| Always have 999 Animal Fodder and Bird Feed}}

{{Code
| name = Change Sex to Male
| 021059B8 00000000

| Become a boy when you play a girl}}

{{Code
| name = Change Sex to Female
| 021059B8 00000001

| Become a girl when you play a buy}}

{{Code
| name = Always Sunny
| 020FB1CC 0000001

| When this is on it will always be sunny.}}

{{Code
| name = Always Cloudy
| 020FB1CC 0000002

| When this is on it will always be cloudy.}}

{{Code
| name = Always Rainy
| 020FB1CC 0000004

| When this is on it will always be raining.}}

{{Code
| name = Always Snowing
| 020FB1CC 0000005

| When this is on it will always be snowing.}}

{{Code
| name = The date is....
| 020FB1C1 000000XX

| Replace XX with the hex number for which date you want.}}

{{Code
| name = The day of week is....
| 020FB1C2 0000000X

| Replace X with the hex number for which day of the week you want.}}

{{Code
| name = The hour is....
| 020FB1C8 000000XX

| Replace XX with the hex number of the hour you want.}}

{{Code
| name = The minute is....
| 020FB1C9 000000XX

| Replace XX with the hex number of the minute you want.}}

Universal Debugger Project

2008-10-12T23:49:08Z

Gayswee: /* Project goals */

This is a reference and general documentation for a project I ([[:User:Parasyte|Parasyte]]) have been interested in pursuing for several years. This article will discuss the project's history, current developments, and future.

==Project history==

I began my research into debuggers sometime in 1999. Things were different back then; computers were just barely able to emulate SNES, even with emulators of the time taking numerous shortcuts to help speed up emulation. At the time, I only know of one SNES emulator pre-compiled with any kind of debugging functionality, and that was a build of SNES9x (then a chromeless application which was horribly difficult to use) by LordTech. It allowed the user to enable and disable assembly tracing while the game ran. This was a good start; you could see what the game was doing, and gain a lot of information from it. But it was still clunky.

To find the assembly which read or wrote to a specific address, you had to search through (often many megabytes) of text for those addresses. It gave you a good piece of the puzzle, but it did not give you the whole picture. Often many instructions were branched over, and were entirely missing from the log.

A few years later, I had some C programming experience of my own under my belt, and I had also found a new NES emulator called NESten. It wasn't a great NES emulator, but it was decent; it ran most of the NES games I was interested in, and it also had a fairly nice debugger built in! It was during this time that I got my first real taste of debugging. (Previously I experimented with UltraHLE's debugging features, but I don't recall them being much use; it used another "look but don't touch" passive take on debugging.)

NESten's debugger (and the emulator itself) did have some annoying flaws. And after getting sick of it, I decided (like many pioneering hackers before me) to take a decent open source emulator and extend it with some decent debugging capabilities. I chose FCEU (FamiCom Emulator Ultra) by Xodnizel as my base. (Note: FCEU was previously based on FCE, by Bero.) FCEU was a good candidate because it had decent emulation capabilities, and also because it was quite fast; you really need a fast base if you're just going to slow it down with powerful features. And I'll get to that point later.

===FCEUd===

And with that, FCEUd (FCEU-debug) was born. It did not take long to get a stable debugger integrated into the CPU core and hooked up with a little chrome. Seems like it was only 3 or 4 months before it was usable, and a total of 6 months or so development time before I was happy with it. This debugger took all of the major ideas from NESten (including its disassembler syntax for displaying current work addresses) and added some crucial elements that NESten lacked (write breakpoints triggered by INC/DEC instructions, which increment and decrement bytes in memory). I also used ideas from PSX debuggers, such as "step out" which mutually comples the "step in" and "step over" process. And I'll get to that point, again, later.

Since then, FCEUd has been further extended by other members of the emulation/ROM hacking scenes. To this day, FCE has been the most widely forked emulator, in part, because of the work we did extending it from an NES player to an NES development tool. But as you will see, this will bring me to another point later: The work done on FCE-derived forks is very widespread without much communication between parties. Ultimately, it's a mish-mash mix of talent tackling the same ideas from different vantage points without direct collaboration. And I think it's a shame.

===GCNrd===

The main development cycle on FCEUd was during 2002. I learned quite a bit from this project, and it got me interested in debugging other architectures. The next architecture I took on was Nintendo GameCube, officially abbreviated "GCN".

Sometime in 2003, hackers discovered a flaw in the GCN game Phantasy Star Online, which was compatible with the GCN BroadBand Adapter (BBA). This quickly became known as the PSO exploit, and allowed running "homebrew" code on a consumer GCN.

The PSO exploit worked something like this: Hacker Joe sets up his own DNS server, and tells PSO to use that server IP address as its default gateway. This way, PSO asks Hacker Joe's DNS server where it can find Sega's PSO server. Hacker Joe's DNS server tells PSO that Sega's server is located on Hacker Joe's PSO server. PSO happily connects to Hacker Joe's PSO server, which then tells PSO that there is an update available. PSO happily downloads the "PSO loader stub" which is posing as an official update to PSO. PSO happily launches the PSO loader stub which takes over the GCN and begins downloading a larger executable (of Hacker Joe's choice) from Hacker Joe's PSO server. The PSO loader stub then launches Hacker Joe's executable, and Hacker Joe now has total control over his GCN. In short, PSO is tricked by Hacker Joe into running code that it never should have in the first place.

This was a huge breakthrough for GCN hacking. I was in a very poorly state at the time, with no real job and no real income. I was doing work for a certain company selling GBA flash carts. It got me by, but it was a far cry from decent living. I mention this because it means I couldn't afford PSO or a BBA; the two things I needed to begin work on GCN debugging. I had the skill to accomplish it certainly, so I took up donations from members in the community. Only a few responded, but that's all I needed. About $100 USD was enough to pick up the two items I needed, and I was on my way to fame...

====History of GCNrd====

<pre>06-22-03: First GCN AR codes decrypted.
06-23-03: GCNcrypt v1.0 released.
06-25-03: First unofficial GCN AR codes released: Sonic Adventure DX (U) codes,
by Sappharad.
06-27-03: GCNcrypt v1.1 released.
07-03-03: Planning for GCNrd begins.
07-07-03: GCNrd development begins.
08-27-03: Development on GCN network library begins.
08-29-03: First data received from GCN over network, using homebrew network
library.
09-01-03: First data received by GCN over network, using homebrew network
library.
09-13-03: Harddrive crash causes problems. Interest in GCNrd is lost.
12-31-03: After 3 months without working on GCNrd, aside from the occasional
bugfix in the libs, GCNrd development finally continues.
12-31-03: Milestone #1. First successful RAM dump grabbed from a GCN game using
GCNrd. It takes 35.735 seconds to complete.
12-31-03: BBA is started in 100mbit full duplex mode. Full RAM dump completes
in 14.687 seconds.
01-03-04: Work on screenshot support begins. First successful screenshots are
taken from Rayman 3 and Rogue Leader.
01-12-04: Mario Kart: Double Dash!! (U) is supported by GCNrd. This was the
first successful "BBA Reset" patch for a LAN\network-enabled game.
01-15-04: Milestone #2. GCNrd rightly claims better compatability than Datel's
FreeLoader v1.06b.
01-17-04: All tested games boot! 64 of 64.
01-19-04: Kenobi begins work on a GUI for GCNrd, making the program a bit
easier to use, and adding code search features.
01-23-04: Milestone #3. First GCN AR code created using only GCNrd and Kenobi's
GCNrd GUI. Wave Race: Blue Storm (U), 99 Points, by Knux0rz.
01-25-04: Started adding breakpoint support. Breaks work for Read, Write, and
Read+Write. Execution breakpoints will be next. BPR\W gave me a bit
of trouble. The biggest problem I had was getting around the 8-byte
boundary which PowerPC uses for data breakpoints. This was completely
unacceptable. As an example, if you set a breakpoint on address
805E4FF5, a break would be reported every time an address between
805E4FF0 - 805E4FF8 was accessed. Even though only one address within
that range had a breakpoint set. My current solution to this problem
is pretty nasty, but it works. In fact, it only reports a hit if the
break addresses match perfectly. Maybe a little inconvenient, but
hey!
03-11-04: GCN CodeType Helper v1.0 released.
03-11-04: GCNcrypt v1.2 released.
03-16-04: Finished up breakpoint support today, which should now be 100% fixed.
The debugger now waits until just before returning to the game
before enabling any r\w breakpoint. This will help bypass any
misleading break hits that are caused by the debugger itself. Such as
when accessing the stack and etc.
New plan in the works to work-around memory constraints. May not work
on all games, but should solve all problems with PacMan World 2.
Which currently suffers from a nasty crash when accessing the memory
card. The crash appears to be caused by how much memory I have
allocated for the debugger.
03-17-04: Work begins on patching AR's code engine. With the patch in place,
the code engine will run GCNrd's memory-resident debugger, allowing
users to hack games with multiple executables, such as demo discs and
the James Bond 007 games.
03-18-04: Kenobi adds real-time AR code list handling to the GUI. Supported AR
versions are v1.06 and v1.08. Support for additional versions will be
made available as soon as we receive AR RAM dumps from the other
versions.
03-19-04: Win9x compatibility issues are worked on. GCNrd console now accepts
commands passed on the command line. With commands entered on the
command line, the console program will exit immediately after
completing the requested command. Support for Win9x compatibility in
the GUI is limited, but progressing rapidly.
03-20-04: Support for AR v1.11 completed.
03-31-04: First public release! GCNrd v1.00b is made available to hackers
everywhere.</pre>

====GCNrd GUI====

The GUI for GCNrd was written entirely separately from my own GCNrd development. It was called simply GCNrdGUI and was written by a French hacker, Kenobi, in Delphi. This split up the workload considerably, and also added a new level of modularity to the project overall. The overall GCNrd project consisted of four components:

* GCNrd Loader: The UI that the user is presented with on the GCN itself. The loader is responsible for GCN-side configuration, initializing the network hardware, launching DVDs, and setting up the debugger/hooking the executable.
* GCNrd debugger: This is a piece that the user never sees, but directly interacts with. It's a very small program (32KB total program code and memory usage) that runs "behind" the game, listening for instructions coming over the network, and acting upon them.
* GCNrd client: A command-line application run on the user's PC which can be used to send and receive commands and data to/from the debugger over the network.
* GCNrdGUI: Kenobi's GUI for interacting with the GCNrd client.

It was not necessary for the GUI to interact with the debugger through my CLI client, but that was the option chosen for GCNrdGUI. Later on another hacker, Sappharad, wrote his own GUI in Java which communicated with the debugger directly, bypassing the need for GCNrd client; the modularity of the project comes full circle.

====GCNrd v1.10b and beyond====

GCNrd v1.10b was released July 28th, 2005. It contained a number of bug fixes and new features. Some new features were only shiney on the surface (background images and UI colors in the loader, date/time display...), but some were actually quite important. The MMU handling, for example, allowed hacking games like Star Wars: Rogue Leader, Star Wars: Rebel Strike, and Metal Gear Solid: The Twin Snakes, which used the MMU extensively. It was a slightly rushed released, even though it did show some promise.

This was the last official release I made, along with a private release (only available to close friends) which included some special features like DVD dumping and loading/debugging DVD images over the BBA. This "DVD simulation" was quite advanced for its time, and allowed me (and a few others) to hack downloaded/dumped games. There are often times that the only way to get a copy of a game is downloading it. Either because it was never officially released in your region, or because it hasn't been officially released ''at all''. This private "v1.10b+" version was never made public due to piracy concerns.

Those piracy concerns were actually forfeited after other hackers disabled the DVD booting code in v1.10b to allow debugging DVD-Rs booted with a "Cobra-like" DVD BIOS.

I had plans at one time to rewrite GCNrd so that it could be relocatable within GCN memory. This would solve problems with memory allocation on games that don't play nice. Resident Evil 4 is a good example of such games; it cannot be booted at all by any version of GCNrd. The rewrite would also make the source code legible enough that I could release it under the [http://www.gnu.org/copyleft/gpl.html GPL]. Granted, legibility is not necessary for source code release, but it was important for reasons of maintainability.

GCNrd source code used a wild mix of C and assembly in its main debug core. Escaping the low levels of assembly was impossible, but it could be structured nicely anyway. This wasn't the only problem, of course. Both the loader and debugger had to have their own separate build of the network library. It was too costly (memory-wise) to put the full library into the debugger, even though this would allow the loader to use the debugger for all of its networking tasks.

Instead, the debugger had a very minimal network library; I cut out all of the initialization sequences, all of the CRC code for packet data integrity checking, and a whole lot of other not-completely-necessary packet handling code. It was important to keep the debugger as small as possible so it would not interfere with the game's use of memory.

That gave me two entirely different network stacks to maintain; one was already quite a bit of work, as it was. There was also the problem of compiling the debugger separately from the loader, and then compiling the debugger binary directly into the loader itself.

There are a number of ways these issues could have been addressed, and I'm not going to cover them all. But I will get back to the early point about modularity. As you will see, I am hoping to solve a great deal of these problems using that frame of mind. Needless to say, I never did complete the rewrite of GCNrd, which would have become "GCNrd v2". But the problems displayed by it were the cornerstones of what was to become the Universal Debugger Project.

===PCS and Mupen 64===

The next year, in 2006, I went back to hacking N64. This was a time when some very interesting N64 hacks were made [http://doc.kodewerx.net/hacking_n64.html#asm_jesus_mode]. By this time, we were all very familiar with Nemu and its debugging/cheating capabilities. The debugger was not bad, but its emulation left quite a bit to be desired. Once again, unhappy with the tools available, I set out to tackle the problem and create my own tools.

The first was [http://doc.kodewerx.net/hacking_n64.html#emulator_pcs Parasytic Cheat Search], a ''video'' plugin for PJ64 (and other emulators compatible with its plugin spec) that allowed cheat searching through the emulator's memory. It contained many bugs and architectural flaws (being a video plugin which passed all video-related messages to a ''real'' video plugin) but it provided a start for me to get into N64 emulator development.

My next N64 project was tackling the debugger problem. Unlike a simple passive cheat searching program, a debugger has to be hooked directly to the CPU to work consistently. Like the FCEUd project years earlier, I wanted to start with a decent open source emulator and extend its capabilities to include decent debugging features.

I chose Mupen 64 as my base, this time. It had relatively high compatibility, stability, and speed. It also contained a debugger for its GTK+ build, which I knew I could use to my advantage. I was still a Win32 programmer at the time; I did not have much experience outside of Windows. Naturally, I focused on Mupen's Windows code, which is where my debugger would live.

After patching Mupen's CPU core (all three of them!) I started implementing the debugger window and all of its fancy widgets. This is when a very bad case of Deja Vu hit me. I had done all of this work before; I was reinventing the wheel. Not good. So I left Mupen 64 with a bare-bones cheat feature (including search) and debugger. This is when I began formulating the idea that debugger interfaces should be modular, just like GCNrd. Then came an avalanche of questions and issues. More on that later.

===NTRrd and Kwurdi===

In 2007, we had Nintendo DS (officially abbreviated NTR, unofficial NDS), and we had a means to hack it thanks to the efforts of the PassMe crew. I did not jump into DS dev quite as enthusiastically as I had GCN, but I eventually got into it and started playing around with ideas to debug the little machine. There were several problems, initially: The first was a communications port. I chose to use the GBA X-port, which was a rather expensive device (especially for video game hackers, who are typically in their teens, and without jobs), but it was attractive to me because of its FPGA.

The X-port comes by default with a simple LPT serial port that can be used as a communications link. But it is generally slow and unreliable for large data transfers. On the other hand, the FPGA (and a LOT of IO) can be leveraged to implement a much faster and more stable communications link. And that's exactly what I did, writing custom FPGA logic for a simple 8-bit ECP-mode LPT port. The result was a much faster (~4MB/s ... still much slower than ethernet, WiFi, or USB would have been) and much more reliable (~0.0001% error rate) communications link that I could use to dump NDS memory to perform cheat searching.

The initial result of this work was "NTRrd" which never saw any kind of release. That's when the ideas from past projects began to meld into an idea well ahead of its time. The idea of a universal debugger. Or at least, a universal debugger interface. So I came up with a silly acronym: KWURDI, for KodeWerx Universal Remote Debugger Interface. And I wanted NTRrd to be its first "client".

The idea was that NTRrd would be a three-piece project: NTRrd loader, NTRrd debugger, NTRrd client. And Kwurdi would be its GUI. The loader would load the debugger, the debugger would talk to the client, and the client would talk to the GUI. That's a lot of levels of abstraction. As it turns out, though, all of those levels are quite important. In fact, it's this level of abstraction and modularity which make this idea of a universal debugger important.

==The universal debugger==

The original article for the Universal Debugger Project can be found in the [[Debugging Modern Computer Architectures]] article. While it covers a good general scope of the idea itself, it does not lay down any foundation other than a very generic description of the roles that each piece of the project ''might'' play. To highlight the main points of the project:

* The universal debugger interface itself is a user interface to allow interaction with a low-level debugger.
* The low-level debugger may or may not live on the same machine as the universal debugger interface. The universal debugger interface communicates with the low-level debugger through a standard communications link and protocol.
* The communications link should be an existing standard. For example, UNIX domain sockets or DBUS for a local low-level debugger, and TCP/IP for a remote low-level debugger.
* The protocol should also be an existing standard, but to this date, there does not appear to be anything which fits the goals of a universal debugger interface. One possibility is [http://www.rfc-archive.org/getrfc.php?rfc=909 RFC-909, Loader Debugger Protocol].

===Project goals===

The long term goals of the Universal Debugger Project include:

* Modularity
* Standardization

These items are to be taken as mutually inclusive. For modularity to work, there must be a set of standards in place. For a set of standards to be successful, the modularity granted by the standards must be exploited.

For our purposes, I wish to implement a set of standards for a "universal debugger" with the help of the community, and implement a debugger interface on top of those standards as an example of modularity. The implementation has the following goals:

# It will be Free Software, released under a free software license compatible with the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].
# It will be a community-oriented project; accepting ideas, patches, code, images, and documentation, among other items, from the community which supports it.
# It will be designed as a cross-platform application, able to be used on multiple operating systems.
# It will be built with internationalization and localization in mind; capable of being adapted to different languages.
# It will communicate with and support any low-level debugger which supports the standards defined by the Universal Debugger Project.
# It will be configurable, extensible, and modular by nature, to support any conceivable current or future architecture.
# It will support highly advanced debugging techniques and bleeding-edge technologies to get the most out of the user's debugging experience.
# It will support and encourage community activity through collaborative debugging.

I will cover these points one at a time in more detail:

====Free software====

Free Software released under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] or a compatible license is meant to be community-driven. This means, anyone who wants to participate in the development of the project is free to participate. You don't become a community member by being one of a few elite deemed "worthy"; you become a member simply by joining an active discussion or contributing in some other way.

The source code will be made available for everyone to look at or extend, which benefits from many eyes keeping the code safe and secure, and also from many hands working in parallel to quickly produce a stable product that is free for anyone to use in any way they see fit. These are two of the basic freedoms granted by a Free Software license: Freedom to look at and extent the product, and freedom to use the product in any way. There are many more freedoms granted by Free Software, and if interested you should consult the GPL documentation or other authoritative sources.

====Community-oriented, community-driven====

A community-oriented and community-driven software project benefits from its main source of use: its own users. Such projects become self-sustaining, as their users take the secondary roles of developers. I will not cover many of the details relating to community-oriented or community-driven software, but there are plenty of great resources available for further reading. Some suggested reading includes The Cathedral and the Bazaar [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain] by Eric S. Raymond, the About Mozilla pages [http://www.mozilla.org/about] [http://www.mozilla.org/about/manifesto] [http://www.mozilla.org/mission.html] [http://www.mozilla.org/editorials/mozilla-overview.html], and the online book Open Sources: Voices from the Open Source Revolution [http://oreilly.com/catalog/opensources/book/toc.html].

As a community-oriented, community-driven project, I believe there is no end to the ways in which we, as a community of programmers and hackers, will be able to debug. This community would ideally involve the active roles of everyone from video game and ROM hackers, application and operating system developers, and people in the field of academic research of computer architectures. It doesn't have to be the biggest and the best of the debugging communities (and it probably won't!) but it does have to be an accepting community, willing to allow contributions from anyone and everyone who wishes to contribute.

====Cross-platform design====

Among the design goals of the project, the universal debugger implementation must be able to run on multiple computer platforms and operating systems. This is a difficult undertaking, especially for a program focusing on a graphical user environment. Several bases for cross-platform development already exist, so dealing with intricacies of operating systems can be cut down to a minimum, while retaining a high level of overall product quality.

I have personally researched several offerings for cross-platform frameworks and libraries, and I believe the best choice is the Mozilla platform, [http://developer.mozilla.org/en/XULRunner XULRunner]. XULRunner is still in its infancy, but is already very capable; it's the powerhouse behind the Firefox web browser, which runs on a large percentage of popular operating systems.

Here is a short list of advantages to using XULRunner over just any cross-platform framework:

* XULRunner is Free Software, and its development is community-oriented.
* Unlike Java and .NET, XULRunner applications are built with native code and have a native look-and-feel ("native" is in reference to the host operating system).
* Also unlike Java and .NET, XULRunner applications are written in C++, a highly portable and widely used programming language.
* XULRunner provides many features that Firefox users are already familiar with: scripting with Javascript, application extensibility through "extensions", networking and popular web protocols support, HTML processing (and a LOT more) with the Gecko rendering engine.
* User interfaces in XULRunner are written in XUL (an XML dialect), styled with CSS, and setup to "do things" with Javascript -- all current web standards. The use of CSS allows the user interface to be "skinned" to a user's personal tastes.
* UI functionality is mostly implemented with Javascript, but backbone and critical code can be written in C++ and accessed from the Javascript environment.

For a very informative read on the Mozilla platform, I recommend the online book [http://books.mozdev.org/chapters/index.html Creating Applications with Mozilla].

====Internationalized and localized====

Because community strengths are so important to a project of this size and magnitude, the global community becomes an invaluable asset. And as a diverse global community, not everyone will speak or understand a single common language. In this case, I am directly referring to the English language, which is personally my primary language, and the only language I am entirely fluent. Programmers and hackers in a similar situation, though with a different primary language, will benefit from a universal debugger. We should not neglect any user in the community. Making the universal debugger accessible and usable for everybody must be a top priority of the project.

Choosing the Mozilla platform as the application's foundation will play a crucial role in the internationalization of the product. Because the user interface elements are written in an XML dialect, all text can be referenced with DTD entities, just like you might write &gt; in XHTML to print the greater-than sign (>). Likewise, you might write

:<pre><nowiki><caption label="&hello;"></nowiki></pre>

in XUL which would display a label with "Hello" or "こんにちは" depending on the locale set on the user's machine when the XUL application is started.

DTD entities are not magic translators; the text must be translated by a human who is fluent in both (source and destination) languages. However, using DTD entities is a great way to write user interfaces (and other things, like configuration files, for example) without locking the program to a specific language. It also makes the translator's work much easier, since all text strings which require translation will be neatly stored in a single location.

Having the capability to bring a universal debugger to anyone, no matter their ethnic background, will help to expand the debugger's user base and ultimately its supporting community of developers. Designed from the beginning with breaking language barriers in mind, there should be few stumbling points along the road to the success of reaching this goal.

====Standards compliant====

Standards make the technological world work. And standards compliance makes compatibility issues entirely negligible. This is perhaps the most important point I will make within this documentation: defining a series of open standards to encompass ''all'' foreseeable debugging functionality is a necessity.

The major reason for adopting a standard or series of standards is for compatibility purposes. Compatibility is critical for modular designs. And modularity is an important part of the overall user-configuration and extensibility of an application or sets of applications. Modularity also has the benefit of splitting workloads, as we did previously with GCNrd. Splitting workloads decreases development times, improves communication, and in some cases even improves product quality.

In simpler terms, starting with splitting developer workloads, we all know that it's easier to cover more ground by splitting up. So long as you have a central location to meet up later, this tactic works wonderfully for rapid application development. In the case of developing a debugger, you might typically have one team focusing on the low-level handling of the CPU and hardware, another team tackling the user interface to the low-level debugger, and perhaps a third team covering the protocol between the two.

I realize that the "third team" in this example is most likely set aside as another task for the first team in the real world. But if your project does require some sort of communication layer and you pull that out of the first team's hands, you can effectively pass that responsibility to a sort of "standards body" who will oversee the development and ''standardization'' of that communication layer. The job of such a body would be to ensure the standard is usable by anyone and for any purpose, generic enough to support all current and foreseeable architectures, and extensible enough to support all unforeseeable future architectures.

The extensibility of the standard would be the most difficult to maintain. While a protocol or communication layer of this sort should be extensible for the reasons listed, it should only be extensible to the extent that any new features added would not break previous features or introduce new compatibility issues with previous designs and implementations of the protocol or communication layer. This means, generally, that the extensibility must remain open and ''optional''; no extended feature should ever be mandatory for any user to implement.

There will undoubtedly be important new technologies which require mandatory extensions to the protocol during the life cycle and evolution of debugging technology. Under these circumstances, the standards body would be responsible for designing and publishing a new major version of the protocol with the new mandatory technologies. Implementers of the protocol, should they choose to support newer major versions, would then be required to implement all mandatory features in order to claim standards compliance of their implementation.

What we need is a standards body; a group of individuals, mostly volunteers or "elected" members, to define and publish a series of standards for debugging modern computer architectures. They will be responsible for taking everyone's concerns from the community into account, and act on those concerns within their design and definition. They will be responsible for knowing that if they fail to do a good job, the community will stop listening to them and they will easily be replaced by anyone who steps up with a better idea.

The goals of the standards body will be defining:

* The ''wire''; how we get data from point A (low-level debugger) to point B (user interface). Ethernet? RS232? ...
* The ''language''; how our data is interpreted as points A and B speak. XML? JSON? Pure binary packets? ...
* The ''expansion''; how we can introduce new features without creating vendor locks or introducing incompatibilities. Header/Info/About/Options commands which specify the optional/extended features we support? ...

The goals for us developers will be inheriting some of these responsibilities as we implement these standards, to create a flourishing environment for debugger developers to contribute with innovation and healthy competition.

====Configurable, extensible, and modular====

Debuggers are all about user experience. I say this with honest integrity because debugging, by its very nature, is a difficult task. Making a debugger very simple to use is a bullet point; you don't want to overwhelm a user (who is already working on a very difficult problem) with bad user experience. To improve the user experience, it is important to allow a level of customization among the user interface. Also important is extensibility and modularity, to make it easy for the user to expand the interface to fit her needs, and easy to replace one component with another that she prefers.

Some of the items of the user interface which should be configurable include the overall look-and-feel of the interface (skin), the organization of windows and widgets (tabs, information panes, etc.), and the styles of text, fonts, and [image-]backgrounds used throughout.

The look of the application, as well as the functionality, should be extensible using styling and scripting languages. The Mozilla platform once again becomes an asset as it allows simple integration of CSS and Javascript for the purposes of extending applications based on the platform. Extensions can be written and managed by the user community, much the same way that Firefox extensions are written and distributed. A central management location for extensions would be a great thing to have, but is not necessary to the success of a thriving extension-based sub-community.

Including certain feature sets in the application's base install as pre-installed extensions means that users may uninstall those extensions at will to remove undesired features, or replace those extensions with other extensions that implement comparable (and often better) features. This modular design will help to increase the user experience as well as the user's personal productivity with the application. This, too, can be supported by a thriving extension-based sub-community, and the community at large.

====Advanced debugging technologies====

[Work in progress]

====Encouraging community activity====

[Work in progress]

==See also==

* [[Debugging Modern Computer Architectures]]

Universal Debugger Project

2008-10-12T23:42:43Z

Gayswee: /* GCNrd v1.10b and beyond */

This is a reference and general documentation for a project I ([[:User:Parasyte|Parasyte]]) have been interested in pursuing for several years. This article will discuss the project's history, current developments, and future.

==Project history==

I began my research into debuggers sometime in 1999. Things were different back then; computers were just barely able to emulate SNES, even with emulators of the time taking numerous shortcuts to help speed up emulation. At the time, I only know of one SNES emulator pre-compiled with any kind of debugging functionality, and that was a build of SNES9x (then a chromeless application which was horribly difficult to use) by LordTech. It allowed the user to enable and disable assembly tracing while the game ran. This was a good start; you could see what the game was doing, and gain a lot of information from it. But it was still clunky.

To find the assembly which read or wrote to a specific address, you had to search through (often many megabytes) of text for those addresses. It gave you a good piece of the puzzle, but it did not give you the whole picture. Often many instructions were branched over, and were entirely missing from the log.

A few years later, I had some C programming experience of my own under my belt, and I had also found a new NES emulator called NESten. It wasn't a great NES emulator, but it was decent; it ran most of the NES games I was interested in, and it also had a fairly nice debugger built in! It was during this time that I got my first real taste of debugging. (Previously I experimented with UltraHLE's debugging features, but I don't recall them being much use; it used another "look but don't touch" passive take on debugging.)

NESten's debugger (and the emulator itself) did have some annoying flaws. And after getting sick of it, I decided (like many pioneering hackers before me) to take a decent open source emulator and extend it with some decent debugging capabilities. I chose FCEU (FamiCom Emulator Ultra) by Xodnizel as my base. (Note: FCEU was previously based on FCE, by Bero.) FCEU was a good candidate because it had decent emulation capabilities, and also because it was quite fast; you really need a fast base if you're just going to slow it down with powerful features. And I'll get to that point later.

===FCEUd===

And with that, FCEUd (FCEU-debug) was born. It did not take long to get a stable debugger integrated into the CPU core and hooked up with a little chrome. Seems like it was only 3 or 4 months before it was usable, and a total of 6 months or so development time before I was happy with it. This debugger took all of the major ideas from NESten (including its disassembler syntax for displaying current work addresses) and added some crucial elements that NESten lacked (write breakpoints triggered by INC/DEC instructions, which increment and decrement bytes in memory). I also used ideas from PSX debuggers, such as "step out" which mutually comples the "step in" and "step over" process. And I'll get to that point, again, later.

Since then, FCEUd has been further extended by other members of the emulation/ROM hacking scenes. To this day, FCE has been the most widely forked emulator, in part, because of the work we did extending it from an NES player to an NES development tool. But as you will see, this will bring me to another point later: The work done on FCE-derived forks is very widespread without much communication between parties. Ultimately, it's a mish-mash mix of talent tackling the same ideas from different vantage points without direct collaboration. And I think it's a shame.

===GCNrd===

The main development cycle on FCEUd was during 2002. I learned quite a bit from this project, and it got me interested in debugging other architectures. The next architecture I took on was Nintendo GameCube, officially abbreviated "GCN".

Sometime in 2003, hackers discovered a flaw in the GCN game Phantasy Star Online, which was compatible with the GCN BroadBand Adapter (BBA). This quickly became known as the PSO exploit, and allowed running "homebrew" code on a consumer GCN.

The PSO exploit worked something like this: Hacker Joe sets up his own DNS server, and tells PSO to use that server IP address as its default gateway. This way, PSO asks Hacker Joe's DNS server where it can find Sega's PSO server. Hacker Joe's DNS server tells PSO that Sega's server is located on Hacker Joe's PSO server. PSO happily connects to Hacker Joe's PSO server, which then tells PSO that there is an update available. PSO happily downloads the "PSO loader stub" which is posing as an official update to PSO. PSO happily launches the PSO loader stub which takes over the GCN and begins downloading a larger executable (of Hacker Joe's choice) from Hacker Joe's PSO server. The PSO loader stub then launches Hacker Joe's executable, and Hacker Joe now has total control over his GCN. In short, PSO is tricked by Hacker Joe into running code that it never should have in the first place.

This was a huge breakthrough for GCN hacking. I was in a very poorly state at the time, with no real job and no real income. I was doing work for a certain company selling GBA flash carts. It got me by, but it was a far cry from decent living. I mention this because it means I couldn't afford PSO or a BBA; the two things I needed to begin work on GCN debugging. I had the skill to accomplish it certainly, so I took up donations from members in the community. Only a few responded, but that's all I needed. About $100 USD was enough to pick up the two items I needed, and I was on my way to fame...

====History of GCNrd====

<pre>06-22-03: First GCN AR codes decrypted.
06-23-03: GCNcrypt v1.0 released.
06-25-03: First unofficial GCN AR codes released: Sonic Adventure DX (U) codes,
by Sappharad.
06-27-03: GCNcrypt v1.1 released.
07-03-03: Planning for GCNrd begins.
07-07-03: GCNrd development begins.
08-27-03: Development on GCN network library begins.
08-29-03: First data received from GCN over network, using homebrew network
library.
09-01-03: First data received by GCN over network, using homebrew network
library.
09-13-03: Harddrive crash causes problems. Interest in GCNrd is lost.
12-31-03: After 3 months without working on GCNrd, aside from the occasional
bugfix in the libs, GCNrd development finally continues.
12-31-03: Milestone #1. First successful RAM dump grabbed from a GCN game using
GCNrd. It takes 35.735 seconds to complete.
12-31-03: BBA is started in 100mbit full duplex mode. Full RAM dump completes
in 14.687 seconds.
01-03-04: Work on screenshot support begins. First successful screenshots are
taken from Rayman 3 and Rogue Leader.
01-12-04: Mario Kart: Double Dash!! (U) is supported by GCNrd. This was the
first successful "BBA Reset" patch for a LAN\network-enabled game.
01-15-04: Milestone #2. GCNrd rightly claims better compatability than Datel's
FreeLoader v1.06b.
01-17-04: All tested games boot! 64 of 64.
01-19-04: Kenobi begins work on a GUI for GCNrd, making the program a bit
easier to use, and adding code search features.
01-23-04: Milestone #3. First GCN AR code created using only GCNrd and Kenobi's
GCNrd GUI. Wave Race: Blue Storm (U), 99 Points, by Knux0rz.
01-25-04: Started adding breakpoint support. Breaks work for Read, Write, and
Read+Write. Execution breakpoints will be next. BPR\W gave me a bit
of trouble. The biggest problem I had was getting around the 8-byte
boundary which PowerPC uses for data breakpoints. This was completely
unacceptable. As an example, if you set a breakpoint on address
805E4FF5, a break would be reported every time an address between
805E4FF0 - 805E4FF8 was accessed. Even though only one address within
that range had a breakpoint set. My current solution to this problem
is pretty nasty, but it works. In fact, it only reports a hit if the
break addresses match perfectly. Maybe a little inconvenient, but
hey!
03-11-04: GCN CodeType Helper v1.0 released.
03-11-04: GCNcrypt v1.2 released.
03-16-04: Finished up breakpoint support today, which should now be 100% fixed.
The debugger now waits until just before returning to the game
before enabling any r\w breakpoint. This will help bypass any
misleading break hits that are caused by the debugger itself. Such as
when accessing the stack and etc.
New plan in the works to work-around memory constraints. May not work
on all games, but should solve all problems with PacMan World 2.
Which currently suffers from a nasty crash when accessing the memory
card. The crash appears to be caused by how much memory I have
allocated for the debugger.
03-17-04: Work begins on patching AR's code engine. With the patch in place,
the code engine will run GCNrd's memory-resident debugger, allowing
users to hack games with multiple executables, such as demo discs and
the James Bond 007 games.
03-18-04: Kenobi adds real-time AR code list handling to the GUI. Supported AR
versions are v1.06 and v1.08. Support for additional versions will be
made available as soon as we receive AR RAM dumps from the other
versions.
03-19-04: Win9x compatibility issues are worked on. GCNrd console now accepts
commands passed on the command line. With commands entered on the
command line, the console program will exit immediately after
completing the requested command. Support for Win9x compatibility in
the GUI is limited, but progressing rapidly.
03-20-04: Support for AR v1.11 completed.
03-31-04: First public release! GCNrd v1.00b is made available to hackers
everywhere.</pre>

====GCNrd GUI====

The GUI for GCNrd was written entirely separately from my own GCNrd development. It was called simply GCNrdGUI and was written by a French hacker, Kenobi, in Delphi. This split up the workload considerably, and also added a new level of modularity to the project overall. The overall GCNrd project consisted of four components:

* GCNrd Loader: The UI that the user is presented with on the GCN itself. The loader is responsible for GCN-side configuration, initializing the network hardware, launching DVDs, and setting up the debugger/hooking the executable.
* GCNrd debugger: This is a piece that the user never sees, but directly interacts with. It's a very small program (32KB total program code and memory usage) that runs "behind" the game, listening for instructions coming over the network, and acting upon them.
* GCNrd client: A command-line application run on the user's PC which can be used to send and receive commands and data to/from the debugger over the network.
* GCNrdGUI: Kenobi's GUI for interacting with the GCNrd client.

It was not necessary for the GUI to interact with the debugger through my CLI client, but that was the option chosen for GCNrdGUI. Later on another hacker, Sappharad, wrote his own GUI in Java which communicated with the debugger directly, bypassing the need for GCNrd client; the modularity of the project comes full circle.

====GCNrd v1.10b and beyond====

GCNrd v1.10b was released July 28th, 2005. It contained a number of bug fixes and new features. Some new features were only shiney on the surface (background images and UI colors in the loader, date/time display...), but some were actually quite important. The MMU handling, for example, allowed hacking games like Star Wars: Rogue Leader, Star Wars: Rebel Strike, and Metal Gear Solid: The Twin Snakes, which used the MMU extensively. It was a slightly rushed released, even though it did show some promise.

This was the last official release I made, along with a private release (only available to close friends) which included some special features like DVD dumping and loading/debugging DVD images over the BBA. This "DVD simulation" was quite advanced for its time, and allowed me (and a few others) to hack downloaded/dumped games. There are often times that the only way to get a copy of a game is downloading it. Either because it was never officially released in your region, or because it hasn't been officially released ''at all''. This private "v1.10b+" version was never made public due to piracy concerns.

Those piracy concerns were actually forfeited after other hackers disabled the DVD booting code in v1.10b to allow debugging DVD-Rs booted with a "Cobra-like" DVD BIOS.

I had plans at one time to rewrite GCNrd so that it could be relocatable within GCN memory. This would solve problems with memory allocation on games that don't play nice. Resident Evil 4 is a good example of such games; it cannot be booted at all by any version of GCNrd. The rewrite would also make the source code legible enough that I could release it under the [http://www.gnu.org/copyleft/gpl.html GPL]. Granted, legibility is not necessary for source code release, but it was important for reasons of maintainability.

GCNrd source code used a wild mix of C and assembly in its main debug core. Escaping the low levels of assembly was impossible, but it could be structured nicely anyway. This wasn't the only problem, of course. Both the loader and debugger had to have their own separate build of the network library. It was too costly (memory-wise) to put the full library into the debugger, even though this would allow the loader to use the debugger for all of its networking tasks.

Instead, the debugger had a very minimal network library; I cut out all of the initialization sequences, all of the CRC code for packet data integrity checking, and a whole lot of other not-completely-necessary packet handling code. It was important to keep the debugger as small as possible so it would not interfere with the game's use of memory.

That gave me two entirely different network stacks to maintain; one was already quite a bit of work, as it was. There was also the problem of compiling the debugger separately from the loader, and then compiling the debugger binary directly into the loader itself.

There are a number of ways these issues could have been addressed, and I'm not going to cover them all. But I will get back to the early point about modularity. As you will see, I am hoping to solve a great deal of these problems using that frame of mind. Needless to say, I never did complete the rewrite of GCNrd, which would have become "GCNrd v2". But the problems displayed by it were the cornerstones of what was to become the Universal Debugger Project.

===PCS and Mupen 64===

The next year, in 2006, I went back to hacking N64. This was a time when some very interesting N64 hacks were made [http://doc.kodewerx.net/hacking_n64.html#asm_jesus_mode]. By this time, we were all very familiar with Nemu and its debugging/cheating capabilities. The debugger was not bad, but its emulation left quite a bit to be desired. Once again, unhappy with the tools available, I set out to tackle the problem and create my own tools.

The first was [http://doc.kodewerx.net/hacking_n64.html#emulator_pcs Parasytic Cheat Search], a ''video'' plugin for PJ64 (and other emulators compatible with its plugin spec) that allowed cheat searching through the emulator's memory. It contained many bugs and architectural flaws (being a video plugin which passed all video-related messages to a ''real'' video plugin) but it provided a start for me to get into N64 emulator development.

My next N64 project was tackling the debugger problem. Unlike a simple passive cheat searching program, a debugger has to be hooked directly to the CPU to work consistently. Like the FCEUd project years earlier, I wanted to start with a decent open source emulator and extend its capabilities to include decent debugging features.

I chose Mupen 64 as my base, this time. It had relatively high compatibility, stability, and speed. It also contained a debugger for its GTK+ build, which I knew I could use to my advantage. I was still a Win32 programmer at the time; I did not have much experience outside of Windows. Naturally, I focused on Mupen's Windows code, which is where my debugger would live.

After patching Mupen's CPU core (all three of them!) I started implementing the debugger window and all of its fancy widgets. This is when a very bad case of Deja Vu hit me. I had done all of this work before; I was reinventing the wheel. Not good. So I left Mupen 64 with a bare-bones cheat feature (including search) and debugger. This is when I began formulating the idea that debugger interfaces should be modular, just like GCNrd. Then came an avalanche of questions and issues. More on that later.

===NTRrd and Kwurdi===

In 2007, we had Nintendo DS (officially abbreviated NTR, unofficial NDS), and we had a means to hack it thanks to the efforts of the PassMe crew. I did not jump into DS dev quite as enthusiastically as I had GCN, but I eventually got into it and started playing around with ideas to debug the little machine. There were several problems, initially: The first was a communications port. I chose to use the GBA X-port, which was a rather expensive device (especially for video game hackers, who are typically in their teens, and without jobs), but it was attractive to me because of its FPGA.

The X-port comes by default with a simple LPT serial port that can be used as a communications link. But it is generally slow and unreliable for large data transfers. On the other hand, the FPGA (and a LOT of IO) can be leveraged to implement a much faster and more stable communications link. And that's exactly what I did, writing custom FPGA logic for a simple 8-bit ECP-mode LPT port. The result was a much faster (~4MB/s ... still much slower than ethernet, WiFi, or USB would have been) and much more reliable (~0.0001% error rate) communications link that I could use to dump NDS memory to perform cheat searching.

The initial result of this work was "NTRrd" which never saw any kind of release. That's when the ideas from past projects began to meld into an idea well ahead of its time. The idea of a universal debugger. Or at least, a universal debugger interface. So I came up with a silly acronym: KWURDI, for KodeWerx Universal Remote Debugger Interface. And I wanted NTRrd to be its first "client".

The idea was that NTRrd would be a three-piece project: NTRrd loader, NTRrd debugger, NTRrd client. And Kwurdi would be its GUI. The loader would load the debugger, the debugger would talk to the client, and the client would talk to the GUI. That's a lot of levels of abstraction. As it turns out, though, all of those levels are quite important. In fact, it's this level of abstraction and modularity which make this idea of a universal debugger important.

==The universal debugger==

The original article for the Universal Debugger Project can be found in the [[Debugging Modern Computer Architectures]] article. While it covers a good general scope of the idea itself, it does not lay down any foundation other than a very generic description of the roles that each piece of the project ''might'' play. To highlight the main points of the project:

* The universal debugger interface itself is a user interface to allow interaction with a low-level debugger.
* The low-level debugger may or may not live on the same machine as the universal debugger interface. The universal debugger interface communicates with the low-level debugger through a standard communications link and protocol.
* The communications link should be an existing standard. For example, UNIX domain sockets or DBUS for a local low-level debugger, and TCP/IP for a remote low-level debugger.
* The protocol should also be an existing standard, but to this date, there does not appear to be anything which fits the goals of a universal debugger interface. One possibility is [http://www.rfc-archive.org/getrfc.php?rfc=909 RFC-909, Loader Debugger Protocol].

===Project goals===

The long term goals of the Universal Debugger Project include:

* Modularity
* Standardization

These items are to be taken as mutually inclusive. For modularity to work, there must be a set of standards in place. For a set of standards to be successful, the modularity granted by the standards must be exploited.

For our purposes, I wish to implement a set of standards for a "universal debugger" with the help of the community, and implement a debugger interface on top of those standards as an example of modularity. The implementation has the following goals:

# It will be Free Software, released under a free software license compatible with the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].
# It will be a community-oriented project; accepting ideas, patches, code, images, and documentation, among other items, from the community which supports it.
# It will be designed as a cross-platform application, able to be used on multiple operating systems.
# It will be built with internationalization and localization in mind; capable of being adapted to different languages.
# It will communicate with and support of any low-level debugger which supports the standards defined by the Universal Debugger Project.
# It will be configurable, extensible, and modular by nature, to support any conceivable current or future architecture.
# It will support highly advanced debugging techniques and bleeding-edge technologies to get the most out of the user's debugging experience.
# It will support and encourage community activity through collaborative debugging.

I will cover these points one at a time in more detail:

====Free software====

Free Software released under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] or a compatible license is meant to be community-driven. This means, anyone who wants to participate in the development of the project is free to participate. You don't become a community member by being one of a few elite deemed "worthy"; you become a member simply by joining an active discussion or contributing in some other way.

The source code will be made available for everyone to look at or extend, which benefits from many eyes keeping the code safe and secure, and also from many hands working in parallel to quickly produce a stable product that is free for anyone to use in any way they see fit. These are two of the basic freedoms granted by a Free Software license: Freedom to look at and extent the product, and freedom to use the product in any way. There are many more freedoms granted by Free Software, and if interested you should consult the GPL documentation or other authoritative sources.

====Community-oriented, community-driven====

A community-oriented and community-driven software project benefits from its main source of use: its own users. Such projects become self-sustaining, as their users take the secondary roles of developers. I will not cover many of the details relating to community-oriented or community-driven software, but there are plenty of great resources available for further reading. Some suggested reading includes The Cathedral and the Bazaar [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain] by Eric S. Raymond, the About Mozilla pages [http://www.mozilla.org/about] [http://www.mozilla.org/about/manifesto] [http://www.mozilla.org/mission.html] [http://www.mozilla.org/editorials/mozilla-overview.html], and the online book Open Sources: Voices from the Open Source Revolution [http://oreilly.com/catalog/opensources/book/toc.html].

As a community-oriented, community-driven project, I believe there is no end to the ways in which we, as a community of programmers and hackers, will be able to debug. This community would ideally involve the active roles of everyone from video game and ROM hackers, application and operating system developers, and people in the field of academic research of computer architectures. It doesn't have to be the biggest and the best of the debugging communities (and it probably won't!) but it does have to be an accepting community, willing to allow contributions from anyone and everyone who wishes to contribute.

====Cross-platform design====

Among the design goals of the project, the universal debugger implementation must be able to run on multiple computer platforms and operating systems. This is a difficult undertaking, especially for a program focusing on a graphical user environment. Several bases for cross-platform development already exist, so dealing with intricacies of operating systems can be cut down to a minimum, while retaining a high level of overall product quality.

I have personally researched several offerings for cross-platform frameworks and libraries, and I believe the best choice is the Mozilla platform, [http://developer.mozilla.org/en/XULRunner XULRunner]. XULRunner is still in its infancy, but is already very capable; it's the powerhouse behind the Firefox web browser, which runs on a large percentage of popular operating systems.

Here is a short list of advantages to using XULRunner over just any cross-platform framework:

* XULRunner is Free Software, and its development is community-oriented.
* Unlike Java and .NET, XULRunner applications are built with native code and have a native look-and-feel ("native" is in reference to the host operating system).
* Also unlike Java and .NET, XULRunner applications are written in C++, a highly portable and widely used programming language.
* XULRunner provides many features that Firefox users are already familiar with: scripting with Javascript, application extensibility through "extensions", networking and popular web protocols support, HTML processing (and a LOT more) with the Gecko rendering engine.
* User interfaces in XULRunner are written in XUL (an XML dialect), styled with CSS, and setup to "do things" with Javascript -- all current web standards. The use of CSS allows the user interface to be "skinned" to a user's personal tastes.
* UI functionality is mostly implemented with Javascript, but backbone and critical code can be written in C++ and accessed from the Javascript environment.

For a very informative read on the Mozilla platform, I recommend the online book [http://books.mozdev.org/chapters/index.html Creating Applications with Mozilla].

====Internationalized and localized====

Because community strengths are so important to a project of this size and magnitude, the global community becomes an invaluable asset. And as a diverse global community, not everyone will speak or understand a single common language. In this case, I am directly referring to the English language, which is personally my primary language, and the only language I am entirely fluent. Programmers and hackers in a similar situation, though with a different primary language, will benefit from a universal debugger. We should not neglect any user in the community. Making the universal debugger accessible and usable for everybody must be a top priority of the project.

Choosing the Mozilla platform as the application's foundation will play a crucial role in the internationalization of the product. Because the user interface elements are written in an XML dialect, all text can be referenced with DTD entities, just like you might write &gt; in XHTML to print the greater-than sign (>). Likewise, you might write

:<pre><nowiki><caption label="&hello;"></nowiki></pre>

in XUL which would display a label with "Hello" or "こんにちは" depending on the locale set on the user's machine when the XUL application is started.

DTD entities are not magic translators; the text must be translated by a human who is fluent in both (source and destination) languages. However, using DTD entities is a great way to write user interfaces (and other things, like configuration files, for example) without locking the program to a specific language. It also makes the translator's work much easier, since all text strings which require translation will be neatly stored in a single location.

Having the capability to bring a universal debugger to anyone, no matter their ethnic background, will help to expand the debugger's user base and ultimately its supporting community of developers. Designed from the beginning with breaking language barriers in mind, there should be few stumbling points along the road to the success of reaching this goal.

====Standards compliant====

Standards make the technological world work. And standards compliance makes compatibility issues entirely negligible. This is perhaps the most important point I will make within this documentation: defining a series of open standards to encompass ''all'' foreseeable debugging functionality is a necessity.

The major reason for adopting a standard or series of standards is for compatibility purposes. Compatibility is critical for modular designs. And modularity is an important part of the overall user-configuration and extensibility of an application or sets of applications. Modularity also has the benefit of splitting workloads, as we did previously with GCNrd. Splitting workloads decreases development times, improves communication, and in some cases even improves product quality.

In simpler terms, starting with splitting developer workloads, we all know that it's easier to cover more ground by splitting up. So long as you have a central location to meet up later, this tactic works wonderfully for rapid application development. In the case of developing a debugger, you might typically have one team focusing on the low-level handling of the CPU and hardware, another team tackling the user interface to the low-level debugger, and perhaps a third team covering the protocol between the two.

I realize that the "third team" in this example is most likely set aside as another task for the first team in the real world. But if your project does require some sort of communication layer and you pull that out of the first team's hands, you can effectively pass that responsibility to a sort of "standards body" who will oversee the development and ''standardization'' of that communication layer. The job of such a body would be to ensure the standard is usable by anyone and for any purpose, generic enough to support all current and foreseeable architectures, and extensible enough to support all unforeseeable future architectures.

The extensibility of the standard would be the most difficult to maintain. While a protocol or communication layer of this sort should be extensible for the reasons listed, it should only be extensible to the extent that any new features added would not break previous features or introduce new compatibility issues with previous designs and implementations of the protocol or communication layer. This means, generally, that the extensibility must remain open and ''optional''; no extended feature should ever be mandatory for any user to implement.

There will undoubtedly be important new technologies which require mandatory extensions to the protocol during the life cycle and evolution of debugging technology. Under these circumstances, the standards body would be responsible for designing and publishing a new major version of the protocol with the new mandatory technologies. Implementers of the protocol, should they choose to support newer major versions, would then be required to implement all mandatory features in order to claim standards compliance of their implementation.

What we need is a standards body; a group of individuals, mostly volunteers or "elected" members, to define and publish a series of standards for debugging modern computer architectures. They will be responsible for taking everyone's concerns from the community into account, and act on those concerns within their design and definition. They will be responsible for knowing that if they fail to do a good job, the community will stop listening to them and they will easily be replaced by anyone who steps up with a better idea.

The goals of the standards body will be defining:

* The ''wire''; how we get data from point A (low-level debugger) to point B (user interface). Ethernet? RS232? ...
* The ''language''; how our data is interpreted as points A and B speak. XML? JSON? Pure binary packets? ...
* The ''expansion''; how we can introduce new features without creating vendor locks or introducing incompatibilities. Header/Info/About/Options commands which specify the optional/extended features we support? ...

The goals for us developers will be inheriting some of these responsibilities as we implement these standards, to create a flourishing environment for debugger developers to contribute with innovation and healthy competition.

====Configurable, extensible, and modular====

Debuggers are all about user experience. I say this with honest integrity because debugging, by its very nature, is a difficult task. Making a debugger very simple to use is a bullet point; you don't want to overwhelm a user (who is already working on a very difficult problem) with bad user experience. To improve the user experience, it is important to allow a level of customization among the user interface. Also important is extensibility and modularity, to make it easy for the user to expand the interface to fit her needs, and easy to replace one component with another that she prefers.

Some of the items of the user interface which should be configurable include the overall look-and-feel of the interface (skin), the organization of windows and widgets (tabs, information panes, etc.), and the styles of text, fonts, and [image-]backgrounds used throughout.

The look of the application, as well as the functionality, should be extensible using styling and scripting languages. The Mozilla platform once again becomes an asset as it allows simple integration of CSS and Javascript for the purposes of extending applications based on the platform. Extensions can be written and managed by the user community, much the same way that Firefox extensions are written and distributed. A central management location for extensions would be a great thing to have, but is not necessary to the success of a thriving extension-based sub-community.

Including certain feature sets in the application's base install as pre-installed extensions means that users may uninstall those extensions at will to remove undesired features, or replace those extensions with other extensions that implement comparable (and often better) features. This modular design will help to increase the user experience as well as the user's personal productivity with the application. This, too, can be supported by a thriving extension-based sub-community, and the community at large.

====Advanced debugging technologies====

[Work in progress]

====Encouraging community activity====

[Work in progress]

==See also==

* [[Debugging Modern Computer Architectures]]

Universal Debugger Project

2008-10-12T22:37:45Z

Gayswee: /* GCNrd GUI */

This is a reference and general documentation for a project I ([[:User:Parasyte|Parasyte]]) have been interested in pursuing for several years. This article will discuss the project's history, current developments, and future.

==Project history==

I began my research into debuggers sometime in 1999. Things were different back then; computers were just barely able to emulate SNES, even with emulators of the time taking numerous shortcuts to help speed up emulation. At the time, I only know of one SNES emulator pre-compiled with any kind of debugging functionality, and that was a build of SNES9x (then a chromeless application which was horribly difficult to use) by LordTech. It allowed the user to enable and disable assembly tracing while the game ran. This was a good start; you could see what the game was doing, and gain a lot of information from it. But it was still clunky.

To find the assembly which read or wrote to a specific address, you had to search through (often many megabytes) of text for those addresses. It gave you a good piece of the puzzle, but it did not give you the whole picture. Often many instructions were branched over, and were entirely missing from the log.

A few years later, I had some C programming experience of my own under my belt, and I had also found a new NES emulator called NESten. It wasn't a great NES emulator, but it was decent; it ran most of the NES games I was interested in, and it also had a fairly nice debugger built in! It was during this time that I got my first real taste of debugging. (Previously I experimented with UltraHLE's debugging features, but I don't recall them being much use; it used another "look but don't touch" passive take on debugging.)

NESten's debugger (and the emulator itself) did have some annoying flaws. And after getting sick of it, I decided (like many pioneering hackers before me) to take a decent open source emulator and extend it with some decent debugging capabilities. I chose FCEU (FamiCom Emulator Ultra) by Xodnizel as my base. (Note: FCEU was previously based on FCE, by Bero.) FCEU was a good candidate because it had decent emulation capabilities, and also because it was quite fast; you really need a fast base if you're just going to slow it down with powerful features. And I'll get to that point later.

===FCEUd===

And with that, FCEUd (FCEU-debug) was born. It did not take long to get a stable debugger integrated into the CPU core and hooked up with a little chrome. Seems like it was only 3 or 4 months before it was usable, and a total of 6 months or so development time before I was happy with it. This debugger took all of the major ideas from NESten (including its disassembler syntax for displaying current work addresses) and added some crucial elements that NESten lacked (write breakpoints triggered by INC/DEC instructions, which increment and decrement bytes in memory). I also used ideas from PSX debuggers, such as "step out" which mutually comples the "step in" and "step over" process. And I'll get to that point, again, later.

Since then, FCEUd has been further extended by other members of the emulation/ROM hacking scenes. To this day, FCE has been the most widely forked emulator, in part, because of the work we did extending it from an NES player to an NES development tool. But as you will see, this will bring me to another point later: The work done on FCE-derived forks is very widespread without much communication between parties. Ultimately, it's a mish-mash mix of talent tackling the same ideas from different vantage points without direct collaboration. And I think it's a shame.

===GCNrd===

The main development cycle on FCEUd was during 2002. I learned quite a bit from this project, and it got me interested in debugging other architectures. The next architecture I took on was Nintendo GameCube, officially abbreviated "GCN".

Sometime in 2003, hackers discovered a flaw in the GCN game Phantasy Star Online, which was compatible with the GCN BroadBand Adapter (BBA). This quickly became known as the PSO exploit, and allowed running "homebrew" code on a consumer GCN.

The PSO exploit worked something like this: Hacker Joe sets up his own DNS server, and tells PSO to use that server IP address as its default gateway. This way, PSO asks Hacker Joe's DNS server where it can find Sega's PSO server. Hacker Joe's DNS server tells PSO that Sega's server is located on Hacker Joe's PSO server. PSO happily connects to Hacker Joe's PSO server, which then tells PSO that there is an update available. PSO happily downloads the "PSO loader stub" which is posing as an official update to PSO. PSO happily launches the PSO loader stub which takes over the GCN and begins downloading a larger executable (of Hacker Joe's choice) from Hacker Joe's PSO server. The PSO loader stub then launches Hacker Joe's executable, and Hacker Joe now has total control over his GCN. In short, PSO is tricked by Hacker Joe into running code that it never should have in the first place.

This was a huge breakthrough for GCN hacking. I was in a very poorly state at the time, with no real job and no real income. I was doing work for a certain company selling GBA flash carts. It got me by, but it was a far cry from decent living. I mention this because it means I couldn't afford PSO or a BBA; the two things I needed to begin work on GCN debugging. I had the skill to accomplish it certainly, so I took up donations from members in the community. Only a few responded, but that's all I needed. About $100 USD was enough to pick up the two items I needed, and I was on my way to fame...

====History of GCNrd====

<pre>06-22-03: First GCN AR codes decrypted.
06-23-03: GCNcrypt v1.0 released.
06-25-03: First unofficial GCN AR codes released: Sonic Adventure DX (U) codes,
by Sappharad.
06-27-03: GCNcrypt v1.1 released.
07-03-03: Planning for GCNrd begins.
07-07-03: GCNrd development begins.
08-27-03: Development on GCN network library begins.
08-29-03: First data received from GCN over network, using homebrew network
library.
09-01-03: First data received by GCN over network, using homebrew network
library.
09-13-03: Harddrive crash causes problems. Interest in GCNrd is lost.
12-31-03: After 3 months without working on GCNrd, aside from the occasional
bugfix in the libs, GCNrd development finally continues.
12-31-03: Milestone #1. First successful RAM dump grabbed from a GCN game using
GCNrd. It takes 35.735 seconds to complete.
12-31-03: BBA is started in 100mbit full duplex mode. Full RAM dump completes
in 14.687 seconds.
01-03-04: Work on screenshot support begins. First successful screenshots are
taken from Rayman 3 and Rogue Leader.
01-12-04: Mario Kart: Double Dash!! (U) is supported by GCNrd. This was the
first successful "BBA Reset" patch for a LAN\network-enabled game.
01-15-04: Milestone #2. GCNrd rightly claims better compatability than Datel's
FreeLoader v1.06b.
01-17-04: All tested games boot! 64 of 64.
01-19-04: Kenobi begins work on a GUI for GCNrd, making the program a bit
easier to use, and adding code search features.
01-23-04: Milestone #3. First GCN AR code created using only GCNrd and Kenobi's
GCNrd GUI. Wave Race: Blue Storm (U), 99 Points, by Knux0rz.
01-25-04: Started adding breakpoint support. Breaks work for Read, Write, and
Read+Write. Execution breakpoints will be next. BPR\W gave me a bit
of trouble. The biggest problem I had was getting around the 8-byte
boundary which PowerPC uses for data breakpoints. This was completely
unacceptable. As an example, if you set a breakpoint on address
805E4FF5, a break would be reported every time an address between
805E4FF0 - 805E4FF8 was accessed. Even though only one address within
that range had a breakpoint set. My current solution to this problem
is pretty nasty, but it works. In fact, it only reports a hit if the
break addresses match perfectly. Maybe a little inconvenient, but
hey!
03-11-04: GCN CodeType Helper v1.0 released.
03-11-04: GCNcrypt v1.2 released.
03-16-04: Finished up breakpoint support today, which should now be 100% fixed.
The debugger now waits until just before returning to the game
before enabling any r\w breakpoint. This will help bypass any
misleading break hits that are caused by the debugger itself. Such as
when accessing the stack and etc.
New plan in the works to work-around memory constraints. May not work
on all games, but should solve all problems with PacMan World 2.
Which currently suffers from a nasty crash when accessing the memory
card. The crash appears to be caused by how much memory I have
allocated for the debugger.
03-17-04: Work begins on patching AR's code engine. With the patch in place,
the code engine will run GCNrd's memory-resident debugger, allowing
users to hack games with multiple executables, such as demo discs and
the James Bond 007 games.
03-18-04: Kenobi adds real-time AR code list handling to the GUI. Supported AR
versions are v1.06 and v1.08. Support for additional versions will be
made available as soon as we receive AR RAM dumps from the other
versions.
03-19-04: Win9x compatibility issues are worked on. GCNrd console now accepts
commands passed on the command line. With commands entered on the
command line, the console program will exit immediately after
completing the requested command. Support for Win9x compatibility in
the GUI is limited, but progressing rapidly.
03-20-04: Support for AR v1.11 completed.
03-31-04: First public release! GCNrd v1.00b is made available to hackers
everywhere.</pre>

====GCNrd GUI====

The GUI for GCNrd was written entirely separately from my own GCNrd development. It was called simply GCNrdGUI and was written by a French hacker, Kenobi, in Delphi. This split up the workload considerably, and also added a new level of modularity to the project overall. The overall GCNrd project consisted of four components:

* GCNrd Loader: The UI that the user is presented with on the GCN itself. The loader is responsible for GCN-side configuration, initializing the network hardware, launching DVDs, and setting up the debugger/hooking the executable.
* GCNrd debugger: This is a piece that the user never sees, but directly interacts with. It's a very small program (32KB total program code and memory usage) that runs "behind" the game, listening for instructions coming over the network, and acting upon them.
* GCNrd client: A command-line application run on the user's PC which can be used to send and receive commands and data to/from the debugger over the network.
* GCNrdGUI: Kenobi's GUI for interacting with the GCNrd client.

It was not necessary for the GUI to interact with the debugger through my CLI client, but that was the option chosen for GCNrdGUI. Later on another hacker, Sappharad, wrote his own GUI in Java which communicated with the debugger directly, bypassing the need for GCNrd client; the modularity of the project comes full circle.

====GCNrd v1.10b and beyond====

GCNrd v1.10b was released July 28th, 2005. It contained a number of bug fixes and new features. Some new features were only shiney on the surface (background images and UI colors in the loader, date/time display...), but some were actually quite important. The MMU handling, for example, allowed hacking games like Star Wars: Rogue Leader, Star Wars: Rebel Strike, and Metal Gear Solid: The Twin Snakes, which used the MMU extensively. It was a slightly rushed released, even though it did show some promise.

This was the last official release I made, along with a private release (only available to close friends) which included some special features like DVD dumping and loading/debugging DVD images over the BBA. This "DVD simulation" was quite advanced for its time, and allowed me (and a few others) to hack downloaded/dumped games. There are often times that the only way to get a copy of a game is downloading it. Either because it was never officially released in your region, or because it hasn't been officially released ''at all''. This private "v1.10b+" version was never made public due to piracy concerns.

Those piracy concerns were actually forfeited after other hackers disabled the DVD booting code in v1.10b to allow debugging DVD-Rs booted with a "Cobra-like" DVD BIOS.

I had plans at one time to rewrite GCNrd so that it could be relocatable within GCN memory. This would solve problems with memory allocation on games that don't play nice. Resident Evil 4 is a good example of such games; it cannot be booted at all by any version of GCNrd. The rewrite would also make the source code legible enough that I could release it under the [http://www.gnu.org/copyleft/gpl.html GPL]. Granted, legibility is not necessary for source code release, but it was important for reasons of maintainability.

GCNrd source code used a wild mix of C and assembly in its main debug core. Escaping the low levels of assembly was impossible, but it could be structured nicely anyway. This wasn't the only problem, of course. Both the loader and debugger had to have their own separate build of the network library. It was too costly (memory-wise) to put the full library into the debugger, even though this would allow the loader to use the debugger for all of its networking tasks.

Instead, the debugger had a very minimal network library; I cut out all of the initialization sequences, all of the CRC code for packet data integrity checking, and whole lot of other not-completely-necessary packet handling code. It was important to keep the debugger as small as possible so it would not interfere with the game's use of memory.

That gave me two entirely different network stacks to maintain; one was already quite a bit of work, as it was. There was also the problem of compiling the debugger separately from the loader, and then compiling the debugger binary directly into the loader itself.

There are a number of ways these issues could have been addressed, and I'm not going to cover them all. But I will get back to the early point about modularity. As you will see, I am hoping to solve a great deal of these problems using that frame of mind. Needless to say, I never did complete the rewrite of GCNrd, which would have become "GCNrd v2". But the problems displayed by it were the cornerstones of what was to become the Universal Debugger Project.

===PCS and Mupen 64===

The next year, in 2006, I went back to hacking N64. This was a time when some very interesting N64 hacks were made [http://doc.kodewerx.net/hacking_n64.html#asm_jesus_mode]. By this time, we were all very familiar with Nemu and its debugging/cheating capabilities. The debugger was not bad, but its emulation left quite a bit to be desired. Once again, unhappy with the tools available, I set out to tackle the problem and create my own tools.

The first was [http://doc.kodewerx.net/hacking_n64.html#emulator_pcs Parasytic Cheat Search], a ''video'' plugin for PJ64 (and other emulators compatible with its plugin spec) that allowed cheat searching through the emulator's memory. It contained many bugs and architectural flaws (being a video plugin which passed all video-related messages to a ''real'' video plugin) but it provided a start for me to get into N64 emulator development.

My next N64 project was tackling the debugger problem. Unlike a simple passive cheat searching program, a debugger has to be hooked directly to the CPU to work consistently. Like the FCEUd project years earlier, I wanted to start with a decent open source emulator and extend its capabilities to include decent debugging features.

I chose Mupen 64 as my base, this time. It had relatively high compatibility, stability, and speed. It also contained a debugger for its GTK+ build, which I knew I could use to my advantage. I was still a Win32 programmer at the time; I did not have much experience outside of Windows. Naturally, I focused on Mupen's Windows code, which is where my debugger would live.

After patching Mupen's CPU core (all three of them!) I started implementing the debugger window and all of its fancy widgets. This is when a very bad case of Deja Vu hit me. I had done all of this work before; I was reinventing the wheel. Not good. So I left Mupen 64 with a bare-bones cheat feature (including search) and debugger. This is when I began formulating the idea that debugger interfaces should be modular, just like GCNrd. Then came an avalanche of questions and issues. More on that later.

===NTRrd and Kwurdi===

In 2007, we had Nintendo DS (officially abbreviated NTR, unofficial NDS), and we had a means to hack it thanks to the efforts of the PassMe crew. I did not jump into DS dev quite as enthusiastically as I had GCN, but I eventually got into it and started playing around with ideas to debug the little machine. There were several problems, initially: The first was a communications port. I chose to use the GBA X-port, which was a rather expensive device (especially for video game hackers, who are typically in their teens, and without jobs), but it was attractive to me because of its FPGA.

The X-port comes by default with a simple LPT serial port that can be used as a communications link. But it is generally slow and unreliable for large data transfers. On the other hand, the FPGA (and a LOT of IO) can be leveraged to implement a much faster and more stable communications link. And that's exactly what I did, writing custom FPGA logic for a simple 8-bit ECP-mode LPT port. The result was a much faster (~4MB/s ... still much slower than ethernet, WiFi, or USB would have been) and much more reliable (~0.0001% error rate) communications link that I could use to dump NDS memory to perform cheat searching.

The initial result of this work was "NTRrd" which never saw any kind of release. That's when the ideas from past projects began to meld into an idea well ahead of its time. The idea of a universal debugger. Or at least, a universal debugger interface. So I came up with a silly acronym: KWURDI, for KodeWerx Universal Remote Debugger Interface. And I wanted NTRrd to be its first "client".

The idea was that NTRrd would be a three-piece project: NTRrd loader, NTRrd debugger, NTRrd client. And Kwurdi would be its GUI. The loader would load the debugger, the debugger would talk to the client, and the client would talk to the GUI. That's a lot of levels of abstraction. As it turns out, though, all of those levels are quite important. In fact, it's this level of abstraction and modularity which make this idea of a universal debugger important.

==The universal debugger==

The original article for the Universal Debugger Project can be found in the [[Debugging Modern Computer Architectures]] article. While it covers a good general scope of the idea itself, it does not lay down any foundation other than a very generic description of the roles that each piece of the project ''might'' play. To highlight the main points of the project:

* The universal debugger interface itself is a user interface to allow interaction with a low-level debugger.
* The low-level debugger may or may not live on the same machine as the universal debugger interface. The universal debugger interface communicates with the low-level debugger through a standard communications link and protocol.
* The communications link should be an existing standard. For example, UNIX domain sockets or DBUS for a local low-level debugger, and TCP/IP for a remote low-level debugger.
* The protocol should also be an existing standard, but to this date, there does not appear to be anything which fits the goals of a universal debugger interface. One possibility is [http://www.rfc-archive.org/getrfc.php?rfc=909 RFC-909, Loader Debugger Protocol].

===Project goals===

The long term goals of the Universal Debugger Project include:

* Modularity
* Standardization

These items are to be taken as mutually inclusive. For modularity to work, there must be a set of standards in place. For a set of standards to be successful, the modularity granted by the standards must be exploited.

For our purposes, I wish to implement a set of standards for a "universal debugger" with the help of the community, and implement a debugger interface on top of those standards as an example of modularity. The implementation has the following goals:

# It will be Free Software, released under a free software license compatible with the [http://www.gnu.org/copyleft/gpl.html GNU General Public License].
# It will be a community-oriented project; accepting ideas, patches, code, images, and documentation, among other items, from the community which supports it.
# It will be designed as a cross-platform application, able to be used on multiple operating systems.
# It will be built with internationalization and localization in mind; capable of being adapted to different languages.
# It will communicate with and support of any low-level debugger which supports the standards defined by the Universal Debugger Project.
# It will be configurable, extensible, and modular by nature, to support any conceivable current or future architecture.
# It will support highly advanced debugging techniques and bleeding-edge technologies to get the most out of the user's debugging experience.
# It will support and encourage community activity through collaborative debugging.

I will cover these points one at a time in more detail:

====Free software====

Free Software released under the [http://www.gnu.org/copyleft/gpl.html GNU General Public License] or a compatible license is meant to be community-driven. This means, anyone who wants to participate in the development of the project is free to participate. You don't become a community member by being one of a few elite deemed "worthy"; you become a member simply by joining an active discussion or contributing in some other way.

The source code will be made available for everyone to look at or extend, which benefits from many eyes keeping the code safe and secure, and also from many hands working in parallel to quickly produce a stable product that is free for anyone to use in any way they see fit. These are two of the basic freedoms granted by a Free Software license: Freedom to look at and extent the product, and freedom to use the product in any way. There are many more freedoms granted by Free Software, and if interested you should consult the GPL documentation or other authoritative sources.

====Community-oriented, community-driven====

A community-oriented and community-driven software project benefits from its main source of use: its own users. Such projects become self-sustaining, as their users take the secondary roles of developers. I will not cover many of the details relating to community-oriented or community-driven software, but there are plenty of great resources available for further reading. Some suggested reading includes The Cathedral and the Bazaar [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain] by Eric S. Raymond, the About Mozilla pages [http://www.mozilla.org/about] [http://www.mozilla.org/about/manifesto] [http://www.mozilla.org/mission.html] [http://www.mozilla.org/editorials/mozilla-overview.html], and the online book Open Sources: Voices from the Open Source Revolution [http://oreilly.com/catalog/opensources/book/toc.html].

As a community-oriented, community-driven project, I believe there is no end to the ways in which we, as a community of programmers and hackers, will be able to debug. This community would ideally involve the active roles of everyone from video game and ROM hackers, application and operating system developers, and people in the field of academic research of computer architectures. It doesn't have to be the biggest and the best of the debugging communities (and it probably won't!) but it does have to be an accepting community, willing to allow contributions from anyone and everyone who wishes to contribute.

====Cross-platform design====

Among the design goals of the project, the universal debugger implementation must be able to run on multiple computer platforms and operating systems. This is a difficult undertaking, especially for a program focusing on a graphical user environment. Several bases for cross-platform development already exist, so dealing with intricacies of operating systems can be cut down to a minimum, while retaining a high level of overall product quality.

I have personally researched several offerings for cross-platform frameworks and libraries, and I believe the best choice is the Mozilla platform, [http://developer.mozilla.org/en/XULRunner XULRunner]. XULRunner is still in its infancy, but is already very capable; it's the powerhouse behind the Firefox web browser, which runs on a large percentage of popular operating systems.

Here is a short list of advantages to using XULRunner over just any cross-platform framework:

* XULRunner is Free Software, and its development is community-oriented.
* Unlike Java and .NET, XULRunner applications are built with native code and have a native look-and-feel ("native" is in reference to the host operating system).
* Also unlike Java and .NET, XULRunner applications are written in C++, a highly portable and widely used programming language.
* XULRunner provides many features that Firefox users are already familiar with: scripting with Javascript, application extensibility through "extensions", networking and popular web protocols support, HTML processing (and a LOT more) with the Gecko rendering engine.
* User interfaces in XULRunner are written in XUL (an XML dialect), styled with CSS, and setup to "do things" with Javascript -- all current web standards. The use of CSS allows the user interface to be "skinned" to a user's personal tastes.
* UI functionality is mostly implemented with Javascript, but backbone and critical code can be written in C++ and accessed from the Javascript environment.

For a very informative read on the Mozilla platform, I recommend the online book [http://books.mozdev.org/chapters/index.html Creating Applications with Mozilla].

====Internationalized and localized====

Because community strengths are so important to a project of this size and magnitude, the global community becomes an invaluable asset. And as a diverse global community, not everyone will speak or understand a single common language. In this case, I am directly referring to the English language, which is personally my primary language, and the only language I am entirely fluent. Programmers and hackers in a similar situation, though with a different primary language, will benefit from a universal debugger. We should not neglect any user in the community. Making the universal debugger accessible and usable for everybody must be a top priority of the project.

Choosing the Mozilla platform as the application's foundation will play a crucial role in the internationalization of the product. Because the user interface elements are written in an XML dialect, all text can be referenced with DTD entities, just like you might write &gt; in XHTML to print the greater-than sign (>). Likewise, you might write

:<pre><nowiki><caption label="&hello;"></nowiki></pre>

in XUL which would display a label with "Hello" or "こんにちは" depending on the locale set on the user's machine when the XUL application is started.

DTD entities are not magic translators; the text must be translated by a human who is fluent in both (source and destination) languages. However, using DTD entities is a great way to write user interfaces (and other things, like configuration files, for example) without locking the program to a specific language. It also makes the translator's work much easier, since all text strings which require translation will be neatly stored in a single location.

Having the capability to bring a universal debugger to anyone, no matter their ethnic background, will help to expand the debugger's user base and ultimately its supporting community of developers. Designed from the beginning with breaking language barriers in mind, there should be few stumbling points along the road to the success of reaching this goal.

====Standards compliant====

Standards make the technological world work. And standards compliance makes compatibility issues entirely negligible. This is perhaps the most important point I will make within this documentation: defining a series of open standards to encompass ''all'' foreseeable debugging functionality is a necessity.

The major reason for adopting a standard or series of standards is for compatibility purposes. Compatibility is critical for modular designs. And modularity is an important part of the overall user-configuration and extensibility of an application or sets of applications. Modularity also has the benefit of splitting workloads, as we did previously with GCNrd. Splitting workloads decreases development times, improves communication, and in some cases even improves product quality.

In simpler terms, starting with splitting developer workloads, we all know that it's easier to cover more ground by splitting up. So long as you have a central location to meet up later, this tactic works wonderfully for rapid application development. In the case of developing a debugger, you might typically have one team focusing on the low-level handling of the CPU and hardware, another team tackling the user interface to the low-level debugger, and perhaps a third team covering the protocol between the two.

I realize that the "third team" in this example is most likely set aside as another task for the first team in the real world. But if your project does require some sort of communication layer and you pull that out of the first team's hands, you can effectively pass that responsibility to a sort of "standards body" who will oversee the development and ''standardization'' of that communication layer. The job of such a body would be to ensure the standard is usable by anyone and for any purpose, generic enough to support all current and foreseeable architectures, and extensible enough to support all unforeseeable future architectures.

The extensibility of the standard would be the most difficult to maintain. While a protocol or communication layer of this sort should be extensible for the reasons listed, it should only be extensible to the extent that any new features added would not break previous features or introduce new compatibility issues with previous designs and implementations of the protocol or communication layer. This means, generally, that the extensibility must remain open and ''optional''; no extended feature should ever be mandatory for any user to implement.

There will undoubtedly be important new technologies which require mandatory extensions to the protocol during the life cycle and evolution of debugging technology. Under these circumstances, the standards body would be responsible for designing and publishing a new major version of the protocol with the new mandatory technologies. Implementers of the protocol, should they choose to support newer major versions, would then be required to implement all mandatory features in order to claim standards compliance of their implementation.

What we need is a standards body; a group of individuals, mostly volunteers or "elected" members, to define and publish a series of standards for debugging modern computer architectures. They will be responsible for taking everyone's concerns from the community into account, and act on those concerns within their design and definition. They will be responsible for knowing that if they fail to do a good job, the community will stop listening to them and they will easily be replaced by anyone who steps up with a better idea.

The goals of the standards body will be defining:

* The ''wire''; how we get data from point A (low-level debugger) to point B (user interface). Ethernet? RS232? ...
* The ''language''; how our data is interpreted as points A and B speak. XML? JSON? Pure binary packets? ...
* The ''expansion''; how we can introduce new features without creating vendor locks or introducing incompatibilities. Header/Info/About/Options commands which specify the optional/extended features we support? ...

The goals for us developers will be inheriting some of these responsibilities as we implement these standards, to create a flourishing environment for debugger developers to contribute with innovation and healthy competition.

====Configurable, extensible, and modular====

Debuggers are all about user experience. I say this with honest integrity because debugging, by its very nature, is a difficult task. Making a debugger very simple to use is a bullet point; you don't want to overwhelm a user (who is already working on a very difficult problem) with bad user experience. To improve the user experience, it is important to allow a level of customization among the user interface. Also important is extensibility and modularity, to make it easy for the user to expand the interface to fit her needs, and easy to replace one component with another that she prefers.

Some of the items of the user interface which should be configurable include the overall look-and-feel of the interface (skin), the organization of windows and widgets (tabs, information panes, etc.), and the styles of text, fonts, and [image-]backgrounds used throughout.

The look of the application, as well as the functionality, should be extensible using styling and scripting languages. The Mozilla platform once again becomes an asset as it allows simple integration of CSS and Javascript for the purposes of extending applications based on the platform. Extensions can be written and managed by the user community, much the same way that Firefox extensions are written and distributed. A central management location for extensions would be a great thing to have, but is not necessary to the success of a thriving extension-based sub-community.

Including certain feature sets in the application's base install as pre-installed extensions means that users may uninstall those extensions at will to remove undesired features, or replace those extensions with other extensions that implement comparable (and often better) features. This modular design will help to increase the user experience as well as the user's personal productivity with the application. This, too, can be supported by a thriving extension-based sub-community, and the community at large.

====Advanced debugging technologies====

[Work in progress]

====Encouraging community activity====

[Work in progress]

==See also==

* [[Debugging Modern Computer Architectures]]

Mischief Makers v1.0 (U)/GameShark

2008-10-12T16:41:53Z

Gayswee: New page: ---- <big>'''Hextator'''</big> '''Kill NPCs''' ---- 8106C2B0 1000 ---- Mischief Makers v1.0

----
<big>'''Hextator'''</big>

'''Kill NPCs'''

----

8106C2B0 1000

----

[[Category:Nintendo 64|Mischief Makers v1.0]]

Help:Templates

2008-10-08T09:20:45Z

Gayswee: /* Using a template */ Added a missing "of"

{{PD Help Page}}
If you have standard texts you want to include on several pages, the MediaWiki template feature comes into play.

==Creating a template==
Templates are standard wiki pages, only the template names are prefixed with "<code>Template:</code>". Therefore you can [[Help:Starting a new page|create them like any other wiki page]].

==Using a template==
Templates are wiki pages which can be used in other pages in three ways:
*<code><nowiki>{{Name}}</nowiki></code> 'transcludes' (i.e. includes a copy of) the content of the template (stored in the page <nowiki>[[Template:Name]]</nowiki>) whenever the page containing the template transclusion is fetched and displayed; i.e. if the template is later changed, the displayed transcluding page will automatically change too
*<code><nowiki>{{subst:Name}}</nowiki></code> replaces that string with the contents of the template, in the source of the transcluding page, when you save that page; the copy of the template contents can then be edited normally (and separately from the original in the template page). '''''Note''''': don't use this if you are looking to continually propagate changes from the source template to the page(s) that references it.
*<code><nowiki>{{msgnw:Name}}</nowiki></code> includes the template in a form that displays it as raw wiki syntax (the way <code><nowiki><nowiki></nowiki></code> does) when the page containing it is fetched

==Using parameters in templates==
<div style="float:right; margin:8px;">
{| {{Prettytable}}
|-
|{{Hl2}} colspan="2" align="center" |'''Template with numbered parameters'''
|-
| colspan="2" |
<pre><nowiki>
'''A little thank you...'''<br>
<small>for {{{1}}}.<br>
hugs, {{{2}}}</small>
</nowiki></pre>
|-
|{{Hl2}}|'''You type'''
|{{Hl2}}|'''You get'''
|-
|<code><nowiki>{{Thankyou|all your hard work|Joe}}</nowiki></code>
|
{{Thankyou|all your hard work|Joe}}
|-
|{{Hl2}} colspan="2" align="center" |'''with named parameters'''
|-
| colspan="2" |
<pre><nowiki>
'''A little thank you...'''<br>
<small>for {{{reason}}}.<br>
hugs, {{{signature}}}</small>
</nowiki></pre>
|-
|{{Hl2}}|'''You type'''
|{{Hl2}}|'''You get'''
|-
|<pre><nowiki>{{Thankyou
|reason=all your hard work
|signature=Joe}}</nowiki></pre>
|
{{Thankyou|all your hard work|Joe}}
|}
</div>
You can define parameters in templates either numbered as <code><nowiki>{{{1}}}</nowiki></code> or named <code><nowiki>{{{param}}}</nowiki></code>.

'''Example:''' You want a little thank you note you can put on the talk page of other users. It will contain a reason and your signature. You could create [[Template:Thankyou]] to enter your text, as in the example in the table.

When using the template on a page, you fill in the parameter values, separated by a pipe char (|): <code><nowiki>{{Thankyou|all your hard work|Joe}}</nowiki></code>. For named parameters use "name=value" pairs separated by a pipe char: <code><nowiki>{{Thankyou|reason=all your hard work|signature=Joe}}</nowiki></code>. The advantage of using named parameters in your template is that they are flexible in order. It also makes the template easier to understand if you have many parameters. If you want to change the order of numbered parameters, you have to mention them explicitly: <code><nowiki>{{Thankyou|2=Joe|1=all your hard work}}</nowiki></code>.

You can also provide default values for parameters, i.e. values that are going to be used if no value is provided for a parameter. For example, <code><nowiki>{{{reason|all your hard work}}}</nowiki></code> would result in ''"all your hard work"'' if no value was provided for the parameter <tt>reason</tt>.

==Control template inclusion==
You can control template inclusion by the use of <code><nowiki><noinclude></nowiki></code> and
<code><nowiki><includeonly></nowiki></code> tags.

Anything between <code><nowiki><noinclude></nowiki></code> and <code><nowiki></noinclude></nowiki></code> will be processed and
displayed only when the page is being viewed directly, not included.

Possible applications are:
* Categorising templates
* Interlanguage links to similar templates in other languages
* Explanatory text about how to use the template

The converse is <code><nowiki><includeonly></nowiki></code>. Text between <code><nowiki><includeonly></nowiki></code> and
<code><nowiki></includeonly></nowiki></code> will be processed and displayed only when the page is
being included. The obvious application is to add all pages containing a given template to a [[Help:Categories|category]], without putting the template itself into that category.

'''Note:''' when you change the categories applied by a template, the categorization of the pages that use that template may not be updated until some time later: this is handled by the {{mediawiki|Manual:Job_queue|job queue}}.

==Organizing templates==
For templates to be effective users need to find them and be able to use them. A simple technique is to include an example on the template page.
For example:
<div style="display:table; width:auto;"><pre>
<noinclude>
==Usage==
Allows to establish a link to a subject:
{{NameOfTemplate|Term1+Term2+Term3}}
</noinclude>
</pre></div>

Then, an editor can simply copy and paste the example to create a similar page.

==See Also==
*[[Help:External searches]] -- a template special use case example
*[[Help:Magic words]] -- fancy stuff you may find in some templates
*{{mediawiki|meta:Help:Embed page}} -- embedding pages from {{mediawiki|namespace|namespaces}} other than <code>Template:</code>.

[[Category:Help|{{PAGENAME}}]]
[[Category:Template]]
{{Languages|Help:Templates}}

Help:Images

2008-10-07T00:50:26Z

Gayswee: /* Syntax */ click=>link

{{PD Help Page}}

This page explains the image syntax when editing the wiki. Before using images, your wiki must have file uploads enabled (see the {{mediawiki|Manual:Configuring_file_uploads|technical manual}} for details) and you have to [[Help:Managing files|upload a file]].

__TOC__
{| {{Prettytable}}
|-
|{{Hl3}}|'''Description'''
|{{Hl3}}|'''You type'''
|{{Hl3}}|'''You get'''
|-
|Embed image<br /> (with alt text)
|
<code><nowiki>[[Image:Example.jpg|Sunflowers]]</nowiki></code>
|
[[Image:Example.jpg|Sunflowers]]
|-
|Link to description page
|
<code><nowiki>[[:Image:Example.jpg]]</nowiki></code><br />
<code><nowiki>[[:Image:Example.jpg|Sunflowers]]</nowiki></code>
|
[[:Image:Example.jpg]]<br />
[[:Image:Example.jpg|Sunflowers]]
|-
|Link directly to file
|
<code><nowiki>[[Media:Example.jpg]]</nowiki></code><br />
<code><nowiki>[[Media:Example.jpg|Sunflowers]]</nowiki></code>
|
[[Media:Example.jpg]]<br />
[[Media:Example.jpg|Sunflowers]]
|-
|Thumbnail<br /> (centered, 100 pixels<br /> wide, with caption)
|
<code><nowiki>[[Image:Example.jpg|center|thumb|100px|Sunflowers]]</nowiki></code>
|
[[Image:Example.jpg|center|thumb|100px|Sunflowers]]
|-
|Border<br /> (100 pixels) <br /> Results in a very small gray border

|
<code><nowiki>[[Image:Example-white-bg.jpg|border|100px]]</nowiki></code>
|
[[Image:Example-white-bg.jpg|border|100px]]
|-
|Frameless<br />Like thumbnail, respect user preferences for image width but without border and no right float.
|
<code><nowiki>[[Image:Example.jpg|frameless]]</nowiki></code>
|
[[Image:Example.jpg|frameless]]
|}

== Syntax ==
The full syntax for displaying an image is:
<code><nowiki>[[Image:{name}|{options}]]</nowiki></code>
Where options can be zero or more of the following, separated by pipes:
*<code>thumb</code>, <code>thumbnail</code>, or <code>frame</code>: Controls how the image is formatted
*<code>left</code>, <code>right</code>, <code>center</code>, <code>none</code>: Controls the alignment of the image on the page
*<code>baseline</code>, <code>sub</code>, <code>super</code>, <code>top</code>, <code>text-top</code>, <code>middle</code>, <code>bottom</code>, <code>text-bottom</code>: Controls the vertical alignment of the image on the page
*<code>{width}px</code>: Resizes the image to the given width in pixels
*<code>{caption text}</code>: Must not end with "px"
* Special cases:
** <code>page=1</code>: Displays the specified page when showing a djvu file
*<code>link={destination}</code>: Allows to link to an arbitrary title, URL or just nowhere

The options can be given in any order. If a given option does not match any of the other possibilities, it is assumed to be the caption text. Caption text can contain wiki links or other formatting.

== Other files ==
You can link to an external file using the same syntax used for linking to an external web page.
*<code><nowiki>[http://url.for/some/image.png]</nowiki></code>
Or with different text:
*<code><nowiki>[http://url.for/some/image.png link text here]</nowiki></code>

If it is enabled on your wiki (see {{mediawiki|Manual:$wgAllowExternalImages}}), you can also embed external images. To do that, simply insert the image's url:
*<code><nowiki>http://url.for/some/image.png</nowiki></code>

== Gallery of images ==
It's easy to make a gallery of thumbnails with the <code><nowiki><gallery></nowiki></code> tag. The syntax is:
<pre>
<gallery>
Image:{filename}|{caption}
Image:{filename}|{caption}
{...}
</gallery>
</pre>
Captions are optional, and may contain wiki links or other formatting.

for example:
<pre>
<gallery>
Image:Example.jpg|Item 1
Image:Example.jpg|a link to [[Help:Contents]]
Image:Example.jpg
Image:Example.jpg
Image:Example.jpg|''italic caption''
Image:Example.jpg|on page "{{PAGENAME}}"
</gallery>
</pre>
is formatted as:
<gallery>
Image:Example.jpg|Item 1
Image:Example.jpg|a link to [[Help:Contents]]
Image:Example.jpg
Image:Example.jpg
Image:Example.jpg|''italic caption''
Image:Example.jpg|on page "{{PAGENAME}}"
</gallery>

== See also ==
* [[Help:Linked images|Linked images]]

==External Link==
* [[wikipedia:Project:Extended image syntax|Wikipedia:Extended image syntax]]

{{Languages|Help:Images}}

[[Category:Help|Images]]

Help:Linked images

2008-10-06T19:12:32Z

Gayswee: Native image link support coming?

{{PD Help Page}}

[[Help:Images|Images]] on a MediaWiki wiki are designed to link to the description page, so that licensing information, upload history, contributors, and full resolution versions are immediately available to the user when he or she clicks an image. In fact, MediaWiki is designed to prevent manual manipulation of images in wikicode which may circumvent this operation: The '''<tt><img></tt>''' tag is specifically not whitelisted in the {{mediawiki|Manual:Sanitizer.php|Sanitizer}}, nor is the '''<tt>background-image</tt>''' CSS attribute.

However, there are several workarounds for those that require them.

==1.14+==
{{future}}
Native image link support was added in [[rev:41727|r41727]]. See [[bugzilla:539|b539]].

==Vanilla install==
If you only have sysop access to the Wiki, these are your best options.

===Site CSS===
The most simplistic method, if your requirements for external images are specialized (that is, restricted to one page or one image), is to add a CSS rule to your MediaWiki:Common.css (or other CSS files, such as MediaWiki:Skinname.css or /skins/skinname/main.css, etc) giving child links of a certain class of object a background image. This method also has some security, as it requires editing the site-wide CSS files, meaning only sysops have access to modify the image shown.

For example (red sections are parts to configure for each image):

In MediaWiki:Common.css:
'''<tt>.imagelink_<span style="color:red;">somename</span> a {
width:<span style="color:red;">100</span>px;
height:<span style="color:red;">100</span>px;
display:block;
text-decoration:none;
background-image: url("<span style="color:red;"><nowiki>http://fullurltoimage</nowiki></span>")
}</tt>'''
In your wikicode:
'''<tt><div class="imagelink_<span style="color:red;">somename</span>"><nowiki>[[</nowiki><span style="color:red;">Some link</span>|&nbsp;<nowiki>]]</nowiki></div></tt>'''

This would give the link the background image specified, as well as the width and height of the image (which you have to set manually). To find the location of an uploaded file, go to the image description page and click the image itself, and copy the image location in the address bar.

For example on [[:Image:Wiki.png]], the image location is http://upload.wikimedia.org/wikipedia/mediawiki/b/bc/Wiki.png (location format will differ depending on local settings), and the width and height would be set to 135px and 135px. So to make a link to the main page here using that logo, one would add to [[MediaWiki:Common.css]]:
<pre>.imagelink_wikilogo a {
width:135px;
height:135px;
display:block;
text-decoration:none;
background-image: url("http://upload.wikimedia.org/wikipedia/mediawiki/b/bc/Wiki.png")
}</pre>
And then use the wikicode:
<pre><div class="imagelink_wikilogo">[[MediaWiki|&nbsp;]]</div></pre>

Which would give you:
<div class="imagelink_wikilogo">[[MediaWiki| ]]</div>

You can also use a thumbnail of an image, but make sure the thumbnail is being used elsewhere, as most installations are not configured to generate thumbnails on demand.

===Inline CSS===
You can also attempt to superimpose an invisible link over an image via CSS, such as is done in [[Template:Click]]. An example of a typical click template is:
<pre><div style="position: relative; width: {{{width}}}; height: {{{height}}}; overflow: hidden;">
<div style="position: absolute; top: 0px; left: 0px; font-size: 100px; overflow: hidden; line-height: 100px; z-index: 3;">[[{{{link}}}|&nbsp;&nbsp;&nbsp;]]</div>
<div style="position: absolute; top: 0px; left: 0px; z-index: 2;">[[Image:{{{image}}}|{{{width}}}|{{{link}}}]]</div>
</div></pre>

Known problems: It doesn't work in text-only browsers, and in screen readers for the disabled, and possibly other situations. The technique of using [[wikipedia:CSS|CSS]] to change page content also completely breaks an article's [[wikipedia:web accessibility|web accessibility]] by contravening a [[wikipedia:WAI|WAI]] priority-one checkpoint.[http://www.w3.org/TR/WAI-WEBCONTENT/#tech-order-style-sheets]

===Redirect===
A less elegant trick is to make the image description page a redirect to the target. So for example [[:Image:Wiki.png]] would be changed to content:
<pre>#REDIRECT [[MediaWiki]]</pre>
There are several disadvantages to this:
* It doesn't always work, some installations/versions have internamespace redirects disabled.
* The image appears at the top of the article. This is because MediaWiki redirects aren't really redirects, they simply bring the target page's data to the current URL, but on image description pages this is done after the image itself is shown.
* It can only be done once per image.

==Native with configuration change==
If you have server access, but do not want to install any extensions, these solutions may work for you.
===External image syntax===
If you enable {{mediawiki|Manual:$wgAllowExternalImages|$wgAllowExternalImages}} (which allows external images from any domain) or {{mediawiki|Manual:$wgAllowExternalImagesFrom|$wgAllowExternalImagesFrom}} (which restricts the list of domains), anyone can then easily create an "external" link to an "external" image. External simply means: using the full URL rather than a local link, so you can link locally, but you need to use the full URL. The plainlinks class is used to remove the "external link" icon:

<span class="plainlinks"><span style="color:red;"><nowiki>[http://linktopage http://linktoimage]</nowiki></span></span>

So for example, were external images allowed here, you could link to the {{mediawiki|MediaWiki|main page}} with http://upload.wikimedia.org/wikipedia/mediawiki/b/bc/Wiki.png using wikicode like:

<span class="plainlinks"><nowiki>[{{fullurl:MediaWiki}} http://upload.wikimedia.org/wikipedia/mediawiki/b/bc/Wiki.png]</nowiki></span>

This has the disadvantage of not registering the link, or the image use, as well as not being easily portable to forks and mirrors.

===Raw HTML===
If you enable {{mediawiki|Manual:$wgRawHtml|$wgRawHtml}}, you can use '''<tt><img></tt>''' tags freely, but this method is highly insecure.

There are, however, some extensions to make it safer, see {{mediawiki|Manual:$wgRawHtml#Related_Extensions}} for details.

==via Extension==
If you are willing to install an extension, several extensions have been created to address this issue:
*{{mediawiki|Extension:ImageMap}} - advanced image shape-link extension, uses the html USEMAP features ''(xml tag)''
*{{mediawiki|Extension:LinkedImage}} - image links ''(XML tag)''
*{{mediawiki|Extension:Icon}} - image links ''(parser function)''

Or you can invent your own linked image syntax, by writing an extension that registers it as a parser hook. See {{mediawiki|Manual:Tag extensions}} for information on extending MediaWiki syntax.

==Other options==
If you want, you can do some more drastic things, such as modify /includes/Sanitizer.php (where the HTML tag whitelist is), and add <img /> to the list of allowed tags.

==See also==
*[[Help:Contents]]
*[[Help:Links]]
*[[Help:Images]]

[[Category:Help|Linked images]]

Help:Links

2008-10-06T12:19:44Z

Gayswee: Reverted edits by 130.94.123.98 (Talk) to last version by Bdk

{{PD Help Page}}
There are four sorts of links in MediaWiki:
# internal links to other pages in the wiki
# external links to websites
# [[#Interwiki links|interwiki links]] (links to other wikis)
# inter-language links to other language versions of the same wiki

To add an internal link, enclose the name of the page you want to link to in double square brackets. When you save the page, you'll see the new link pointing to your page. If the page exists already, it is displayed in blue, empty pages are displayed in red. Selflinks to the current page are not transformed in URLs but displayed in bold.

The first letter of the target page is automatically capitalized and spaces are represented as underscores (typing an underscore in the link will have a similar effect as typing a space, but is not recommended, since the underscore will also be shown in the text).

== How to link ==
{| {{Prettytable}}
|-
|{{Hl3}}|'''Description'''
|{{Hl3}}|'''You type'''
|{{Hl3}}|'''You get'''
|-
|Internal link
|<tt><nowiki>[[Main Page]]</nowiki></tt>
|[[Main Page]]
|-
|Piped link
|<tt><nowiki>[[Main Page|different text]]</nowiki></tt>
|[[Main Page|different text]]
|-
|External link
|<tt><nowiki>http://mediawiki.org</nowiki></tt>
|http://mediawiki.org
|-
|External link,<br />
different title
|<tt><nowiki>[http://mediawiki.org MediaWiki]</nowiki></tt>
|[http://mediawiki.org MediaWiki]
|-
|External link,<br />
numbered
|<tt><nowiki>[http://mediawiki.org]</nowiki></tt>
|[http://mediawiki.org]
|-
|Anchor link
|<tt><nowiki>[[#See also]]</nowiki></tt>
|[[#See also]]
|-
|Anchor link at another page
|<tt><nowiki>[[Help:Images#See also]]</nowiki></tt>
|[[Help:Images#See also]]
|-
|Category link
|<tt><nowiki>[[:Category:Help]]</nowiki></tt>
|[[:Category:Help]]
|-
|Internal link to image file
|<tt><nowiki>[[media:example.jpg]]</nowiki></tt>
|[[media:example.jpg]]
|-
|Internal link to pdf file
|<tt><nowiki>[[media:example.pdf]]</nowiki></tt>
|[[media:example.pdf]]
|-
|Interwiki link
|<tt><nowiki>[[Wikipedia:MediaWiki]]</nowiki></tt>
|[[Wikipedia:MediaWiki]]
|-
|mailto link
|<tt><nowiki>[mailto:info@example.org email me]</nowiki></tt>
|[mailto:info@example.org email me]
|-
|redirect
|<tt><nowiki>#REDIRECT [[Main Page]]</nowiki></tt>
| → [[Main Page]]
|}

=== More advanced ===

{| {{Prettytable}}
|-
|{{Hl3}}|'''Description'''
|{{Hl3}}|'''You type'''
|{{Hl3}}|'''You get'''
|-
|Piped link,<br />
different title
|<tt><nowiki>[[Main Page|<span title="different title">different text</span>]]</nowiki></tt>
|[[Main Page|<span title="different title">different text</span>]]
|-
|External link,<br />
same host unnamed
|<tt><nowiki>[http://{{SERVERNAME}}/pagename]</nowiki></tt>
|[http://{{SERVERNAME}}/pagename]
|-
|mailto named with subject line and body
|<tt><nowiki>[mailto:info@example.org?Subject=URL%20Encoded%20Subject&body=Body%20Text info]</nowiki></tt>
|[mailto:info@example.org?Subject=URL%20Encoded%20Subject&body=Body%20Text info]
|}

----

{{admin tip|tip=
Which protocols (like http:) are allowed for links is controlled by the [http://www.mediawiki.org/wiki/Manual:%24wgUrlProtocols $wgUrlProtocols] setting.
}}

{{admin tip|tip=
To remove the 'external link image' from next to each of the external links, add the following to the page located at <code>MediaWiki:Monobook.css</code> on your wiki.

<pre>
#bodyContent a.external,
#bodyContent a[href ^="gopher://"] {
background: none;
padding-right: 0;
}
</pre>
}}

== How to avoid auto-links ==

By default, when you write a URL as is, it will be transformed to an external link.

To avoid that effect, put the URL between <nowiki> start & end tags as in:

<nowiki><nowiki>http://mediawiki.org</nowiki></nowiki>

== Interwiki links ==
Interwiki links are links from the local wiki to another wiki. For example you can link to the Sunflower article on wikipedia.org by typing <tt><nowiki>[[wikipedia:Sunflower]]</nowiki></tt>. This results in a link like this: [[wikipedia:Sunflower]]

Similar to internal page links, you can create piped links, with alternate link text. e.g. <tt><nowiki>[[wikipedia:Sunflower|big yellow flower]]</nowiki></tt>

Basically this is an abbreviation for longer URLs. A very similar link could be created as a normal external link by typing <tt><nowiki>[http://en.wikipedia.org/wiki/Sunflower Sunflower]</nowiki></tt>, but interwiki links allow you to type out an easy and compact link, almost as if you are linking to a page on your own wiki.

Some interesting things to note:
* Interwiki links are displayed slightly differently to external links, without the little external link icon.
* Complex page names with spaces and other characters are handled elegantly, just as they would be for an internal page link, making this more tidy than creating an external link to a full URL. For example <tt><nowiki>[[wikipedia:Sunflower County, Mississippi]]</nowiki></tt> is in some ways tidier and more elegant than the full URL : <tt>http://en.wikipedia.org/wiki/Sunflower_County%2C_Mississippi</tt>

== See also ==
* [[Help:Linked images|Linked images]]

{{Languages|Help:Links}}

[[Category:Help|Links]]
[[Category:Link]]

Help:Skins

2008-10-05T13:48:19Z

Gayswee: /* See also */ Gallery of user styles

{{PD Help Page}}

Clicking on the [[Special:preferences|my preferences]] link in the upper right while logged in then click on the '''Skin''' button to change your skin. You can also preview the skin by clicking the '''(preview)''' links next to each skin.

You can make changes to the current skin's {{mediawiki|Manual:Interface/Stylesheets|stylesheet}} file (CSS) by creating a subpage of your userpage, "[[Special:Mypage/monobook.css|User:Yourname/monobook.css]]" for example. This requires your site admin to have enabled this feature -- if it is, you will see advice text at the top of your custom CSS page about clearing your browser's cache.

{{admin tip|tip=To enable this feature, you have to set [http://www.mediawiki.org/wiki/Manual:%24wgAllowUserCss $wgAllowUserCss] to your {{mediawiki|Manual:LocalSettings.php|LocalSettings.php}}.}}

== See also ==
* [[Help:Preferences]]
* [http://meta.wikimedia.org/wiki/Gallery_of_user_styles Gallery of user styles] (no official skins)

{{Languages|Help:Skins}}

[[Category:Help|{{PAGENAME}}]]
[[Category:Special Pages|{{PAGENAME}}]]
[[Category:Subpage|{{PAGENAME}}]]

Help:Protecting and unprotecting pages

2008-10-04T04:53:02Z

Gayswee:

{{PD Help Page}}
'''Protecting and unprotecting pages''' is very straightforward, but these operations require [[Help:Sysops and permissions|sysop permissions]].

You can designate a page as a [[Help:Protected pages|protected page]] by clicking the 'Protect page' tab, and supplying a comment (a brief textual description of why you are protecting the page)

There are several reasons why a particular page might be protected. Typically a protected page is one which has been repeatedly targeted with vandalism, or where it is believed that any vandalism would have a unusually severe impact. However there are also many good reasons for ''not'' protecting pages. As a sysop you must make this choice, and wield your power responsibly. A good reason to protect pages would to maintain some overall structured deemed desireable for a speciifc wiki.

{{languages|Help:Protecting and unprotecting pages}}
[[Category:Help|Protecting and unprotecting pages]]

Help:Deleting a page

2008-10-02T08:40:00Z

Gayswee: Reverted edits by 202.137.66.72 (Talk) to last version by Protonk

{{#ifexist: Template:PD Help Page/{{SUBPAGENAME}}|{{PD Help Page/{{SUBPAGENAME}}}}|{{PD Help Page}}}}

== When '''not''' to delete a page : ==
Typically you would delete a page if the contents are entirely inappropriate, and do not match the purposes of the wiki. In other situations you might prefer a less extreme course of action, for example...

* The page should have a different title - So just "move" the page to a better title. See [[Help:Moving a page]]
* The contents should have been placed on a different page - So "merge" the contents into the existing page and then create a redirect. See [[Help:Redirects]]
* The contents are already on a different page - So wipe away all the duplicate content and leave behind a redirect. That way, this page title (which made more sense to somebody), will helpfully redirect to the correct location of the information. See [[Help:Redirects]]
* The page is out-of-date - So update it! If the page describes a current or future event, which has now passed, reword all of the sentences to be in the past tense, that way you have created a page which acts as a historical record. Alternatively label the information as out-of-date, with a warning notice.

So in fact a straightforward delete is generally only necessary if the ''title'' of the page is inappropriate. In other situations, a merge and redirect is more appropriate.

=== Proposing changes ===
Deciding on appropriate content/page titles can be a difficult aspect of wiki organization, and one which can often provoke debates. If the merge or deletion you have in mind, is one which might cause upset, you should propose the change first. Do this by leaving a note to give your reasons on the [[Help:Talk pages|talk page]]. You might also establish a system for labeling the page itself, with a delete/merge proposal template, to make everybody aware of your intentions

=== Unlinking a page ===
If a page is no longer of any value, then you won't have any links pointing to it right? Well you might be surprised. The 'What links here' toolbox feature (bottom left) will tell you which other wiki pages link in to the current page. Always use this feature to check before proceeding with deleting. These related pages will need to be edited, to reflect the change.

== Deletion itself ==
'''Normal users''' cannot permanently delete a wiki page. This is an entirely deliberate design feature, which is an important part of why wikis work. Every kind of editing operation can be reverted by any other user, and that includes resurrecting deleted content. Try not to let it wind you up too much. It doesn't cause significant wasted space, and with nothing but a 'delete' label the page is effectively deleted anyway.

'[[Help:Sysops and permissions|Sysop]]' users ''are'' able to delete a page semi-permanently. See [[Help:Sysop deleting and undeleting]]. Typically sysops might look for delete labels, and do a proper delete on these pages, after a period of time. If for some reason you need a page to be deleted more quickly than that, you will need to contact a sysop to request this.

==See also==
* [[Help:Sysops and permissions]]

{{Languages|Help:Deleting a page}}

{{Help/Category|Help}}

Help:Magic words

2008-09-29T21:52:50Z

Gayswee: /* Behaviour switches */

{{PD Help Page}}

'''Magic words''' are strings of text that MediaWiki associates with a return value or function, such as time, site details, or page names. This page is about usage of standard magic words; for a technical reference, see {{mediawiki|Manual:Magic words}}.

==General notes==
* '''Inheritance:''' page-dependent magic words will affect or return data about the current page, regardless of whether it is in the page code or a transcluded template.

==Behaviour switches==
A behaviour switch controls the layout or behaviour of the page and can often be used to specify desired omissions and inclusions in the content. They are usually written as an upercase word wrapped with double underscores.

{| {{prettytable}}
|-
!{{Hl2}}| Word
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
|{{Hl3}} colspan="3"| '''Table of contents'''
|-
| <nowiki>__NOTOC__</nowiki>
| Hides the table of contents (TOC).
|
|-
|<nowiki>__FORCETOC__</nowiki>
| Forces the table of content to appear at its normal position (above the first header).
|
|-
| <nowiki>__TOC__</nowiki>
| Places a table of contents at the word's current position (overriding <nowiki>__NOTOC__</nowiki>). If this is used multiple times, the table of contents will appear at the first word's position.
|
|-
|{{Hl3}} colspan="3"| '''Editing'''
|-
| <nowiki>__NOEDITSECTION__</nowiki>
| Hides the section edit links beside headings.
|
|-
| <nowiki>__NEWSECTIONLINK__</nowiki>
| Adds a link (([[MediaWiki:Addsection|"+" by default]]) beside the "edit" tab for adding a new section on a non-talk page (see {{mediawiki|m:Help:Section#Adding a section at the end|Adding a section to the end}}).
| 1.7+
|-
|{{Hl3}} colspan="3"| '''Categories'''
|-
| <nowiki>__NOGALLERY__</nowiki>
| Used on a category page, replaces thumbnails in the category view with normal links.
| 1.7+
|-
| <nowiki>__HIDDENCAT__</nowiki>
| Used on a category page, hides the category from the lists of categories in its members and parent categories (there is an option in the [[Help:Preferences|user preferences]] to show them).
| 1.13+
|-
| <nowiki>{{DEFAULTSORT:xyz}}</nowiki>
| Used on a categorized page, sets a default [[Help:Categories|category sort key]].
| 1.10+
|-
|{{Hl3}} colspan="3"| '''Language conversion'''
|-
| <nowiki>__NOCONTENTCONVERT__</nowiki><br /><nowiki>__NOCC__</nowiki>
| On wikis with language variants, don't perform any content language conversion (character and phase) in article display; for example, only show Chinese (zh) instead of variants like zh_cn, zh_tw, zh_sg, or zh_hk.
|
|-
| <nowiki>__NOTITLECONVERT__</nowiki><br /><nowiki>__NOTC__</nowiki>
| On wikis with language variants, don't perform language conversion on the title (all other content is converted).
|
|-
|{{Hl3}} colspan="3"| '''Page formatting'''
|-
| <nowiki>{{DISPLAYTITLE:xyz}}</nowiki>
| Format the current page's title header. The value must be equivalent to the default title: only capitalization changes and replacing spaces with underscores. It can be disabled or enabled by {{mediawiki|Manual:$wgAllowDisplayTitle|$wgAllowDisplayTitle}}; disabled by default before 1.10+, enabled by default thereafter.
| 1.7+
|-
| <nowiki>__END__</nowiki>
| Explicitly marks the end of the article, to prevent MediaWiki from removing trailing whitespace. Removed in {{mediawiki|rev:19213|19213}}.
|
|-
|{{Hl3}} colspan="3"| '''Other'''
|-
| <nowiki>__START__</nowiki>
| No effect.
|
|-
| <nowiki>__NOINDEX__</nowiki>
| Tell search engines not to index the page (ie, do not list in search engines' results).
| {{mediawiki|rev:37973|1.13+}}
|-
| <nowiki>__INDEX__</nowiki>
| Tell search engines to index the page (overrides {{mediawiki|Manual:$wgArticleRobotPolicies|$wgArticleRobotPolicies}}, but not robots.txt).
| 1.13+
|-
| <nowiki>__STATICREDIRECT__</nowiki>
| On redirect pages, don't allow MediaWiki to automatically update the link when someone moves a page and checks "Update any redirects that point to the original title".
| {{mediawiki|rev:37928|1.13+}}
|-
| <nowiki>#REDIRECT [[Page name]]</nowiki>
| Causes the current page to [[Help:Redirects|redirect]] viewers to another page.
|}

==Variables and parser functions==
Variables return information about the current page, wiki, or date. Their syntax is similar to [[Help:Templates|templates]], but capitalized to help avoid conflicts. If a template has the same name and case as a variable, the variable will be used. Usage of the template can be forced by adding the "msg:" modifier (for example, "<code><nowiki>{{msg:CURRENTYEAR}}</nowiki></code>"). In some cases, adding parameters will force the parser to treat a variable as a template; for example, <code><nowiki>{{CURRENTDAYNAME|x}}</nowiki></code> tries to transclude "Template:CURRENTDAYNAME".

Parser functions are very similar to variables, but operate on user input instead of the current page. The first parameter is delimited by a colon (:) instead of a pipe (|). (This page does not document custom parser functions added by the {{mediawiki|Extension:ParserFunctions|ParserFunctions extension}}.)

===Date & time===
The following variables return the current date and time according to the user's timezone [[Special:Preferences|preferences]], defaulting to the UTC timezone.

Due to MediaWiki and browser caching, these variables frequently show when the page was ''cached'' rather than the current time.

{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
|{{Hl3}} colspan="4"| '''Year'''
|-
| <nowiki>{{CURRENTYEAR}}</nowiki>
| {{CURRENTYEAR}}
| Year
|
|-
|{{Hl3}} colspan="4"| '''Month'''
|-
| <nowiki>{{CURRENTMONTH}}</nowiki>
| {{CURRENTMONTH}}
| Month (zero-padded number)
|
|-
| <nowiki>{{CURRENTMONTHNAME}}</nowiki>
| {{CURRENTMONTHNAME}}
| Month (name)
|
|-
| <nowiki>{{CURRENTMONTHNAMEGEN}}</nowiki>
| {{CURRENTMONTHNAMEGEN}}
| Month ([http://en.wikipedia.org/wiki/genitive genitive form])
|
|-
| <nowiki>{{CURRENTMONTHABBREV}}</nowiki>
| {{CURRENTMONTHABBREV}}
| Month (abbreviation)
| 1.5+
|-
|{{Hl3}} colspan="4"| '''Day'''
|-
| <nowiki>{{CURRENTDAY}}</nowiki>
| {{CURRENTDAY}}
| Day of the month (unpadded number)
|
|-
| <nowiki>{{CURRENTDAY2}}</nowiki>
| {{CURRENTDAY2}}
| Day of the month (zero-padded number)
| 1.6+
|-
| <nowiki>{{CURRENTDOW}}</nowiki>
| {{CURRENTDOW}}
| Day of the week (unpadded number)
|
|-
| <nowiki>{{CURRENTDAYNAME}}</nowiki>
| {{CURRENTDAYNAME}}
| Day of the week (name)
|
|-
|{{Hl3}} colspan="4"| '''Time'''
|-
| <nowiki>{{CURRENTTIME}}</nowiki>
| {{CURRENTTIME}}
| Time (24-hour HH:mm format)
|
|-
| <nowiki>{{CURRENTHOUR}}</nowiki>
| {{CURRENTHOUR}}
| Hour (24-hour zero-padded number)
|
|-
|{{Hl3}} colspan="4"| '''Other'''
|-
| <nowiki>{{CURRENTWEEK}}</nowiki>
| {{CURRENTWEEK}}
| Week (number)
|
|-
| <nowiki>{{CURRENTTIMESTAMP}}</nowiki>
| {{CURRENTTIMESTAMP}}
| [[wikipedia:ISO 8601|ISO 8601]] time stamp
| 1.7+
|}

The following variables do the same as the above, but using the site's local timezone instead of user preferences and UTC:
* <nowiki>{{LOCALYEAR}}</nowiki>
* <nowiki>{{LOCALMONTH}}</nowiki>
* <nowiki>{{LOCALMONTHNAME}}</nowiki>
* <nowiki>{{LOCALMONTHNAMEGEN}}</nowiki>
* <nowiki>{{LOCALMONTHABBREV}}</nowiki>
* <nowiki>{{LOCALDAY}}</nowiki>
* <nowiki>{{LOCALDAY2}}</nowiki>
* <nowiki>{{LOCALDOW}}</nowiki>
* <nowiki>{{LOCALDAYNAME}}</nowiki>
* <nowiki>{{LOCALTIME}}</nowiki>
* <nowiki>{{LOCALHOUR}}</nowiki>
* <nowiki>{{LOCALWEEK}}</nowiki>
* <nowiki>{{LOCALTIMESTAMP}}</nowiki>

===Technical metadata===
Revision variables return data about the '''latest edit to the current page''', even if viewing an older version of the page.
{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
|{{Hl3}} colspan="4"| '''Site'''
|-
| <nowiki>{{SITENAME}}</nowiki>
| {{SITENAME}}
| The wiki's site name ({{mediawiki|Manual:$wgSitename|$wgSitename}}).
|
|-
| <nowiki>{{CURRENTVERSION}}</nowiki>
| {{CURRENTVERSION}}
| The wiki's MediaWiki version.
| 1.7+
|-
| <nowiki>{{CONTENTLANGUAGE}}</nowiki>
| {{CONTENTLANGUAGE}}
| The wiki's default interface language ({{mediawiki|Manual:$wgLanguageCode|$wgLanguageCode}})
| 1.7+
|-
|{{Hl3}} colspan="4"| '''Latest revision to current page'''
|-
| <nowiki>{{REVISIONID}}</nowiki>
| {{REVISIONID}}
| Unique ID
| 1.5+
|-
| <nowiki>{{REVISIONDAY}}</nowiki>
| {{REVISIONDAY}}
| Day edit was made (unpadded number)
| 1.8+
|-
| <nowiki>{{REVISIONDAY2}}</nowiki>
| {{REVISIONDAY2}}
| Day edit was made (zero-padded number)
| 1.8+
|-
| <nowiki>{{REVISIONMONTH}}</nowiki>
| {{REVISIONMONTH}}
| Month edit was made (unpadded number)
| 1.8+
|-
| <nowiki>{{REVISIONYEAR}}</nowiki>
| {{REVISIONYEAR}}
| Year edit was made
| 1.8+
|-
| <nowiki>{{REVISIONTIMESTAMP}}</nowiki>
| {{REVISIONTIMESTAMP}}
| Timestamp as of time of edit
| 1.8+
|}

===Statistics===
Numbers returned by these variables contain number separators, but can return raw numbers with the ":R" flag (for example, <code><nowiki>{{NUMBEROFPAGES}}</nowiki></code> = {{NUMBEROFPAGES}} and <code><nowiki>{{NUMBEROFPAGES:R}}</nowiki></code> = {{NUMBEROFPAGES:R}}). Use "|R" for magic words that require a parameter like PAGESINCATEGORY (for example <code><nowiki>{{PAGESINCATEGORY:Help}}</nowiki></code> and <code><nowiki>{{PAGESINCATEGORY:Help|R}}</nowiki></code>).
{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
|{{Hl3}} colspan="4"| '''Entire wiki'''
|-
| <nowiki>{{NUMBEROFPAGES}}</nowiki>
| {{NUMBEROFPAGES}}
| Number of wiki pages.
| 1.7+
|-
| <nowiki>{{NUMBEROFARTICLES}}</nowiki>
| {{NUMBEROFARTICLES}}
| Number of pages in main namespace.
|
|-
| <nowiki>{{NUMBEROFFILES}}</nowiki>
| {{NUMBEROFFILES}}
| Number of uploaded files.
| 1.5+
|-
| <nowiki>{{NUMBEROFEDITS}}</nowiki>
| {{NUMBEROFEDITS}}
| Number of page edits.
| {{mediawiki|rev:21319|1.10+}}
|-
| <nowiki>{{NUMBEROFUSERS}}</nowiki>
| {{NUMBEROFUSERS}}
| Number of registered users.
| 1.7+
|-
| <nowiki>{{NUMBEROFADMINS}}</nowiki>
| {{NUMBEROFADMINS}}
| Number of users in the ''sysop'' {{mediawiki|Manual:User rights|group}}.
| 1.7+
|-
| <nowiki>{{NUMBERINGROUP:groupname}}</nowiki>
| {{NUMBERINGROUP:bureaucrat}} <br /><nowiki>({{NUMBERINGROUP:bureaucrat}} used here)</nowiki>
| Number of users in a specific {{mediawiki|Manual:User rights|group}}.
| {{mediawiki|rev:40116|1.14+}}
|-
|{{Hl3}} colspan="4"| '''Per namespace'''
|-
| <nowiki>{{PAGESINNS:2}}</nowiki><br /><nowiki>{{PAGESINNAMESPACE:2}}</nowiki>
| ''not enabled''
| Number of pages in the given [[Help:Namespaces|namespace]] (replace 2 with the relevant [[Manual:Namespace|namespace ID]]). E.g. <nowiki>{{PAGESINNAMESPACE:14}}</nowiki> equals the number of categories.  Disabled by default, enable with {{mediawiki|Manual:$wgAllowSlowParserFunctions|$wgAllowSlowParserFunctions}}.
| 1.7+
|-
|{{Hl3}} colspan="4"| '''Other'''
|-
| <nowiki>{{PAGESINCATEGORY:Help}}</nowiki><br /><nowiki>{{PAGESINCAT:Help}}</nowiki>
| {{PAGESINCATEGORY:Help}}<br />{{PAGESINCAT:Help}}
| Number of pages in the given [[Help:Categories|category]] (replace "Help" with the relevant category name).
| {{mediawiki|rev:32932|1.13+}}
|-
| <nowiki>{{PAGESIZE:Help:Magic_words}}</nowiki>
| {{PAGESIZE:Help:Magic_words}}
| Returns the byte size of the specified page.
| {{mediawiki|rev:33551|1.13+}}
|}

===URL data===
====URLs====
{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
| <nowiki>{{SERVER}}</nowiki>
| {{SERVER}}
| domain URL ({{mediawiki|Manual:$wgServer|$wgServer}})
|
|-
| <nowiki>{{SERVERNAME}}</nowiki>
| {{SERVERNAME}}
| domain name ({{mediawiki|Manual:$wgServerName|$wgServerName}})
|
|-
| <nowiki>{{SCRIPTPATH}}</nowiki>
| {{SCRIPTPATH}}
| relative script path ({{mediawiki|Manual:$wgScriptPath|$wgScriptPath}})
|
|-
| <nowiki>{{localurl:</nowiki>''page name''<nowiki>}}</nowiki><br /><nowiki>{{localurl:page name|</nowiki>''query string''<nowiki>}}</nowiki>
| {{localurl:page name}}<br />{{localurl:page name|query string}}
| relative path to title
|
|-
| <nowiki>{{fullurl:</nowiki>''page name''<nowiki>}}</nowiki><br /><nowiki>{{fullurl:page name|</nowiki>''query_string''<nowiki>}}</nowiki>
| {{fullurl:page name}}<br />{{fullurl:page name|query_string}}
| absolute path to title
| 1.5+
|-
| <nowiki>{{filepath:Wiki.png}}</nowiki>
| {{filepath:Wiki.png}}
| The absolute URL to a media file.
| {{mediawiki|rev:25854|1.12+}}
|-
| <nowiki>{{urlencode:x y z}}</nowiki>
| <code>{{urlencode:x y z}}</code>
| The input encoded for use in URLs.
| {{mediawiki|rev:14273|1.7+}}
|-
| <nowiki>{{anchorencode:x y z}}</nowiki>
| <code>{{anchorencode:x y z}}</code>
| The input encoded for use in URL section anchors (after the '#' symbol in a URL).
| {{mediawiki|rev:16279|1.8+}}
|}

====Page names====
{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
| <nowiki>{{FULLPAGENAME}}</nowiki>
| {{FULLPAGENAME}}
| Namespace and page title.
| 1.6+
|-
| <nowiki>{{PAGENAME}}</nowiki>
| {{PAGENAME}}
| Page title.
|
|-
| <nowiki>{{BASEPAGENAME}}</nowiki>
| {{BASEPAGENAME}}
| Page title excluding the current [[Help:Subpages|subpage]] and namespace ("Title" on "Title/foo").
| 1.7+
|-
| <nowiki>{{SUBPAGENAME}}</nowiki>
| {{SUBPAGENAME}}
| The [[Help:Subpages|subpage]] title ("foo" on "Title/foo").
| 1.6+
|-
| <nowiki>{{SUBJECTPAGENAME}}</nowiki>
| {{SUBJECTPAGENAME}}
| The namespace and title of the associated content page.
| 1.7+
|-
| <nowiki>{{TALKPAGENAME}}</nowiki>
| {{TALKPAGENAME}}
| The namespace and title of the associated talk page.
| 1.7+
|}

The following are URL-encoded equivalents:
* <nowiki>{{FULLPAGENAMEE}}</nowiki>
* <nowiki>{{PAGENAMEE}}</nowiki>
* <nowiki>{{BASEPAGENAMEE}}</nowiki>
* <nowiki>{{SUBPAGENAMEE}}</nowiki>
* <nowiki>{{SUBJECTPAGENAMEE}}</nowiki>
* <nowiki>{{TALKPAGENAMEE}}</nowiki>

====Namespaces====
{| {{prettytable}}
|-
!{{Hl2}}| Variable
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Versions
|-
| <nowiki>{{NAMESPACE}}</nowiki>
| {{NAMESPACE}}
| Namespace (name)
|-
| <nowiki>{{SUBJECTSPACE}}</nowiki><br /><nowiki>{{ARTICLESPACE}}</nowiki>
| {{SUBJECTSPACE}}<br />{{ARTICLESPACE}}
| Name of the associated content namespace
| 1.7+
|-
| <nowiki>{{TALKSPACE}}</nowiki>
| {{TALKSPACE}}
| Name of the associated talk namespace
| 1.7+
|}

The following are URL-encoded equivalents:
* <nowiki>{{NAMESPACEE}}</nowiki>
* <nowiki>{{SUBJECTSPACEE}}</nowiki>
* <nowiki>{{TALKSPACEE}}</nowiki>

<code><nowiki>{{ns:}}</nowiki></code> returns the localized namespace name for that number constant. The default values are:
{| {{prettytable}}
|-
!{{Hl2}}| Usage
!{{Hl2}}| Output
|-
| <nowiki>{{ns:-2}} or {{ns:Media}}</nowiki>
| {{ns:-2}}
|-
| <nowiki>{{ns:-1}} or {{ns:Special}}</nowiki>
| {{ns:-1}}
|-
| <nowiki>{{ns:0}}</nowiki>
| {{ns:0}}
|-
| <nowiki>{{ns:1}} or {{ns:Talk}}</nowiki>
| {{ns:1}}
|-
| <nowiki>{{ns:2}} or {{ns:User}}</nowiki>
| {{ns:2}}
|-
| <nowiki>{{ns:3}} or {{ns:User_talk}}</nowiki>
| {{ns:3}}
|-
| <nowiki>{{ns:4}} or {{ns:Project}}</nowiki>
| {{ns:4}}
|-
| <nowiki>{{ns:5}} or {{ns:Project_talk}}</nowiki>
| {{ns:5}}
|-
| <nowiki>{{ns:6}} or {{ns:Image}}</nowiki>
| {{ns:6}}
|-
| <nowiki>{{ns:7}} or {{ns:Image_talk}}</nowiki>
| {{ns:7}}
|-
| <nowiki>{{ns:8}} or {{ns:MediaWiki}}</nowiki>
| {{ns:8}}
|-
| <nowiki>{{ns:9}} or {{ns:MediaWiki_talk}}</nowiki>
| {{ns:9}}
|-
| <nowiki>{{ns:10}} or {{ns:Template}}</nowiki>
| {{ns:10}}
|-
| <nowiki>{{ns:11}} or {{ns:Template_talk}}</nowiki>
| {{ns:11}}
|-
| <nowiki>{{ns:12}} or {{ns:Help}}</nowiki>
| {{ns:12}}
|-
| <nowiki>{{ns:13}} or {{ns:Help_talk}}</nowiki>
| {{ns:13}}
|-
| <nowiki>{{ns:14}} or {{ns:Category}}</nowiki>
| {{ns:14}}
|-
| <nowiki>{{ns:15}} or {{ns:Category_talk}}</nowiki>
| {{ns:15}}
|}

===Formatting===
{| {{prettytable}}
!{{Hl2}}| Usage
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Version
|-
|-
| <nowiki>{{lc:XYZ}}</nowiki>
| {{lc:XYZ}}
| The lowercase input.
| 1.5+
|-
| <nowiki>{{lcfirst:XYZ}}</nowiki>
| {{lcfirst:XYZ}}
| The input with the first character lowercase.
| 1.5+
|-
| <nowiki>{{uc:xyz}}</nowiki>
| {{uc:xyz}}
| The uppercase input.
| 1.5+
|-
| <nowiki>{{ucfirst:xyz}}</nowiki>
| {{ucfirst:xyz}}
| The input with the first character uppercase.
| 1.5+
|-
| <nowiki>{{formatnum:-987654321.654321}}</nowiki>
| {{formatnum:-987654321.654321}}
| The input with decimal and decimal group separators, and localized digit script, according to the wiki's default locale.
| 1.7+
|-
| <nowiki>{{padleft:xyz|5|_}}</nowiki><br /><nowiki>{{padleft:xyz|5}}</nowiki>
| {{padleft:xyz|5|_}}<br />{{padleft:xyz|5}}
| The input (first parameter) padded on the left side to the specified width (second parameter) using the specified character (third parameter). If a padding character isn't specified, '0' is used by default.<br />'''bug:''' multibyte characters are interpreted as two characters, which can skew width. These also cannot be used as padding characters.
| 1.8+
|-
| <nowiki>{{padright:xyz|5|_}}</nowiki><br /><nowiki>{{padright:xyz|5}}</nowiki>
| {{padright:xyz|5|_}}<br />{{padright:xyz|5}}
| Identical to padleft, but adds padding characters to the right side.
|-
| <nowiki>{{DIRMARK}}</nowiki><br /><nowiki>{{DIRECTIONMARK}}</nowiki>
| {{DIRMARK}}<br />{{DIRECTIONMARK}}
| Outputs a unicode-directional mark that matches the wiki's default language's direction (<code>&lrm;</code> on left-to-right wikis, <code>&rlm;</code> on right-to-left wikis), useful in text with multi-directional text.
| 1.7+
|-
| <nowiki>{{plural:2|is|are}}</nowiki>
| {{plural:2|is|are}}
| Outputs the correct given pluralization form (parameters except first) depending on the count (first parameter). Plural transformations are used for languages like Russian based on "count mod 10".
|}

===Miscellaneous===
{| {{prettytable}}
!{{Hl2}}| Usage
!{{Hl2}}| Output
!{{Hl2}}| Description
!{{Hl2}}| Version
|-
| <nowiki>{{#language:eo}}</nowiki>
| {{#language:eo}}
| The native name for the given language code.
| 1.7+
|-
| <nowiki>{{#special:userlogin}}</nowiki>
| {{#special:userlogin}}
| The localized name for the given canonical Special: page.
| {{mediawiki|rev:17321|1.9+}}
|-
| <nowiki>{{#tag:tagname}}</nowiki><br /><nowiki>{{#tag:tagname|inner content|parameter=value|parameter2=value}}</nowiki>
| ''(depends on parser tag)''
| Alias for XML-style parser or extension tags, but parsing wiki code. Attribute values can be passed as parameter values ('<code><nowiki><tagname attribute="value"></nowiki></code>' → '<code><nowiki>{{#tag:tagname|attribute=value}}</nowiki></code>'), and inner content as an unnamed parameter ('<code><nowiki><tagname>content</tagname></nowiki></code>' → '<code><nowiki>{{#tag:tagname|content}}</nowiki></code>').
| [[rev:29482|1.12+]]
|}

{{languages}}

[[Category:Help|{{PAGENAME}}]]
[[Category:Time|{{PAGENAME}}]]
[[Category:Magic words|{{PAGENAME}}]]

Template:Languages

2008-09-28T13:12:48Z

Gayswee: + da

== Template ==

<onlyinclude><div class="LanguageLinks">
<table width="100%">
<tr valign="top" style="background: #EEF3E2">
<td style="width: 25px; padding-left: 0.5em;">[[Image:Geographylogo.png|25px|Languages]]</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #aaaaaa;">'''[[Project:Language policy|Languages]]:''' </td><td style="padding: 1px 1em 0; background: #F6F9ED;">
'''[[{{{1|:{{NAMESPACE}}:{{BASEPAGENAME}}}}}|English]]'''
{{Languages/Lang|af|{{{1|}}}}}
{{Languages/Lang|ar|{{{1|}}}}}
{{Languages/Lang|az|{{{1|}}}}}
{{Languages/Lang|bcc|{{{1|}}}}}
{{Languages/Lang|bg|{{{1|}}}}}
{{Languages/Lang|br|{{{1|}}}}}
{{Languages/Lang|ca|{{{1|}}}}}
{{Languages/Lang|cs|{{{1|}}}}}
{{Languages/Lang|da|{{{1|}}}}}
{{Languages/Lang|de|{{{1|}}}}}
{{Languages/Lang|el|{{{1|}}}}}
{{Languages/Lang|es|{{{1|}}}}}
{{Languages/Lang|fa|{{{1|}}}}}
{{Languages/Lang|fi|{{{1|}}}}}
{{Languages/Lang|fr|{{{1|}}}}}
{{Languages/Lang|gu|{{{1|}}}}}
{{Languages/Lang|he|{{{1|}}}}}
{{Languages/Lang|hu|{{{1|}}}}}
{{Languages/Lang|id|{{{1|}}}}}
{{Languages/Lang|it|{{{1|}}}}}
{{Languages/Lang|ja|{{{1|}}}}}
{{Languages/Lang|ko|{{{1|}}}}}
{{Languages/Lang|ksh|{{{1|}}}}}
{{Languages/Lang|mr|{{{1|}}}}}
{{Languages/Lang|ms|{{{1|}}}}}
{{Languages/Lang|nl|{{{1|}}}}}
{{Languages/Lang|no|{{{1|}}}}}
{{Languages/Lang|oc|{{{1|}}}}}
{{Languages/Lang|pl|{{{1|}}}}}
{{Languages/Lang|pt|{{{1|}}}}}
{{Languages/Lang|ro|{{{1|}}}}}
{{Languages/Lang|ru|{{{1|}}}}}
{{Languages/Lang|si|{{{1|}}}}}
{{Languages/Lang|sq|{{{1|}}}}}
{{Languages/Lang|sr|{{{1|}}}}}
{{Languages/Lang|sv|{{{1|}}}}}
{{Languages/Lang|th|{{{1|}}}}}
{{Languages/Lang|tr|{{{1|}}}}}
{{Languages/Lang|uk|{{{1|}}}}}
{{Languages/Lang|vi|{{{1|}}}}}
{{Languages/Lang|yue|{{{1|}}}}}
{{Languages/Lang|zh|{{{1|}}}}}
{{Languages/Lang|zh-hans|{{{1|}}}}}
{{Languages/Lang|zh-hant|{{{1|}}}}}
</td></tr></table></div></onlyinclude>

== Syntax ==
<nowiki>{{Languages|PageName}}</nowiki>

* '''PageName''' (optional) - the name of the page to display language links for. If omitted then the English version of the current page is used. This parameter can normally be omitted, as it is only required if you want to link to a page other than the one you place the template on, which is very uncommon. If this parameter is used on a sub-page make sure you supply the root name, not the full page name (e.g. on [[MediaWiki/fr]] you would need to use <code><nowiki>{{Languages|MediaWiki}}</nowiki></code> and not <code><nowiki>{{Languages|MediaWiki/fr}}</nowiki></code>).

== Usage ==

The template should only be placed on pages that exist in more than one language, and it should be placed in the same location on each translation of the page.

The English version of a page is always the main version, with all other languages as sub-pages, named using the appropriate language code (see below).

For example, on the Main Page you would include the text <code><nowiki>{{Languages}}</nowiki></code>, both on [[Main Page]] itself, and on each of its language sub-pages. The template automatically creates links to any language sub-pages that exist, e.g. <tt>Main Page/ja<tt>, <tt>Main Page/fr</tt>, and ignores non-existant languages.

See [[Project:Language policy]] for further details about translating pages.

== Supported languages ==
This shows you the name of each language's sub-page (using ''Main Page'' as an example). Other languages may be added easily as necessary. Please use the appropriate [[meta:List of Wikipedias|prefix, as used on Wikipedia]] when adding a new language. Please do ''not'' add languages for which no pages exist yet, as this will increase the time needed to include the template without adding any benefit (languages are only displayed to the user when the relevant page exists).

The link on the language names goes to the Wikipedia in that language. '''If no Wikipedia in your language exists, do not add pages in that language to MediaWiki.org!''' This wiki is not the place for language advocacy - please go through the correct channels, and once your language has a Wikipedia then please return to add content here.

{| border="1" cellpadding="5"
! Page Name || Language
|-
| Main Page || [[:en:|English]]
|-
| Main Page'''/af''' || [[:af:|Afrikaans]]
|-
| Main Page'''/ar''' || [[:ar:|Arabic]]
|-
| Main Page'''/az''' || [[:az:|Azerbaijani]]
|-
| Main Page'''/bcc''' || Southern Balochi
|-
| Main Page'''/bg''' || [[:bg:|Bulgarian]]
|-
| Main Page'''/br''' || [[:br:|Breton]]
|-
| Main Page'''/ca''' || [[:ca:|Catalan]]
|-
| Main Page'''/cs''' || [[:cs:|Czech]]
|-
| Main Page'''/da''' || [[:da:|Danish]]
|-
| Main Page'''/de''' || [[:de:|German]]
|-
| Main Page'''/el''' || [[:el:|Greek]]
|-
| Main Page'''/es''' || [[:es:|Spanish]]
|-
| Main Page'''/fa''' || [[:fa:|Persian]]
|-
| Main Page'''/fi''' || [[:fi:|Finnish]]
|-
| Main Page'''/fr''' || [[:fr:|French]]
|-
| Main Page'''/gu''' || [[:gu:|Gujarati]]
|-
| Main Page'''/he''' || [[:he:|Hebrew]]
|-
| Main Page'''/hu''' || [[:hu:|Hungarian]]
|-
| Main Page'''/id''' || [[:id:|Indonesian]]
|-
| Main Page'''/it''' || [[:it:|Italian]]
|-
| Main Page'''/ja''' || [[:ja:|Japanese]]
|-
| Main Page'''/ko''' || [[:ko:|Korean]]
|-
| Main Page'''/ksh''' || [[:ksh:|Kölsch]]
|-
| Main Page'''/mr''' || [[:mr:|Marathi]]
|-
| Main Page'''/ms''' || [[:ms:|Malay]]
|-
| Main Page'''/nl''' || [[:nl:|Nederlands]]
|-
| Main Page'''/no''' || [[:no:|Norwegian]]
|-
| Main Page'''/oc''' || [[:oc:|Occitan]]
|-
| Main Page'''/pl''' || [[:pl:|Polish]]
|-
| Main Page'''/pt''' || [[:pt:|Portugese]]
|-
| Main Page'''/ro''' || [[:ro:|Romanian]]
|-
| Main Page'''/ru''' || [[:ru:|Russian]]
|-
| Main Page'''/si''' || [[:si:|Sinhalese]]
|-
| Main Page'''/sq''' || [[:sq:|Albanian]]
|-
| Main Page'''/sr''' || [[:sr:|Serbian]]
|-
| Main Page'''/sv''' || [[:sv:|Swedish]]
|-
| Main Page'''/th''' || [[:th:|Thai]]
|-
| Main Page'''/tr''' || [[:tr:|Turkish]]
|-
| Main Page'''/uk''' || [[:uk:|Ukrainian]]
|-
| Main Page'''/vi''' || [[:vi:|Vietnamese]]
|-
| Main Page'''/yue''' || [[:zh-yue:|Cantonese]]
|-
| Main Page'''/zh''' || [[:zh:|Chinese]]
|-
| Main Page'''/zh-hans''' || Chinese (Simplified)
|-
| Main Page'''/zh-hant''' || Chinese (Traditional)
|}

== Example ==
Here is how the language bar looks on the [[MediaWiki]] page:
{{Languages|MediaWiki}}
[[Category:Language templates]]

Template:Thankyou

2008-09-27T22:04:34Z

Gayswee:

<div class="noprint" style="float:right; border:1px solid blue;width:200px;background-color:#fff;padding:3px;">
[[Image:Example.jpg|left|80px|Example sunflower image]] '''A little thank you...''' <br /><small>for {{{reason|{{{1}}}}}}. <br />hugs, {{{signature|{{{2}}}}}}</small>
</div>
<noinclude>
{{Languages|Template:Thankyou}}
[[Category:Template examples|{{PAGENAME}}]]</noinclude>