MediaWiki API result
This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.
See the complete documentation, or the API help for more information.
{
"batchcomplete": "",
"continue": {
"gapcontinue": "Reverse_Regression_Testing",
"continue": "gapcontinue||"
},
"warnings": {
"main": {
"*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
},
"revisions": {
"*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
}
},
"query": {
"pages": {
"480": {
"pageid": 480,
"ns": 0,
"title": "Regedit",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "__NOTOC__\n'''regedit''' is Wine's registry editor, similar in appearance and function to Window's regedit. When invoked as `wine regedit` with no arguments, the program runs in GUI mode.\n\n'''Note:''' Although Wine stores the registry as text files (specifically <tt>$WINEPREFIX/*.reg</tt>), you should use the regedit tool for making changes to the registry, just like you would on Windows. This is because of, amongst other things, the special encoding used to store keys.\n\n== Usage ==\n<pre>\n wine regedit filename\n wine regedit /E filename [regpath]\n wine regedit /D regpath\n\nfilename - registry file name\nregpath - name of the registry key\n\nWhen called without any switches, adds the content of the specified file to the registry\n\nSwitches:\n /E - exports contents of the specified registry key to the specified\n file. Exports the whole registry if no key is specified.\n /D - deletes specified registry key\n /S - silent execution, can be used with any other switch.\n Default. The only existing mode, exists for compatibility with Windows regedit.\n /V - advanced mode, can be used with any other switch.\n Ignored, exists for compatibility with Windows regedit.\n /L - location of system.dat file. Can be used with any other switch.\n Ignored. Exists for compatibility with Windows regedit.\n /R - location of user.dat file. Can be used with any other switch.\n Ignored. Exists for compatibility with Windows regedit.\n /? - print this help. Any other switches are ignored.\n /C - create registry from file. Not implemented.\n\nThe switches are case-insensitive, can be prefixed either by '-' or '/'.\nThis program is command-line compatible with Microsoft Windows regedit\n</pre>\n\n== User Keys Backup ==\nThe user can save whatever particular settings he/she wishes, in case of ~/.wine being removed or created on a new system. \n\nFor backing up software settings:\n<ol>\n<li> Run ''regedit'' , navigate to <tt>HKEY_CURRENT_USER\\Software</tt>, and click on the folder.\n<li> Click Registry -> Export Registry File . Save as ''myoptions.reg'' but be sure to click the \"Selected Branch\" button before OK\n<li> Or to combine multiple individual folders (in the HCU\\Software dir) into a single .reg file:\n<ol style=\"list-style-type:lower-alpha\">\n<li> Navigate to <tt>HKEY_CURRENT_USER\\Software</tt> and click on the pertinent program's folder\n<li> Click File -> Export , making sure the \"Selected Branch\" button is selected\n<li> Save the files as ''myoptions.reg myoptions2.reg myoptions3.reg'' and so on, for each top-level folder\n<li> In the terminal/console, cd to the directory of the saved files\n<li> Run ''cat myoptions.reg myoptions2.reg myoptions3.reg > foo && cp foo myoptions.reg && rm foo''\n</ol>\n<li> Registry backup is finished! Restore the keys into the registry any time by running ''regedit myoptions.reg''\n</ol>\n\n== See Also ==\n* [[Useful Registry Keys]] -- a collection of registry keys for further tweaking of Wine\n\n----"
}
]
},
"66": {
"pageid": 66,
"ns": 0,
"title": "Regression Testing",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "'''''Translations of this page:''''' not yet ported. Translators, see Discussion page.\n\nSometimes updates to Wine, designed to fix bugs or introduce new features, cause unexpected new problems, called regressions. Since most users only update at new releases, hundreds of patches may be committed before someone notices the regression. This is where regression testing comes in.\n\nBy using the [http://git-scm.com/ Git source control program] and its [http://git-scm.com/docs/git-bisect bisect command] specifically, debuggers can partially (or even fully in some cases) automate a binary search over Wine's revision history for the exact patch that causes the regression. For a more general article on using git and Wine together, see [[Git Wine Tutorial]]; this article is focused on regression testing.\n\n== Before you start ==\n=== A cheap alternative? ===\nThe Wine codebase is not small and takes some time to build so if you can pin down the problem patch by other means, you could save significant time and effort. One possibility is that the failure has been caught by Wine's suite of automatic ConformanceTests. If you have some idea of which components in Wine are failing, you can skim the automated test results for recent builds of Wine at http://test.winehq.org/data.\n\nFor instance, http://bugs.winehq.org/show_bug.cgi?id=28415 was narrowed down by looking at http://test.winehq.org/data/tests/winmm:midi.html. That's not often going to be possible, but when it is, it's easier than running a real regression test.\n\n=== Getting the source ===\nTo begin, first make sure git is installed on your system and you are using version 1.4.1 or newer (should only be an issue with very old/stable distros):\n\n git --version\n\nIf git is not installed, download and install it using your distribution's package manager. For example, to install git in Ubuntu use:\n\n sudo apt-get install git\n\n\nTo save lots of time during the regression testing, you might want to consider installing [http://ccache.samba.org/ ccache], which can cache some compilation steps to avoid redundant work. You can probably find ccache using your distro's package manager. For example, on Ubuntu, simply use:\n\n sudo apt-get install ccache\n\n\nWith git and ccache installed, you should be able to [http://git-scm.com/docs/git-clone clone] the Wine source code to a directory of your choice (\"wine-git\" is used in this page's examples) with the following command:\n\n git clone https://source.winehq.org/git/wine.git wine-git/\n cd wine-git/\n\nThe Wine source tree is large (hundreds of megabytes) so downloading and initializing the repository will take some time. If you are behind a firewall, you may also need to replace '''git:''' with '''http:''' in the remote address. Now that you have a bleeding-edge copy of the source code, we can begin testing.\n\n=== Compiling Wine ===\nJust to check that the regression hasn't already been fixed in a very recent patch, you will probably want to compile Wine. This also seeds ccache and ensures that you have all the proper build dependencies. First, run the configure script inside your Wine repository with the appropriate options:\n\n CC=\"ccache gcc\" ./configure --verbose --disable-tests\n\nReassigning the CC variable enables ccache by default every time you recompile, and the --disable-tests option will also save the time that would be used to compile Wine's test suite (which shouldn't be necessary for testing regressions). The WineTestBot system is usually used to check the test suite itself for regressions.\n\nAlso, if you have a 64-bit processor, you will need to do some steps differently to avoid errors. WineOn64bit has more information, including for specific distributions, but generally you will want to run configure using something like this:\n\n CC=\"ccache gcc -m32\" ./configure --verbose --disable-tests\n\n\nRegardless of your processor, unless you've compiled Wine before, configure will probably return some errors due to missing dependencies. With some distros, you can use the package manager to quickly install all dependencies. For example, on Debian-based distros, you can use:\n\n sudo apt-get build-dep wine wine-dev\n\nFor information on other distros and detailed lists, see [[:Category:Distributions]]. After installing dependencies, run the <tt>./configure</tt> command again, and repeat this process until you receive no errors.\n\nAfter a successful run of configure, the makefile in your repository should be setup properly, and you can build wine by simply entering `make`. Compilation will take some time, depending on the speed of your hardware. Some computers take as few as 3 minutes, while some may take hours, though 20 to 40 minutes seems about average. Running `make install` after compiling is '''not recommended'''. Not only will it cause conflicts in your system as you test different versions of Wine over the course of the bisection, but it will interfere with any stable version of Wine you already have installed.\n\nOnce Wine finishes compiling, you'll want to test for the bug. To be safe, test with a clean .wine directory, which can be done by either backing up the existing wine directory or switching to a new wineprefix (if using a different wineprefix, remember that the wine directory resets to default once you end the terminal session):\n\n mv ~/.wine ~/.wine-backup\n\nor\n\n WINEPREFIX=\"~/.wine-test\"\n\n'''Note:''' Some bugs can be suppressed simply by giving a program a fresh .wine directory of its own.\n\n\nNow, install your application from scratch, and make sure that you're running the git version of Wine by invoking it with a full path:\n\n wine-git/wine program_install.exe\n\ninstead of just\n\n wine program_install.exe\n\n\nFinally run your installed program (again making sure to invoke the built-from-source version of Wine):\n\n ./wine \"C:\\Program Files\\Program Name\\program.exe\"\n\nHopefully, your bug has been already fixed, in which case you can use the git version to run your program until the next release. If not, you will have to run the bisection to pin down the cause of the regression.\n\n=== Regressions between wine-staging versions ===\n\nBecause wine-staging is a set of constantly rebased patches applied on top of upstream, it can't be bisected in the same way as upstream wine. For instructions on bisecting between wine-staging versions, see [[Wine-Staging#Regressions_between_Staging_versions]]. The basic process will probably be similar to the instructions on this page, but the details may differ.\n\n== Running the bisection ==\n=== Preliminary notes ===\nIf you don't remember which version of Wine you were using when the program last worked, you can try finding it by installing archived binary packages of Wine (e.g. from http://wine.budgetdedicated.com/archive/index.html). Eliminating as many early versions of Wine from the bisection as possible allows testing a smaller set of revisions. It can also help you avoid building very old versions of Wine, which are a headache to compile due to major changes in Wine's design and dependencies.\n\nAlso, you don't need an internet connection while doing the regression test. The bisection will run entirely within your local git repository.\n\n=== Walkthrough ===\nSuppose that you have a bug that was introduced when upgrading from Wine 0.9.36 to Wine 0.9.37 (these numbers are release tags; for a list of release tags in use, see [http://source.winehq.org/git/?p=wine.git;a=tags here]). The following command will set up git to test for your bug between these releases:\n\n git bisect start\n git bisect good wine-0.9.36\n git bisect bad wine-0.9.37\n\nSometimes, however, you may know exactly which component the bad patch was in, if so, you can tell git. Omitting the tag parameters from the `bad` and `good` commands respectively tells git that the most recent version is broken (very likely) and that even the earliest revision should be tested (not recommended, see notes above). For example, to tell git that the problem is in the wined3d dll component, and the problem wasn't present in Wine 0.9.38 but is in the current version, use:\n\n git bisect start -- dlls/wined3d\n git bisect good wine-0.9.38\n git bisect bad\n\n\nGit will then tell you the number of commits that will be tested in the interval. Don't worry if it seems large, it won't take that many tests :-). Git will revert the source to the version between the two end-points (`good` and `bad`). For example, if you have 100 commits to test, it will position the source at the 50th commit. At this point you will recompile the Wine source code with `make`. While it shouldn't always be necessary to rerun './configure' too, if you want to be safe (which might be good if you're testing over a large interval), you can run both in one command:\n\n ./configure --verbose && make\n\n\nIf the version you are testing fails to compile (or cannot be tested for some other reason), enter:\n\n git bisect skip\n\nThen try running `make` again. Repeat this as many times as necessary until Wine successfully compiles. This can particularly cause problems with old versions of Wine because of changes to freetype ([http://www.winehq.org/pipermail/wine-patches/2008-September/060764.html this mailing list discussion] explains why and includes a patch).\n\nOnce you've successfully recompiled Wine, run your program and test for your bug. If the bug is still present, you know that the problems started somewhere among the older 50 patches, not in the newer 50. To tell that to git, issue the command:\n\n git bisect bad\n\n\nIf the bug wasn't present, you know that the regression was caused by one of newer 50 patches. To tell that to git, issue the command:\n\n git bisect good\n\n\nThese commands tell git to ignore the half of the interval that does not need testing, then reposition the source code at the midpoint of the remaining patches. At this point, you simply need to continue repeating the process, recompiling Wine, testing for the bug, then notifying git whether the bug was present or not. After a few tests, git will eventually identify the bad patch, and output something like this:\n\n a460a2df43aa8eae10b1db028c6020829b009c54 is first bad commit\n commit a460a2df43aa8eae10b1db028c6020829b009c54\n Author: Stefan Doesinger <[email protected]>\n Date: Sat Jun 9 14:27:41 2007 +0200\n wined3d: Store the gl information in a per adapter structure and initialize it only once.\n :040000 040000 d8ae35832fcdbca8de07acae73b9e21564ced413\n 1720cc38fb598110071c9ee4f21f8f61b6f764c3 M dlls\n\n'''If you do not see a message telling you the hash of the first bad commit, but something like this instead:'''\n\n Bisecting: 0 revisions left to test after this\n\n'''you are not done yet'''. This message means you have pinpointed a specific patch but still need to test if it is the last good or first bad commit so compile and test one more time.\n\nIf all you get are \"good\" tests (the bug fails to show), git's final output may have a line reading \"Release x.x.xx\" and look like this:\n\n b821e839bb33ac8f56939cc582010ecf4d9c25d4 is first bad commit\n commit b821e839bb33ac8f56939cc582010ecf4d9c25d4\n Author: Alexandre Julliard <[email protected]>\n Date: Fri Mar 21 16:41:33 2008 +0100\n Release 0.9.58.\n :100644 100644 9123c03a3138b05cb8ebb5271f554bb76510cd09 3b88d88dcdfc8e148f8e7e0858bf0ca62c0bdff3 M ANNOUNCE\n :100644 100644 900c8932cb5aad58e928a5c3192ab95967dc0664 e001d501bec609c31c5a91ab185a06ef1662f4c8 M ChangeLog\n :100644 100644 5614cdd9b3c6af6d44027f067fcc423e49c49c91 36e035642c055736e2f833210f5db334a6706486 M VERSION\n :100755 100755 a516335cb3e4c67298f285adbdb2ede09da133be 51a9fd0b9741b28a588e2dd3bb57ae2be8805af2 M configure\n\nThis probably means the regression actually occurs outside of the interval you've given. This particular output is just a version tag, meaning that no real code was changed (and cannot have made your problem appear). You will need to reset your bisection (see below) and use that \"Release x.x.xx\" as your first `good` bisect (wine-x.x.xx).\n\n=== Contact the developer ===\nOnce you have identified which patch is causing the regression, post the information to any bug reports in [http://bugs.winehq.org bugzilla] (enter a new report if one hasn't already been filed). Also, be sure to '''CC the author of the patch''' when you post to the bug report. This will allow the developers to fix the problem much quicker.\n\n=== Resetting the bisect ===\nOnce you've finished with a test, you may want to check something else or simply use the latest git version. If you try to start a new bisection before resetting, git-bisect will fail with \"won't bisect on seeked tree.\" Also, the bisection process causes git to leave your branches so to reset your git repository and return to the default branch, use:\n\n git bisect reset\n git checkout master\n\n== Working with developers ==\n=== Reverting the patch ===\nIf the bisect identifies a patch that a developer believes is harmless, you may be asked to check your result by reverting that patch. First, reset your bisect if you haven't already, then use the revert command with the SHA1 ID of the bad patch. The <tt>-n</tt> flag avoids committing the reversion:\n\n git revert -n b821e839bb33ac8f56939cc582010ecf4d9c25d4\n\n\nRebuild Wine and test your program again. When you're done testing, be sure to reset your tree to the latest Wine commit:\n\n git reset --hard HEAD\n\n=== Patching your git tree ===\nNow suppose a developer posts a new patch that they want you to test. Though this may seem overwhelming, it's quite simple. Simply download the patch (likely from Bugzilla, or possibly from e-mail) and copy it to the top-level directory of your git repository. Then run:\n\n git apply patch_name.diff\n\nThis will patch the source code and if successful, should output a confirmation listing the directories that have been message.\n\nSee, wasn't that hard! Now if you're going to be testing any other programs, you don't want your tree cluttered with patches you were testing for another program. To undo '''all''' patches to your git tree, run:\n\n git reset --hard origin\n\nThis will reset all commits you've made, but this shouldn't be an issue if you're only testing and not developing patches of your own.\n\n=== Updating your git tree ===\nLet's assume that some time has passed, and a bug you've been following is now reported to work in the latest source version of Wine. If you want to test this, you need to update your git repository and compile the new version. Updating consists of two steps, first downloading any new patches, then syncing your local repository to point to the latest revision:\n\n git fetch\n git rebase origin\n\nOnce that's done, just compile Wine again and test. If there was a fix for your bug in one of the new patches, your program should now work!\n\n== Other ideas ==\n=== Automating the bisection ===\nIf the regression is something easily scripted (e.g. a broken compile, a program that crashes without any user interaction, etc.), you can use a script to automate git-bisect. For instance, if 'winetricks dotnet11' crashes for you in 1.1.44, but not 1.1.43, you would setup the bisection interval like normal, but then run a script:\n\n git bisect start\n git bisect good wine-1.1.43\n git bisect bad wine-1.1.44\n git bisect run ./foo.sh\n\n\nThe script foo.sh should look something like:\n\n #!/bin/sh\n ./configure --disable-tests || exit 125\n make || exit 125\n rm -rf $HOME/.wine || exit 125\n WINE=$HOME/wine-git/wine winetricks -q dotnet11\n\nThe key point is that git decides what to do at each step based on error codes. The script should exit with a non-zero status for a failure, and with zero for success. If Wine fails, it will pass the error code for you, but all other steps in the script should exit with 125 on failure. Error code 125 tells git to skip a patch instead of registering it as \"bad.\"\n\n=== Testing a broken compile ===\nIf the regression you're testing for is a broken compilation, it should be easy to automate the bisection as shown above. One major difference is that you should not pass error code 125 if make fails (because you want to mark compiler failures, not skip them):\n\n #!/bin/sh\n ./configure --disable-tests || exit 125\n make\n\n=== Disabling optimization to speed up compilation ===\nWhen compiling Wine, a large portion of the build time is spent optimizing code. Unless you're testing for performance issues, this becomes unnecessary when running a bisection. You might be able to speed up compilation substantially by skipping optimization. This can be done by passing a few flags to `configure` on the command line, like so:\n\n CC=\"ccache gcc\" CFLAGS=\"-g -O0\" ./configure --verbose\n\n=== Disabling tests to speed up compilation ===\nWhen building a plain vanilla version of Wine from source, compiling the test suite also takes up a good deal of time. While these tests are invaluable for development, they are not needed for regression testing (we already know something broke, so conformance is irrelevant).\n\nAlexandre Julliard committed a [http://source.winehq.org/git/wine.git/?a=commitdiff;h=35078f4b57523d4afe00d01da9afb9cbe2c37dba patch] that allows one to disable building the test suite when regression testing. For Wine 1.1.9 and above, you can simply pass the `--disable-tests` flag to configure:\n\n ./configure --disable-tests\n\n\nIf your last known \"good\" version is older, a small hack is needed. This patch works for versions of Wine up to around 1.1.3:\n<pre>\ndiff --git a/dlls/Makefile.in b/dlls/Makefile.in\nindex d7b0976..2b4b779 100644\n --- a/dlls/Makefile.in\n+++ b/dlls/Makefile.in\n@@ -332,7 +332,7 @@ SUBDIRS = \\\n winequartz.drv \\\n winex11.drv\n-BUILDSUBDIRS = $(BASEDIRS) $(EXTRADIRS) $(TESTSUBDIRS)\n+BUILDSUBDIRS = $(BASEDIRS) $(EXTRADIRS)\n INSTALLSUBDIRS = $(BASEDIRS) $(EXTRADIRS) $(IMPLIBSUBDIRS)\n DOCSUBDIRS = $(BASEDIRS) $(EXTRADIRS)\ndiff --git a/programs/Makefile.in b/programs/Makefile.in\nindex 3c128e1..72dbdb8 100644\n--- a/programs/Makefile.in\n+++ b/programs/Makefile.in\n@@ -41,7 +41,6 @@ SUBDIRS = \\\n winemenubuilder \\\n winemine \\\n winepath \\\n- winetest \\\n winevdm \\\n winhelp \\\n winver \\\n--\n1.4.4.2\n</pre>\nIf you're testing Wine versions between 1.1.3 and 1.1.9, use this patch instead:\n<pre>\ndiff --git a/dlls/Makefile.in b/dlls/Makefile.in\nindex 6680673..e998a38 100644\n--- a/dlls/Makefile.in\n+++ b/dlls/Makefile.in\n@@ -9,9 +9,8 @@ INSTALLDIRS = $(DESTDIR)$(dlldir)\n DLLSUBDIRS = @ALL_DLL_DIRS@\n IMPLIBSUBDIRS = @ALL_IMPLIB_DIRS@\n-TESTSUBDIRS = @ALL_TEST_DIRS@\n-SUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS) $(TESTSUBDIRS)\n-BUILDSUBDIRS = $(DLLSUBDIRS) $(TESTSUBDIRS)\n+SUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS)\n+BUILDSUBDIRS = $(DLLSUBDIRS)\n INSTALLSUBDIRS = $(DLLSUBDIRS) $(IMPLIBSUBDIRS)\n DOCSUBDIRS = $(DLLSUBDIRS)\n@@ -445,8 +444,6 @@ CROSS_IMPLIBS = \\\n wsock32/libwsock32.a \\\n wtsapi32/libwtsapi32.a\n-$(TESTSUBDIRS:%=%/__crosstest__): $(CROSS_IMPLIBS)\n-\n implib: $(IMPORT_LIBS)\n .PHONY: implib\ndiff --git a/programs/Makefile.in b/programs/Makefile.in\nindex 7bd60b2..e5edef4 100644\n--- a/programs/Makefile.in\n+++ b/programs/Makefile.in\n@@ -38,7 +38,3 @@ install install-lib:: install-progs$(DLLEXT) $(INSTALLDIRS)\n uninstall::\n -cd $(DESTDIR)$(bindir) && $(RM) wineapploader $(INSTALLPROGS)\n -rmdir $(DESTDIR)$(dlldir)\n-\n-# Rules for testing\n-\n-check test:: $(SUBDIRS:%=%/__test__)\ndiff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in\nindex d153c04..3dd7bcd 100644\n--- a/programs/winetest/Makefile.in\n+++ b/programs/winetest/Makefile.in\n@@ -21,10 +21,6 @@ SVG_SRCS = winetest.svg\n @MAKE_PROG_RULES@\n-ALL_TEST_DIRS = @ALL_TEST_DIRS@\n-\n-TESTBINS = $(ALL_TEST_DIRS:%/tests=%_test.exe)\n-\n @ALL_WINETEST_DEPENDS@\n # Special rules\n--\n1.5.3.6\n</pre>\n\nHowever, care must be taken when using these patches. Git doesn't like you editing the tree in the middle of a bisection. So to disable tests while bisecting old versions of Wine, use this little trick everytime you recompile Wine in the bisection:\n\n git apply disable_test_patch.diff && CC=\"ccache gcc\" ./configure && make depend && make && git apply -R < disable_test_patch.diff}}}\n\nTest your app and use the git-bisect `good` and `bad` commands as usual. The alternate recompilation command applies one of the patches above (be sure to download the proper one and invoke it with the name you saved it under), compiles Wine, then reverses the patch, leaving git none the wiser.\n\n== Troubleshooting ==\nIf you are having problems with regression testing, you might want to try double-checking the [http://git-scm.com/docs/ git documentation] first of all. Another possibility is asking for help on the [irc://irc.libera.chat:6697/#winehackers #winehackers] channel on [https://www.winehq.org/irc IRC]. If you are particularly having trouble compiling or running an older version of Wine, odds are the instructions in [[Reverse Regression Testing]] will be able to help you.\n\n== See Also ==\n* You can see a list of regressions that haven't been bisected and how many regressions different developers have pinpointed [http://source.winehq.org/regressions here].\n* [[Reverse Regression Testing]]\n\n[[Category:Development]] [[Category:Quality Assurance]]"
}
]
}
}
}
}