Index: include/config.php
===================================================================
RCS file: /home/wine/lostwages/include/config.php,v
retrieving revision 1.27
diff -u -p -r1.27 config.php
--- include/config.php 14 May 2005 05:59:06 -0000 1.27
+++ include/config.php 20 May 2005 03:24:43 -0000
@@ -52,7 +52,7 @@ class config
'Sending Patches' => '{$root}/site/sending_patches',
'To Do Lists' => '{$root}/site/todo_lists',
'Fun Projects' => '{$root}/site/fun_projects',
- 'Janitorial' => '{$root}/site/janitorial',
+ 'Janitorial' => 'http://wiki.winehq.org/JanitorialProjects',
'Winelib' => '{$root}/site/winelib',
'Status' => '{$root}/site/status',
'Resources' => '{$root}/site/resources'
--- templates/en/janitorial.template 2005-05-19 23:24:45.213346260 -0400
+++ /dev/null 2005-04-25 14:57:02.262484864 -0400
@@ -1,597 +0,0 @@
-
-
-
Janitorial Projects
-
- Any self respecting project has a Janitorial project
- (e.g. Kernel
- Janitor's List), and it's high time that we have one too.
- What is there to clean up? Well, lots of things! :)
-
- Regedit fixes
-
- Regedit lacks a few features. We need to improve regedit to:
-
- - Allow display and editing of binary (REG_BINARY) values.
-
- Allow display and editing of multi-string (REG_SZ_MULTI) values.
-
- Import registry files regerated by Windows 2000 regedit
-
-
-
-
Portability fixes
-
- Fix Wine to be compilable by a 64-bit compiler
-
- - Inspect and fix all public Win32 headers to match PSDK definitions.
-
- Make sure that pointers do not get truncated.
-
- Add support for Win64.
-
-
- Fix wrong assumptions in Wine about endianess
-
- - Inspect all Wine code and public headers to eliminate endianess dependent
- constructs (low/high parts of a field, bit fileds), add WORDS_BIGENDIAN
- when appropriate.
-
- Make sure that Wine code handles data in an endianess independent way.
-
-
- Code cleanup
-
- Some parts of Wine have become too big and complex to debug, and should
- be reworked into cleaner more readable code.
- One example is SHFileOperationW in dlls/shell32/shlfileop.c.
- This needs to be split into a number of smaller functions.
-
-
COM objects
-
- IClassFactory->CreateInstance aggregation check
-
- The CreateInstance method of IClassFactory takes pUnkOuter as the second
- member. This parameter must be null unless the class supports aggregation,
- which many don't. If the object the class factory creates doesn't support
- aggregation, pUnkOuter should be checked to make it is NULL.
-
- This usually means adding code like the following at the top of the
- factory's CreateInstance method:
-
- if( pUnkOuter )
- return CLASS_E_NOAGGREGATION;
-
-
-
- There appears to be quite a few COM object in which that is not done.
- See an example patch
- of how to fix this problem.
-
-
Implement DllCanUnloadNow and IClassFactory->LockServer
-
- COM objects that support activation as in-proc servers are implemented as
- DLLs. The COM specifies that these DLLs should provide an entry point
- named DllCanUnloadNow which returns true or false depending on whether
- the DLL is still in use or not. Many of Wine's COM objects stub that
- entrypoint to return TRUE always.
-
- To implement DllCanUnloadNow, a counter should be created to keep track of
- the number of active objects that use the DLL's code. Additionally
- LockServer(TRUE) should increment that counter by one and LockServer(FALSE)
- should decrement it by one.
-
- DLLs that appear to have this problem:
-
- - dlls/dmcompos/dmcompos_main.c
-
- dlls/dmusic/dmusic_main.c
-
- dlls/dmsynth/dmsynth_main.c
-
- dlls/dmband/dmband_main.c
-
- dlls/dswave/dswave_main.c
-
- dlls/dxdiagn/dxdiag_main.c
-
- dlls/msi/msi.c
-
- dlls/itss/itss.c
-
- dlls/olepro32/olepro32stubs.c
-
- dlls/dmime/dmime_main.c
-
- dlls/oleaut32/oleaut.c
-
- dlls/dpnhpast/main.c
-
- dlls/mlang/mlang.c
-
- dlls/dmscript/dmscript_main.c
-
- dlls/dsound/dsound_main.c
-
- dlls/dinput8/dinput8_main.c
-
- dlls/shdocvw/shdocvw_main.c
-
- dlls/dinput/dinput_main.c
-
- dlls/mpr/mpr_main.c
-
- dlls/urlmon/urlmon_main.c
-
- dlls/shell32/shell32_main.c
-
- dlls/ddraw/main.c
-
- dlls/dmstyle/dmstyle_main.c
-
-
- Tools
-
- Smatch
- From Michael Stefaniuc:
- Smatch (smatch.sourceforge.net)
- is basically a patch to gcc-3.1.1 that makes gcc dump out its
- internal representation of the code and a set of perl modules/scripts to
- ease the parsing of the dumped code. Most of the perl scripts are for
- the Linux Kernel but writing new scripts seems to be easy. I wrote
- (well, mostly adapted an existing script for the kernel)
- one script
- (if we decide to adopt smatch it should probably go to $wine/tools/smatch/)
- to find code paths with missing LeaveCriticalSection's. Scripts to find
- some other useful things like fd, DC, GDI obejects leaks should be easy to write.
- Update:
- There's a new web page
- about Wine and Smatch. It includes also a table with the bugs found by the smatch
- scripts. I could need a hand with the bugs (status BUG, UNKNOWN) cause I don't know
- how to fix them correctly (and for some locking BUG's I am not sure that they are
- real bugs).
-
-
Cross-calls that are Just Wrong (TM)
- The inspiration for the next two projects comes from our
- Perl hacker extraordinaire, Patrik
- Stridvall. More to the point, a while ago Dimi asked him,
- "...what would it take to add checks for calls to 16bit funcs from 32bit
- funcs, and from Unicode funcs to ANSI funcs?"
- He promptly replied: "It is already done. Years ago. :-)"
-
- Get rid of W->A calls
- We should not call ASCII functions from Unicode functions.
- The ASCII to Unicode conversion is lossy; moreover, with the
- shift to Unicode, it's actually slower to deal in ASCII than
- in Unicode, because of the additional conversions required.
- There are 40 cross calls from Unicode to ANSI as reported by
- tools/winapi_check/winapi_check --none --progress --cross-call-unicode-ascii
- (as of Jan 11, 2005):
-
- - dlls/advapi32/crypt.c: advapi32: CryptAcquireContextW: illegal call to CryptAcquireContextA
-
- dlls/advapi32/crypt.c: advapi32: CryptEnumProviderTypesW: illegal call to CryptEnumProviderTypesA
-
- dlls/advapi32/crypt.c: advapi32: CryptGetDefaultProviderW: illegal call to CryptGetDefaultProviderA
-
- dlls/advapi32/crypt.c: advapi32: CryptSetProviderExW: illegal call to CryptSetProviderExA
-
- dlls/ddraw/main.c: ddraw: DirectDrawEnumerateExW: illegal call to DirectDrawEnumerateExA
-
- dlls/hhctrl.ocx/hhctrl.c: hhctrl.ocx: HtmlHelpW: illegal call to MessageBoxA
-
- dlls/kernel/resource.c: kernel32: FindResourceExW: illegal call to get_res_name_type_WtoA
-
- dlls/lzexpand/lzexpand_main.c: lz32: GetExpandedNameW: illegal call to GetExpandedNameA
-
- dlls/lzexpand/lzexpand_main.c: lz32: LZOpenFileW: illegal call to LZOpenFileA
-
- dlls/rpcrt4/rpc_binding.c: rpcrt4: RPCRT4_CreateBindingW: illegal call to RPCRT4_strdupWtoA
-
- dlls/rpcrt4/rpc_binding.c: rpcrt4: RPCRT4_CompleteBindingW: illegal call to RPCRT4_strdupWtoA
-
- dlls/rpcrt4/rpc_binding.c: rpcrt4: RPCRT4_CompleteBindingW: illegal call to RPCRT4_strndupA
-
- dlls/rpcrt4/rpc_binding.c: rpcrt4: RpcBindingToStringBindingW: illegal call to RpcBindingToStringBindingA
-
- dlls/rpcrt4/rpc_binding.c: rpcrt4: RpcBindingToStringBindingW: illegal call to RpcStringFreeA
-
- dlls/rpcrt4/rpc_server.c: rpcrt4: RpcServerUseProtseqEpExW: illegal call to RPCRT4_strdupWtoA
-
- dlls/shell32/shellole.c: shell32: DragQueryFileW: illegal call to DragQueryFileA
-
- dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to Shell_NotifyIconA
-
- dlls/shlwapi/ordinal.c: shlwapi: SHCreateWorkerWindowW: illegal call to SHCreateWorkerWindowA
-
- dlls/shlwapi/string.c: shlwapi: StrRetToStrW: illegal call to SHStrDupA
-
- dlls/version/install.c: version: VerInstallFileW: illegal call to VerInstallFileA
-
- dlls/wininet/internet.c: wininet: InternetCheckConnectionW: illegal call to InternetCheckConnectionA
-
- dlls/winmm/mmio.c: winmm: mmioRenameW: illegal call to mmioRenameA
-
- dlls/winmm/mmio.c: winmm: mmioStringToFOURCCW: illegal call to mmioStringToFOURCCA
-
- dlls/winsock/socket.c: winsock: WSAStringToAddressW: illegal call to WSAStringToAddressA
-
- dlls/winspool/info.c: winspool.drv: AddPrinterW: illegal call to DEVMODEdupWtoA
-
- dlls/winspool/info.c: winspool.drv: AddPrinterW: illegal call to RegSetValueExA
-
- dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to DEVMODEdupWtoA
-
- dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to DeviceCapabilitiesA
-
- dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to HEAP_strdupWtoA
-
- dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to DEVMODEdupWtoA
-
- dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to DocumentPropertiesA
-
- dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to HEAP_strdupWtoA
-
- dlls/winspool/info.c: winspool.drv: OpenPrinterW: illegal call to RegCreateKeyA
-
- programs/winedbg/winedbg.c: winedbg: dbg_outputW: illegal call to dbg_outputA
-
- windows/winhelp.c: user32: WinHelpW: illegal call to WinHelpA
-
- windows/winproc.c: user32: CallWindowProcW: illegal call to WINPROC_CallProc32WTo32A
-
-
- Please note that patches have been submitted for the italic entries;
- the grayed out entries have already been fixed.
-
- - workers: Rolf Kalbermatter,
- Stefan Leichter,
- Matthew Davison,
- Tony Lambregts,
- Dmitry Timoshkov,
- Eric Pouech,
- Alexandre Julliard,
- Justin Chevrier,
- Ulrich Czekalla,
- Mike McCormack,
- Juan Lang,
- Kevin Koltzau,
- James Hawkins,
- Filip Navara,
- Jacek Caban.
-
- status: Over 3/4 done.
-
- updated: Jan 11, 2004
-
-
- DLL separation: Phase 2
- Eliminate temporary hacks form the .spec files:
-
- - ntdll.MODULE_DllThreadAttach(): kernel
-
- ntdll.MODULE_GetLoadOrderW(): kernel
-
- ntdll.VERSION_Init(): kernel
-
- kernel32.DOSMEM_AllocSelector(): winedos
-
- kernel32.DOSMEM_Available(): winedos
-
- kernel32.DOSMEM_FreeBlock(): winedos
-
- kernel32.DOSMEM_GetBlock(): winedos
-
- kernel32.DOSMEM_Init(): winedos
-
- kernel32.DOSMEM_ResizeBlock(): winedos
-
- kernel32.LOCAL_Alloc(): gdi, user
-
- kernel32.LOCAL_Compact(): gdi
-
- kernel32.LOCAL_CountFree(): gdi
-
- kernel32.LOCAL_Free(): gdi, user
-
- kernel32.LOCAL_HeapSize(): gdi, user
-
- kernel32.LOCAL_Lock(): gdi, user
-
- kernel32.LOCAL_ReAlloc(): gdi, user
-
- kernel32.LOCAL_Size(): user
-
- kernel32.LOCAL_Unlock(): gdi, user
-
- kernel32.NE_DefResourceHandler(): user
-
- gdi32.CloseJob16(): wineps
-
- gdi32.DrvGetPrinterData16(): wineps
-
- gdi32.DrvSetPrinterData16(): wineps
-
- gdi32.OpenJob16(): wineps
-
- gdi32.SelectVisRgn16(): wineps, ttydrv, x11drv
-
- gdi32.SetDCHook(): x11drv
-
- gdi32.SetHookFlags16(): ttydrv, x11drv
-
- gdi32.WriteSpool16(): wineps
-
- gdi32.DIB_CreateDIBSection(): ddraw
-
- gdi32.GDI_GetObjPtr(): x11drv
-
- gdi32.GDI_ReleaseObj(): x11drv
-
- user32.CallWindowProc16(): commdlg
-
- user32.CloseDriver16(): winmm
-
- user32.CreateDialogIndirectParam16(): commdlg
-
- user32.DefDriverProc16(): winmm
-
- user32.DefWindowProc16(): ctl3d
-
- user32.DestroyIcon32(): kernel
-
- user32.DialogBoxIndirectParam16(): commdlg
-
- user32.GetDriverModuleHandle16(): winmm
-
- user32.OpenDriver16(): winmm
-
- user32.SendDriverMessage16(): winmm
-
- user32.UserYield16(): winmm
-
- user32.HOOK_CallHooks(): ttydrv, x11drv
-
- user32.USER_Unlock(): x11drv
-
- user32.WINPOS_ActivateOtherWindow(): ttydrv, x11drv
-
- user32.WINPOS_GetMinMaxInfo(): x11drv
-
- user32.WINPOS_ShowIconTitle(): ttydrv, x11drv
-
- user32.WIN_GetPtr(): ttydrv, x11drv
-
- user32.WIN_SetStyle(): x11drv
-
-
-
- Stick to the Win32 API
- There are many reasons why we should use the Win32 API as much
- as possible inside Wine, rather than our own, ad-hoc API. Here are a few:
-
- - The Win32 API is documented, and understood by many people
-
- It is always available, so introducing additional APIs only increases confusion
-
- The Win32 API gets a lot more testing as it is used more.
-
- This can go on, and on, but I think the point is clear. The following tasks
- fall into this category.
-
- Getting rid of the global
- HEAP_strdupWtoA function
- As of Jan 9, 2005, there were 11 occurrences of HEAP_strdupWtoA.
- These functions invocations should go away during the W -> A cross-call
- cleanup. It is better to directly fix that sort of cross call, rather than
- replace this function by other alternatives. The few of them that can not
- be eliminated this way, should be replaced by calls to WideCharToMultiByte.
- find dlls -name \*.c -exec grep -q HEAP_strdupWtoA {} \; -ls
-
- - dlls/winspool/info.c
-
- dlls/wineps/escape.c
-
- dlls/wineps/init.c
-
- When these are finally removed, we can get rid of the non-standard include
- file heap.h.
-
-
Include file cleanup
- That is, no more Wine-specific headers in include/. This is tightly
- related to the DLL Separation task, listed above. There are 11 Wine-only
- headers that need to be moved:
-
- - builtin16.h
-
- cursoricon.h
-
- dciddi.h
-
- gdi.h
-
- heap.h
-
- local.h
-
- miscemu.h
-
- module.h
-
- stackframe.h
-
- thread.h
-
- winpos.h
-
-
-
- Remove non-standard directories
- There is only 1 directory left that does not fit into the current organization.
- It is a historical remnants of a troubled past, and it needs to go.
- This is tightly linked to the DLL Separation task, listed above.
-
-
- - workers: Alexandre Julliard.
-
- status: first patches committed.
-
- updated: Apr 20, 2005
-
-
- Compile Wine with other headers
- We have at least two other Win32 headers available: MSVC, and MinGW (w32api).
- In a perfect world, we should be able to build Wine using either of them.
- This will be a very effective way of discovering problems in our own
- headers, as the compiler will signal mismatches in function signatures, etc.
-
- - workers: Steven Edwards.
-
- status: first patches committed.
-
- updated: Aug 30, 2003
-
-
- Miscellaneous
-
- Check www.winehq.org against the W3 HTML validator
-
- It's good practice to keep our website W3 compliant. The
- W3 HTML validator can
- check a site's HTML for conformance to the W3C recommendations.
-
- If you find errors on the website, you can
- submit patches
- against the lostwages
- module in the Wine CVS to wine-patches with the subject
- starting with "LOSTWAGES:".
-
-
Use Compiler Warnings to Fix Errors
- Having gcc print out some warnings could isolate some problems. There are
- at least three different ones that we should investigate:
-
-
- - -Wmissing-declarations
- should point lots of missing APIs declarations
- (Eric has done it in some cases, and is in the process of submitting some
- fixes). We cannot turn this warning always on because there are lots of
- cases where we have global functions without prototypes (more than 2/3
- of them are made out of the 16bit entry points)
-
- - -Wwrite-strings
- There has already been quite some work on this, but we think there's
- more to do.
-
- - -Wcast-qual
- should point out all the (const bla*) => (foo*) casts. We
- use quite a bit this, and in some cases it would prevent some errors.
- These are the main cases pointed out by this warning:
-
- - const void* ptr; and then reading a value from ptr (word...) like
- *(WORD*)ptr which should be written *(const WORD*). The warning in this
- case is harmless.
-
- - const void* ptr; and then setting it to another const pointer: const
- WORD* pw = (WORD*)ptr; which should be written pw = (const WORD*)ptr;.
- This warning is harmless if pw is really defined as const, in some cases
- it isn't and this should be fixed.
-
- - const void* ptr; and then setting it to a pointer to a pointer (used
- a lot for qsort/bsearch... callbacks), when dealing with arrays of
- pointers. Here again, what's const is the first pointer, so const foo* f
- = *(const foo**)ptr is wrong, it should be const foo* f = (const foo*
- const*)ptr; This could be harmfull if not declared properly.
- Unfortunately, we cannot turn this warning on all the time because some
- C functions implementation would always trigger it (strstr for example),
- unless we use intergral values (not pointer) to cast from the const
- char* to the returned char*), and this is uglier IMO than the warning we
- try to avoid.
-
- - -Wsign-compare
- Turns up a load of warnings, most of which can be fixed by choosing
- correct variable types.
-
-
- This project was suggested by Eric Pouech and Francois Gouget.
- For more information contact them directly or
- the wine-devel mailing list.
-
- - workers: Hans Leidekker (on -Wsign-compare)
-
- status: TODO
-
- updated: May 21, 2004
-
-
-
- Fix min/max macros
- From Francois Gouget: "Patch our min/max macros to catch
- signed/unsigned comparisons. This generates a lot of warnings. Ideally
- they should be fixed without using casts but it may not always be possible.
- (the modified min/max macros where borrowed from a Linux kernel patch)"
-
- - workers: wanted
-
- status: TODO
-
- updated: May 21, 2004
-
-
-
- Replace DPRINTFs with TRACEs where possible
- Currently, the debug layer is smart enough to concatenate consecutive
- TRACE statements if they don't end with a new line. As such,
- we can replace most DPRINTF statements with TRACEs.
- The conversion is mostly mechanical, but must be checked manually
- to watch for potential simplifications that may be possible with the
- new scheme.
-
-
-
- Make winegcc link automatically to a main() or a WinMain()
- From Alexandre: The easiest is with some sort of crt0 static library that provides
- main() if it's missing; you have a main() that basically calls WinMain(), compiled
- inside a .a library. At link time if you have a main() already the linker doesn't use
- the .a, otherwise it uses it. crt0 is the default C startup code, currently we generate
- it inside the spec file directly but it would be cleaner to have a separate crt0.o file;
- it's also needed if we want full msvcrt compatibility. We need at least a crt0.o to call
- main(), and another .o providing the default main(). There may also be a need to handle
- msvcrt specially (i.e. link another .a in msvcrt mode), so that we call exit() when
- linked to msvcrt instead of calling ExitProcess() as we normally do.
- From Dimi: So, let's say we'll create a winecrt0-glibc.a and a winecrt0-msvcrt.a,
- and in winegcc we assume that they are there, so we can just list the appropriate one
- as the last element on the linker command line.
-
- - workers: wanted
-
- status: TODO.
-
- updated: Aug 7, 2004
-
-
- Fix the conformance tests so that they pass on Windows
- Entry submitted by Francois Gouget.
-
- Volunteers who will run the tests their Windows platform of choice on a
- regular basis so that we quickly fix incorrect tests
-
-
- Completed Projects
-
- Several janitorial projects have been completed in the past and we'd
- like to thank everyone who pitched in. Just in case you're wondering
- what we've done, the list is preserved below:
-
-
Compilation with -DSTRICT
- Please refer to Bug
- #90 for more information on this project.
-
- - workers: Michael Stefaniuc, Andrew John Hughes, Johan Dahlin, Alexandre Julliard
-
- completed: Nov 22, 2002
-
-
- HEAP_strdupAtoW
- These should be changed to MultiByteToWideChar,
- or even better to RtlCreateUnicodeStringFromAsciiz.
-
- - workers: Matthew Davison
-
- completed: Jan 27, 2003
-
-
- Get rid of 32->16 calls
- We should not call 16 bit from 32 bit code. With the ongoing 16-bit
- separation, this is even more so important.
-
- - workers: Andrew John Hughes
-
- completed: Jan 31, 2003
-
-
- Include statements should use <> instead of ""
- Wine uses "" in most of it #include statements for historical
- reasons that are no longer an issue. It needs to be changed to use
- <> instead. We will keep the quotes in the .c-files, as an indication
- that the header is a Wine header, rather than a system header. For header
- files we don't have this luxury as they can cause problems for Winelib developpers.
-
- - workers: Dimitrie O. Paun
-
- completed: Aug 30, 2003
-
-
- Header dependencies cleanup
- From Alexandre: ...most of our headers are including way
- too much stuff compared to what Windows does. It should be possible to
- generate a dependency tree of our headers with makedep and compare
- that with one done with the Windows headers; the goal is to make them
- identical.
-
- - workers: Alexandre Julliard
-
- completed: Sep 9, 2003
-
-
- DLL separation: Phase 1
- DLLs make use of only the functions exported through the .spec files.
-
- - workers: Alexandre Julliard
-
- completed: Feb 7, 2004
-
-
- Fix HeapReAlloc/RtlReAllocateHeap() calls
- From Eric: there's lot of code which relies on HeapReAlloc would allocate
- a block if the block to reallocate is NULL (as realloc does in stdlib);
- this is not the case in windows, and we should fix it (and first, fix
- all the Wine code relying on this)
-
- - workers: Oleg Prokhorov, Dimitrie O. Paun
-
- completed: Mar 10, 2004
-
-
- Use Interlocked functions in AddRef and Release methods
-
- Most OLE objects should be threadsafe, which requires use of the thread-safe
- increment and decrement functions InterlockedIncrement(&This->ref)
- and InterlockedDecrement(&This->ref) instead of This->ref++
- or This->ref--. See an example
- patch
- of how to fix this problem.
-
- To be consistent, references to This->ref in TRACE's should be
- avoided as well.
-
-
- - workers: James Hawkins, Joris Huizer, Paul Vriens
-
- completed: Jan 25, 2005
-
-
- Remove HeapAlloc casts
-
- Casting the return value of HeapAlloc and HeapReAlloc is unnecessary,
- and should be avoided. All existing casts can be removed. You can
- find them using:
-
- find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc"
-
- As of the 23rd March 2005, there's 262 of these to be removed.
-
-
- - workers: Jacob Ericson (completed in one day!)
-
- completed: Mar 25, 2005
-
-
- Check the usage of strncpy/strncpyW
-
- strncpy(dst,src,n) has two subtle
-
- problems. The first is that it always fills the whole dst
- buffer (n characters). The second is that it doesn't always nul
- terminate the dst buffer that it's filling.
-
- Wine code should avoid the use of strncpy for these reasons, and instead
- use lstrcpynA/W or memcpy. You can use the following command to find
- occurrences of strncpy in the Wine source code:
-
- find . -name \*.c -exec grep strncpy {} \; -ls
-
- The aim is to make sure that we only copy as many bytes as necessary into
- the dst buffer, and always nul terminate the buffer when we
- intended to.
-
- Julliard
- says:
- "A careful review of the code to ensure that lstrcpyn semantics are really what
- we want. In several cases we know that we are copying less than the full string,
- and in that case we have to use memcpy instead, lstrcpyn won't do the right
- thing."
-
-
- - workers: Peter Berg Larsen, Alexandre Julliard
-
- completed: Apr 21, 2005
-
-
-