[1/2] [docs] winedev: Use appropriate tags for code excerpts
Frédéric Delanoy
frederic.delanoy at gmail.com
Thu Sep 5 15:56:49 CDT 2013
---
en/winedev-architecture.sgml | 2 +-
en/winedev-coding.sgml | 34 ++++++++++++++++-----------------
en/winedev-ddraw.sgml | 2 +-
en/winedev-debugger.sgml | 20 ++++++++++----------
en/winedev-debugging.sgml | 14 +++++++-------
en/winedev-kernel.sgml | 6 +++---
en/winedev-ole.sgml | 8 ++++----
en/winedev-opengl.sgml | 2 +-
en/winedev-otherdebug.sgml | 45 ++++++++++++++++++++++----------------------
en/winedev-testing.sgml | 22 +++++++++++-----------
en/winedev-windowing.sgml | 14 +++++++-------
11 files changed, 84 insertions(+), 85 deletions(-)
diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml
index 978e55a..9a7ce4e 100644
--- a/en/winedev-architecture.sgml
+++ b/en/winedev-architecture.sgml
@@ -483,7 +483,7 @@
<para>
The Wine server itself is a single and separate Unix
process and does not have its own threading - instead, it
- is built on top of a large <function>poll()</function>
+ is built on top of a large <code language="c">poll()</code>
loop that alerts the Wine server whenever anything
happens, such as a client having sent a command, or a wait
condition having been satisfied. There is thus no danger
diff --git a/en/winedev-coding.sgml b/en/winedev-coding.sgml
index 78c507f..edc1d87 100644
--- a/en/winedev-coding.sgml
+++ b/en/winedev-coding.sgml
@@ -100,16 +100,16 @@
<listitem>
<para>
Commenting out a block of code is usually done by
- using <command>if (0)</command>. For example:
+ using <code language="c">if (0)</code>. For example:
</para>
- <screen>
+ <programlisting language="c">
/* note about reason for commenting block */
if (0) {
code
code /* comments */
code
}
- </screen>
+ </programlisting>
<para>
The reason for using this method is that it does not
require that you edit comments that may be inside the
@@ -237,15 +237,15 @@ code
<para>
Operating systems change. Maybe yours doesn't have the
<filename class="headerfile">foo.h</filename> header, but maybe a future
- version will have it. If you want to <userinput>#include
- <foo.h></userinput>, it doesn't matter what operating
+ version will have it. If you want to <code language="c">#include
+ <foo.h></code>, it doesn't matter what operating
system you are using; it only matters whether
<filename class="headerfile">foo.h</filename> is there.
</para>
<para>
Furthermore, operating systems change names or <quote>fork</quote> into
- several ones. An <userinput>#ifdef <replaceable>MyOS</replaceable></userinput> will break
- over time.
+ several ones. An <code language="c">#ifdef <replaceable>MyOS</replaceable></code> will
+ break over time.
</para>
<para>
If you use the feature of <command>autoconf</command> -- the
@@ -323,13 +323,13 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<para>
Now you can change
</para>
- <programlisting>
+ <programlisting language="c">
#include <foo.h>
</programlisting>
<para>
to
</para>
- <programlisting>
+ <programlisting language="c">
#ifdef HAVE_FOO_H
#include <foo.h>
#elif defined (HAVE_BAR_H)
@@ -339,11 +339,11 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<para>
If your system doesn't have a corresponding header file even
though it has the library functions being used, you might
- have to add an <literal>#else</literal> section to the
+ have to add an <code language="c">#else</code> section to the
conditional. Avoid this if you can.
</para>
<para>
- You will also need to add <userinput>#undef HAVE_FOO_H</userinput>
+ You will also need to add <code language="c">#undef HAVE_FOO_H</code>
(etc.) to <filename class="headerfile">include/config.h.in</filename>.
</para>
<para>
@@ -369,7 +369,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
</para>
<para>
Secondly, you will also need to add
- <symbol>#undef HAVE_BAR</symbol> to
+ <code language="c">#undef HAVE_BAR</code> to
<filename class="headerfile">include/config.h.in</filename>.
</para>
<para>
@@ -388,15 +388,15 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<para>
You add your implementation in
<filename>misc/port.c</filename> surrounded by
- <userinput>#ifndef HAVE_MEMMOVE</userinput> and
- <literal>#endif</literal>.
+ <code language="c">#ifndef HAVE_MEMMOVE</code> and
+ <code language="c">#endif</code>.
</para>
<para>
You might have to add a prototype for your function.
If so, <filename class="headerfile">include/miscemu.h</filename> might be
the place. Don't forget to protect that definition by
- <userinput>#ifndef HAVE_MEMMOVE</userinput> and
- <literal>#endif</literal> also!
+ <code language="c">#ifndef HAVE_MEMMOVE</code> and
+ <code language="c">#endif</code> also!
</para>
</listitem>
</varlistentry>
@@ -413,7 +413,7 @@ AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
<filename>loader/signal.c</filename>. Here we have a
multi-branch case on features:
</para>
- <programlisting>
+ <programlisting language="c">
#ifdef HAVE_THIS
...
#elif defined (HAVE_THAT)
diff --git a/en/winedev-ddraw.sgml b/en/winedev-ddraw.sgml
index 4fc3614..f2c5243 100644
--- a/en/winedev-ddraw.sgml
+++ b/en/winedev-ddraw.sgml
@@ -117,7 +117,7 @@
For example, the <classname>DIBTexture</classname> <type>DirectDrawSurface</type>
implementation looks like this:
</para>
- <programlisting>
+ <programlisting language="c">
struct DIBTexture_DirectDrawSurfaceImpl_Part
{
union DIBTexture_data data; /*declared in the real header*/
diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml
index 3ed92e3..f2228b4 100644
--- a/en/winedev-debugger.sgml
+++ b/en/winedev-debugger.sgml
@@ -535,18 +535,18 @@ process tid prio (all id:s are in hex)
If you have found a misbehaving Wine function, try to find out
why it misbehaves. Find the function in the source code.
Try to make sense of the arguments passed. Usually there is a
- <function>WINE_DEFAULT_DEBUG_CHANNEL(<parameter><replaceable>channel</replaceable></parameter>);</function>
+ <code language="c">WINE_DEFAULT_DEBUG_CHANNEL(<parameter><replaceable>channel</replaceable></parameter>);</code>
at the beginning of the source file. Rerun wine with the
<userinput><envar>WINEDEBUG</envar>=+xyz,+relay</userinput> environment variable set.
</para>
<para>
Occasionally there are additional debug channels defined at the
beginning of the source file in the form
- <function>WINE_DECLARE_DEBUG_CHANNEL(<parameter><replaceable>channel</replaceable></parameter>);</function>
+ <code language="c">WINE_DECLARE_DEBUG_CHANNEL(<parameter><replaceable>channel</replaceable></parameter>);</code>
if so the offending function may also use one of these alternate
channels. Look through the the function for
- <function>TRACE_(<parameter><replaceable>channel</replaceable></parameter>)("
-<parameter><replaceable>...</replaceable></parameter> /n");</function> and add any
+ <code language="c">TRACE_(<parameter><replaceable>channel</replaceable></parameter>)("
+ <parameter><replaceable>...</replaceable></parameter> /n");</code> and add any
additional channels to the command line.
</para>
</listitem>
@@ -692,7 +692,7 @@ process tid prio (all id:s are in hex)
is usually written in C). Win16 function entries usually
look like that:
</para>
- <programlisting>
+ <programlisting language="asm">
push bp
mov bp, sp
... function code ..
@@ -705,7 +705,7 @@ retf XXXX <--------- XXXX is number of bytes of arguments
<literal>[bp+6]</literal> belongs to the
<emphasis>rightmost</emphasis> argument, for exported win16
functions use the <literal>PASCAL</literal> calling convention. So, if we use
- <function>strcmp(a,b)</function> with <parameter>a</parameter>
+ <code language="c">strcmp(a,b)</code> with <parameter>a</parameter>
and <parameter>b</parameter> both 32-bit variables
<parameter>b</parameter> would be at <literal>[bp+6]</literal>
and <parameter>a</parameter> at <literal>[bp+10]</literal>.
@@ -713,7 +713,7 @@ retf XXXX <--------- XXXX is number of bytes of arguments
<para>
Most functions make also use of local storage in the stackframe:
</para>
- <programlisting>
+ <programlisting language="asm">
enter 0086, 00
... function code ...
leave
@@ -726,9 +726,9 @@ retf XXXX
function, arguments are pushed on the stack using something
like this:
</para>
- <programlisting>
-push word ptr [bp-02] <- will be at [bp+8]
-push di <- will be at [bp+6]
+ <programlisting language="asm">
+push word ptr [bp-02] <lineannotation><- will be at [bp+8]</lineannotation>
+push di <lineannotation><- will be at [bp+6]</lineannotation>
call KERNEL.LSTRLEN
</programlisting>
<para>
diff --git a/en/winedev-debugging.sgml b/en/winedev-debugging.sgml
index 9c895ef..dbcd192 100644
--- a/en/winedev-debugging.sgml
+++ b/en/winedev-debugging.sgml
@@ -14,7 +14,7 @@
and how you can control the debugging output. A picture is
worth a thousand words, so here are a few examples of the
debugging API in action:
- <programlisting>
+ <programlisting language="c">
ERR("lock_count == 0 ... please report\n");
FIXME("Unsupported RTL style!\n");
WARN(": file seems to be truncated!\n");
@@ -105,7 +105,7 @@ MESSAGE( "Could not create graphics driver '%s'\n", buffer );
and as such, there is only one channel to output to. You can declare
a default channel for the file using the
<systemitem class="macro">WINE_DEFAULT_DEBUG_CHANNEL()</systemitem> macro:
- <programlisting>
+ <programlisting language="c">
#include "wine/debug.h"
WINE_DEFAULT_DEBUG_CHANNEL(xxx);
@@ -123,7 +123,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(xxx);
debug channel per file. In such cases, you need to declare
all the additional channels at the top of the file, and
use the _-version of the debugging macros:
- <programlisting>
+ <programlisting language="c">
#include "wine/debug.h"
WINE_DEFAULT_DEBUG_CHANNEL(xxx);
@@ -399,7 +399,7 @@ where:
if you want to output the parameters of the function, do
it as the first thing and include them in parentheses,
like this:
- <programlisting>
+ <programlisting language="c">
TRACE("(%d, %p, ...)\n", <replaceable>par1</replaceable>, <parameter>par2</parameter>, ...);
</programlisting>
</para>
@@ -407,7 +407,7 @@ TRACE("(%d, %p, ...)\n", <replaceable>par1</replaceable>, <parameter>par2</param
<listitem>
<para>
if you want to name a parameter, use <literal>=</literal> :
- <programlisting>
+ <programlisting language="c">
TRACE("(fd=%d, file=%s): stub\n", <replaceable>fd</replaceable>, <replaceable>name</replaceable>);
</programlisting>
</para>
@@ -416,7 +416,7 @@ TRACE("(fd=%d, file=%s): stub\n", <replaceable>fd</replaceable>, <replaceable>na
<para>
for stubs, you should output a <literal>FIXME</literal>
message. I suggest this style:
- <programlisting>
+ <programlisting language="c">
FIXME("(%x, %d, ...): stub\n", <replaceable>par1</replaceable>, <replaceable>par2</replaceable>, ...);
</programlisting>
</para>
@@ -432,7 +432,7 @@ FIXME("(%x, %d, ...): stub\n", <replaceable>par1</replaceable>, <replaceable>par
<para>
if the output string needs to be dynamically constructed,
render it in memory before outputting it:
- <programlisting>
+ <programlisting language="c">
char buffer[128] = "";
if (flags & FLAG_A) strcat(buffer, "FLAG_A ");
diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml
index 4214834..958050b 100644
--- a/en/winedev-kernel.sgml
+++ b/en/winedev-kernel.sgml
@@ -184,7 +184,7 @@
the executable and then on this line:
</para>
- <programlisting>
+ <programlisting language="c">
ExitProcess( entry( peb ) );
</programlisting>
@@ -613,7 +613,7 @@ ExitProcess( entry( peb ) );
of the code to ensure that any held sections are left. Code like this:
</para>
- <programlisting>
+ <programlisting language="c">
if (res != ERROR_SUCCESS) return res;
</programlisting>
@@ -705,7 +705,7 @@ if (res != ERROR_SUCCESS) return res;
you see code like this:
</para>
- <programlisting>movl %esp, %fs:0</programlisting>
+ <programlisting language="asm">movl %esp, %fs:0</programlisting>
<para>
... then you are seeing the program set up an SEH handler frame. All
diff --git a/en/winedev-ole.sgml b/en/winedev-ole.sgml
index 4343ddf..5b58512 100644
--- a/en/winedev-ole.sgml
+++ b/en/winedev-ole.sgml
@@ -60,7 +60,7 @@
<para>
Let's take Direct3D as an example:
</para>
- <programlisting>#define ICOM_INTERFACE IDirect3D
+ <programlisting language="c">#define ICOM_INTERFACE IDirect3D
#define IDirect3D_METHODS \
ICOM_METHOD1(HRESULT,Initialize, REFIID,) \
ICOM_METHOD2(HRESULT,EnumDevices, LPD3DENUMDEVICESCALLBACK,, LPVOID,) \
@@ -169,7 +169,7 @@ ICOM_DEFINE(IDirect3D,IUnknown)
<para>
In C this gives:
</para>
- <programlisting>typedef struct IDirect3DVtbl IDirect3DVtbl;
+ <programlisting language="c">typedef struct IDirect3DVtbl IDirect3DVtbl;
struct IDirect3D {
IDirect3DVtbl* lpVtbl;
};
@@ -241,7 +241,7 @@ struct IDirect3DVtbl {
<para>
And in C++ (with <command>g++</command>):
</para>
- <programlisting>typedef struct IDirect3D: public IUnknown {
+ <programlisting language="cpp">typedef struct IDirect3D: public IUnknown {
private: HRESULT (*fnInitialize)(IDirect3D* me, REFIID a);
public: inline HRESULT Initialize(REFIID a) { return ((IDirect3D*)t.lpVtbl)->fnInitialize(this,a); };
private: HRESULT (*fnEnumDevices)(IDirect3D* me, LPD3DENUMDEVICESCALLBACK a, LPVOID b);
@@ -323,7 +323,7 @@ struct IDirect3DVtbl {
This continues the above example. This example assumes that
the implementation is in C.
</para>
- <programlisting>typedef struct _IDirect3D {
+ <programlisting language="c">typedef struct _IDirect3D {
void* lpVtbl;
// ...
} _IDirect3D;
diff --git a/en/winedev-opengl.sgml b/en/winedev-opengl.sgml
index 257a2a4..59bcbcb 100644
--- a/en/winedev-opengl.sgml
+++ b/en/winedev-opengl.sgml
@@ -280,7 +280,7 @@ Please report (lionel.ulmer at free.fr) !
<para>
create a dummy <filename class="extension">.c</filename> file:
</para>
- <programlisting>
+ <programlisting language="c">
int main(void)
{
return 0;
diff --git a/en/winedev-otherdebug.sgml b/en/winedev-otherdebug.sgml
index c753a8c..3ac92a5 100644
--- a/en/winedev-otherdebug.sgml
+++ b/en/winedev-otherdebug.sgml
@@ -12,24 +12,24 @@
thus, the operation of pushing a value onto the stack involves
decrementing <literal>esp</literal> and then moving the value into
the memory pointed to by <literal>esp</literal>
- (i.e., <literal>push p</literal> in assembly resembles
- <literal>*(--esp) = p;</literal> in C). Removing (popping)
- values off the stack is the reverse (i.e., <literal>pop p</literal>
- corresponds to <literal>p = *(esp++);</literal> in C).
+ (i.e., <code language="asm">push p</code> in assembly resembles
+ <code language="c">*(--esp) = p;</code> in C). Removing (popping)
+ values off the stack is the reverse (i.e., <code language="asm">pop p</code>
+ corresponds to <code language="c">p = *(esp++);</code> in C).
</para>
<para>
In the <literal>stdcall</literal> calling convention, arguments are
pushed onto the stack right-to-left. For example, the C call
- <userinput>myfunction(40, 20, 70, 30);</userinput> is expressed in
+ <code language="c">myfunction(40, 20, 70, 30);</code> is expressed in
Intel assembly as:
- <screen>
+ <programlisting language="asm">
push 30
push 70
push 20
push 40
call myfunction
- </screen>
+ </programlisting>
The called function is responsible for removing the arguments
off the stack. Thus, before the call to myfunction, the
stack would look like:
@@ -76,9 +76,9 @@
<para>
Another method that has been much more successful is to attempt to
figure out how many arguments each function is removing from the
- stack. This instruction, <userinput>ret <replaceable>hhll</replaceable></userinput> (where
- <replaceable>hhll</replaceable> is the number of bytes to remove, i.e. the
- number of arguments times 4), contains the bytes
+ stack. This instruction, <code language="asm">ret
+ <replaceable>hhll</replaceable></code> (where <replaceable>hhll</replaceable> is the number
+ of bytes to remove, i.e. the number of arguments times 4), contains the bytes
<literal>0xc2 <replaceable>ll</replaceable> <replaceable>hh</replaceable></literal> in
memory. It is a reasonable
assumption that few, if any, functions take more than 16 arguments;
@@ -90,11 +90,10 @@
<para>
Of course, this is not without errors.
- <literal>ret 00<replaceable>ll</replaceable></literal> is not the only instruction that can
- can have the byte sequence <literal>0xc2 <replaceable>ll</replaceable> 0x0</literal>; for
- example,
- <literal>push 0x000040c2</literal> has the byte sequence
- <literal>0x68 0xc2 0x40 0x0 0x0</literal>, which matches
+ <code language="asm">ret 00<replaceable>ll</replaceable></code> is not the only
+ instruction that can can have the byte sequence <literal>0xc2 <replaceable>ll</replaceable>
+ 0x0</literal>; for example, <code language="asm">push 0x000040c2</code> has the byte
+ sequence <literal>0x68 0xc2 0x40 0x0 0x0</literal>, which matches
the above. Properly, the utility should look for this sequence
only on an instruction boundary; unfortunately, finding
instruction boundaries on an i386 requires implementing a full
@@ -106,7 +105,7 @@
<para>
Much more troublesome is the non-linear flow of a function. For
example, consider the following two functions:
- <screen>
+ <programlisting language="asm">
<replaceable>somefunction1</replaceable>:
jmp <replaceable>somefunction1_impl</replaceable>
@@ -115,7 +114,7 @@
<replaceable>somefunction1_impl</replaceable>:
ret 0008
- </screen>
+ </programlisting>
In this case, we would incorrectly detect both
<function><replaceable>somefunction1</replaceable></function> and
<function><replaceable>somefunction2</replaceable></function> as taking only a single
@@ -278,12 +277,12 @@ less registry.c.gcov
</screen>
The interesting code part looks like this
in <filename>registry.c.gcov</filename>:
- <screen>
+ <programlisting language="c">
4: 1273: if (name && name[0]) /* need to create the subkey */
-: 1274: {
#####: 1275: if ((ret = RegCreateKeyW( hkey, name, &subkey )) != ERROR_SUCCESS) return ret;
-: 1276: }
- </screen>
+ </programlisting>
<command>gcov</command> output consists of three components:
the number of times a line was run, the line number, and the
actual text of the line. Note: If a line is optimized out by
@@ -292,12 +291,12 @@ less registry.c.gcov
<varname>name</varname> is never passed to the function.
In order to validate this line, we need to do two things.
First, we must write the test:
- <screen>
+ <programlisting language="c">
ret = RegSetValueW(hkey_main, name1W, REG_SZ, string1W, sizeof(string1W));
ok(ret == ERROR_SUCCESS, "RegSetValueW failed: %d, GLE=%d\n", ret, GetLastError());
test_hkey_main_Value_A(name1A, string1A, sizeof(string1A));
test_hkey_main_Value_W(name1W, string1W, sizeof(string1W));
- </screen>
+ </programlisting>
Once we add in this test case, we now want to know if the line
in question is run by this test and works as expected. You
should be in the same directory as in the previous command
@@ -322,12 +321,12 @@ less registry.c.gcov
The interesting code part looks like this in
<filename>registry.c.gcov</filename>:
</para>
- <screen>
+ <programlisting language="c">
5: 1273: if (name && name[0]) /* need to create the subkey */
-: 1274: {
1: 1275: if ((ret = RegCreateKeyW( hkey, name, &subkey )) != ERROR_SUCCESS) return ret;
-: 1276: }
- </screen>
+ </programlisting>
<para>
Based on gcov, we now know that line 1275 is executed once.
And since all of our other tests have remain unchanged, we
diff --git a/en/winedev-testing.sgml b/en/winedev-testing.sgml
index 8d4e1f3..5fec897 100644
--- a/en/winedev-testing.sgml
+++ b/en/winedev-testing.sgml
@@ -373,7 +373,7 @@ Kit</ulink>.
<listitem><para>
Copy some existing test from the Wine source tree, or
create your test program (say, <filename>mytest.c</filename>) using Notepad,
- being sure to begin it with <userinput>#include <wine/test.h></userinput>
+ being sure to begin it with <code language="c">#include <wine/test.h></code>
following the usual Wine test style.
</para></listitem>
<listitem><para>
@@ -410,7 +410,7 @@ Kit</ulink>.
</para>
<para>
A new test file will look something like the following:
-<programlisting>
+<programlisting language="c">
#include <wine/test.h>
#include <winbase.h>
@@ -443,7 +443,7 @@ START_TEST(paths)
<para>
You can use <function>trace</function> to print informational messages. Note
that these messages will only be printed if <userinput>runtest -v</userinput> is being used.
-<programlisting>
+<programlisting language="c">
trace("testing GlobalAddAtomA\n");
trace("foo=%d\n",foo);
</programlisting>
@@ -451,7 +451,7 @@ START_TEST(paths)
<para>
Then just call functions and use <function>ok</function> to make sure that
they behaved as expected:
-<programlisting>
+<programlisting language="c">
ATOM atom = GlobalAddAtomA( "foobar" );
ok( GlobalFindAtomA( "foobar" ) == atom, "could not find atom foobar\n" );
ok( GlobalFindAtomA( "FOOBAR" ) == atom, "could not find atom FOOBAR\n" );
@@ -487,7 +487,7 @@ START_TEST(paths)
<para>
So how do you write a good error message? Let's start with an example
of a bad error message:
-<programlisting>
+<programlisting language="c">
ok(GetThreadPriorityBoost(curthread,&disabled)!=0,
"GetThreadPriorityBoost Failed\n");
</programlisting>
@@ -505,7 +505,7 @@ thread.c:123: Test failed: GetThreadPriorityBoost Failed
</para>
<para>
Let's look at how to rewrite it:
-<programlisting>
+<programlisting language="c">
BOOL rc;
...
rc=GetThreadPriorityBoost(curthread,&disabled);
@@ -521,7 +521,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
When receiving such a message, one would check the source, see that
it's a call to <function>GetThreadPriorityBoost</function>, that the test failed not
because the API returned the wrong value, but because it returned an
- error code. Furthermore we see that <function>GetLastError()</function> returned
+ error code. Furthermore we see that <code language="c">GetLastError()</code> returned
<errorcode>120</errorcode> which <filename class="headerfile">winerror.h</filename> defines
as <errorname>ERROR_CALL_NOT_IMPLEMENTED</errorname>. So the source of
the problem is obvious: this Windows platform (here Windows 98) does
@@ -542,14 +542,14 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
result of an earlier computation, or comes from a large array of test
values (e.g. index 112 of <varname>_pTestStrA</varname> in <filename>vartest.c</filename>).
In that respect, for some tests you may want to define a macro such as the following:
-<screen>
+<programlisting language="c">
#define eq(received, expected, label, type) \
ok((received) == (expected), "%s: got " type " instead of " type "\n", (label),(received),(expected))
...
eq( b, curr_val, "SPI_{GET,SET}BEEP", "%d" );
-</screen>
+</programlisting>
</para>
</sect1>
@@ -568,7 +568,7 @@ thread.c:123: Test failed: rc=0 error=120 disabled=0
groups of checks can be declared as expected to fail on some of them.
In the most common case, one would declare a group of tests as
expected to fail in Wine. To do so, use the following construct:
-<programlisting>
+<programlisting language="c">
todo_wine {
SetLastError( 0xdeadbeef );
ok( GlobalAddAtomA(0) == 0 && GetLastError() == 0xdeadbeef, "failed to add atom 0\n" );
@@ -593,7 +593,7 @@ todo_wine {
So, if an API returns a different error code on Windows 9x and
Windows NT, your check should just verify that Wine returns one or
the other:
-<programlisting>
+<programlisting language="c">
ok ( GetLastError() == WIN9X_ERROR || GetLastError() == NT_ERROR, ...);
</programlisting>
</para>
diff --git a/en/winedev-windowing.sgml b/en/winedev-windowing.sgml
index d92e434..46c5843 100644
--- a/en/winedev-windowing.sgml
+++ b/en/winedev-windowing.sgml
@@ -22,11 +22,11 @@
window structure contains a pointer to the immediate
ancestor (parent window if <constant>WS_CHILD</constant>
style bit is set), a pointer to the sibling (returned by
- <function>GetWindow(..., GW_NEXT)</function>), a pointer
+ <code language="c">GetWindow(..., GW_NEXT)</code>), a pointer
to the owner window (set only for popup window if it was
created with valid <varname>hwndParent</varname>
parameter), and a pointer to the first child window
- (<function>GetWindow(.., GW_CHILD)</function>). All popup
+ (<code language="c">GetWindow(.., GW_CHILD)</code>). All popup
and non-child windows are therefore placed in the first
level of this hierarchy and their ancestor link
(<varname>wnd->parent</varname>) points to the desktop
@@ -469,7 +469,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
global handles <type>HACCEL16</type> and
<type>HACCEL32</type> by the Win16/Win32 API.
These are 5 bytes long, with no padding:
- <programlisting>
+ <programlisting language="c">
BYTE fVirt;
WORD key;
WORD cmd;
@@ -482,7 +482,7 @@ WORD cmd;
user only by direct accessing PE resources. These have a
size of 8 bytes:
</para>
- <programlisting>
+ <programlisting language="c">
BYTE fVirt;
BYTE pad0;
WORD key;
@@ -498,7 +498,7 @@ WORD pad1;
in the Win32 API.
These have a size of 6 bytes:
</para>
- <programlisting>
+ <programlisting language="c">
BYTE fVirt;
BYTE pad0;
WORD key;
@@ -546,7 +546,7 @@ WORD cmd;
<function>main_key_scan</function> table, which looks like
this:
</para>
- <programlisting>
+ <programlisting language="c">
static const int main_key_scan[MAIN_LEN] =
{
/* this is my (102-key) keyboard layout, sorry if it doesn't quite match yours */
@@ -623,7 +623,7 @@ static const char main_key_NO[MAIN_LEN][4] =
<varname>main_key_tab[]</varname> layout index table. This
will look like this:
</para>
- <programlisting>
+ <programlisting language="c">
static struct {
WORD lang, ansi_codepage, oem_codepage;
const char (*key)[MAIN_LEN][4];
--
1.8.4
More information about the wine-patches
mailing list