Ros-dev July 2005

ros-dev@reactos.org

59 participants
100 discussions

RE: [ros-svn] [sedwards] 16887: dos line endings

by Casper Hornstrup

Put svn:eol-style = native on them, then the svn client will take care of it: svn propset -R svn:eol-style "native" dosfsck Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of > sedwards(a)svn.reactos.com > Sent: 30. juli 2005 01:04 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [sedwards] 16887: dos line endings > > dos line endings > > > Updated files: > trunk/rosapps/sysutils/dosfsck/boot.c > trunk/rosapps/sysutils/dosfsck/boot.h > trunk/rosapps/sysutils/dosfsck/byteorder.h > trunk/rosapps/sysutils/dosfsck/byteswap.h > trunk/rosapps/sysutils/dosfsck/byteswap1.h > trunk/rosapps/sysutils/dosfsck/check.c > trunk/rosapps/sysutils/dosfsck/check.h > trunk/rosapps/sysutils/dosfsck/common.c > trunk/rosapps/sysutils/dosfsck/common.h > trunk/rosapps/sysutils/dosfsck/compiler.h > trunk/rosapps/sysutils/dosfsck/dosfsck.c > trunk/rosapps/sysutils/dosfsck/dosfsck.h > trunk/rosapps/sysutils/dosfsck/fat.c > trunk/rosapps/sysutils/dosfsck/fat.h > trunk/rosapps/sysutils/dosfsck/file.c > trunk/rosapps/sysutils/dosfsck/file.h > trunk/rosapps/sysutils/dosfsck/getopt.c > trunk/rosapps/sysutils/dosfsck/io.c > trunk/rosapps/sysutils/dosfsck/io.h > trunk/rosapps/sysutils/dosfsck/lfn.c > trunk/rosapps/sysutils/dosfsck/lfn.h > trunk/rosapps/sysutils/dosfsck/msdos_fs.h > trunk/rosapps/sysutils/dosfsck/swab.h > trunk/rosapps/sysutils/dosfsck/version.h > trunk/rosapps/sysutils/dosfsck/vfat.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

19 years, 11 months

Wallpaper and Registry Keys

by James Tabor

Hi all! In Mastering, Win 2K Registry, Sybex books, Pages 282-285. We need some registry fixup to save the wallpaper. HKEY_USERS\.DEFAULT\Control Panel\Desktop, entry Wallpaper, type REG_SZ and value: fully qualified bitmap image filename, entry WallpaperStyle, type REG_SZ and value: 0, entry TileWallpaper, type REG_SZ and value: 0, and on... Same with Mastering, Win XP Registry, Sybex books, Pages 230-231, nothing changed. Is there a problem with implementing some of these? What was the show stopper? Thanks, James

19 years, 11 months

USB mouse support

by Jonathan Wilson

How far away is support for USB mice?

19 years, 11 months

RE: [ros-svn] [gdalsnes] 16793: my 1st

by Murphy, Ged (Bolton)

gdalsnes(a)svn.reactos.com wrote: > my 1st > > > Added files: > branches/hardons1stbranch/ > > Updated files: > branches/hardons1stbranch/kapi.h branches/hardons1stbranch/ntuser.h > > Deleted files: > branches/hardons1stbranch/debug.h branches/hardons1stbranch/debug1.h Hi Hardon. Out of interest, what's the purpose of this branch? (probably been discussed in IRC, but I missed it) Thanks, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 11 months

Re: [ros-dev] RE: [ros-svn] [gdalsnes] 16793: my 1st

by ayerkes＠speakeasy.net

> -----Original Message----- > From: Richard [mailto:eek2121@comcast.net] > Sent: Friday, July 29, 2005 12:18 AM > To: 'ReactOS Development List' > Subject: Re: [ros-dev] RE: [ros-svn] [gdalsnes] 16793: my 1st > > Then where is this effort? Why is one developer wandering off on his > own? How about setting a 'win32k rewrite' as a goal for 0.4? That is, > if 0.3 ever makes it out the door... > > Honestly, i think that devs should work towards the feature set we > planned for 0.3, however that is just me. Granted, there is no money > involved in this project, but not setting goals and randomly doing > rewrites is the fast way to code burnout, boredom, and lost interest. > Drowning yourself in an impossibly large project is nuts. > > Richard Not meeting 0.3 is largely my fault. I don't even know when I'll be able to return to writing on it in a consistent way, given my new job :-(. I've had several offers from others to write on it but it seems that most people either aren't very interested in what remains, or don't feel confident about working on kernel code. The remaining kernel tasks don't actually involve much know-how about the kernel, and my components are designed to be easy to understand (with minimal concurrency). Only three things are needed to meet the 0.3 goal: 1) retest apps on the 0.3 list and fix regressions 2) finish the net cpl and possibly fix bugs in npfs that make CallNamedPipe bugcheck 3) (big) finish needed stuff for mozilla compatibility There are a lot of generic tasks in net that need doing, and could really be done by anybody. They affect the kernel but won't use very much specific kernel code: 1) Plumb remaining ioctls into kernel land (afd/info.c,tcpip/*info.c) - Keepalive - Nagle - TTL (datagram and tcp) - Verify behavior of nonblocking sockets - send/rcv buf 2) Plumb ARP cache requests (tcpip/iinfo.c,network/neighbor.c) 3) Put together a test matrix for socket end conditions (when I get my stuff from chicago next saturday, I'll be able to pass on my test apps and notes), and emulate winsock properly. 4) Finish the NTSTATUS -> winsock error conversion and use it everywhere 5) Finish off errno -> NTSTATUS conversion in tcp.c 6) Finish any kernel-related IOCTL changes 7) Write a test tool and verify WSAEnumNetworkEvents 8) Do some refactoring in afd/select.c to make it easier to understand Hard kernely tasks: 1) Fix IRP cancellation in tcpip 2) Verify CLOSE/CLEANUP in afd and tcpip 3) Better buffer management in afd 4) Fix use of TDI_TRANSPORT_ADDRESS vs TA_ADDRESS and verify correctness based on osr docs 5) Test out our AFD and TCPIP on real windows with kd 6) Replace recursive mutex

19 years, 11 months

Re: [ros-svn] [ion] 16811: - Fix debug header nonsense

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Fix debug header nonsense > - Fix some w32api definitions > - MSVC/PSDK Compatibility fixes. > - Clean up user32 headers for greater PCH usage. > > >Added files: >trunk/reactos/lib/user32/include/controls.h >trunk/reactos/lib/user32/include/dde_private.h >trunk/reactos/w32api/include/winnls32.h > >Updated files: >trunk/reactos/apps/utils/ps/ps.c >trunk/reactos/drivers/dd/mpu401/settings.c >trunk/reactos/include/reactos/debug.h >trunk/reactos/include/wine/debug.h >trunk/reactos/lib/ntdll/inc/ntdll.h >trunk/reactos/lib/user32/controls/button.c >trunk/reactos/lib/user32/controls/combo.c >trunk/reactos/lib/user32/controls/edit.c >trunk/reactos/lib/user32/controls/icontitle.c >trunk/reactos/lib/user32/controls/listbox.c >trunk/reactos/lib/user32/controls/scrollbar.c >trunk/reactos/lib/user32/include/user32.h >trunk/reactos/lib/user32/include/user32p.h >trunk/reactos/lib/user32/misc/dde.c >trunk/reactos/lib/user32/misc/ddeclient.c >trunk/reactos/lib/user32/misc/ddeserver.c >trunk/reactos/lib/user32/misc/display.c >trunk/reactos/lib/user32/misc/dllmain.c >trunk/reactos/lib/user32/misc/exticon.c >trunk/reactos/lib/user32/misc/object.c >trunk/reactos/lib/user32/misc/stubs.c >trunk/reactos/lib/user32/windows/bitmap.c >trunk/reactos/lib/user32/windows/clipboard.c >trunk/reactos/lib/user32/windows/cursor.c >trunk/reactos/lib/user32/windows/defwnd.c >trunk/reactos/lib/user32/windows/dialog.c >trunk/reactos/lib/user32/windows/draw.c >trunk/reactos/lib/user32/windows/font.c >trunk/reactos/lib/user32/windows/hook.c >trunk/reactos/lib/user32/windows/icon.c >trunk/reactos/lib/user32/windows/input.c >trunk/reactos/lib/user32/windows/mdi.c >trunk/reactos/lib/user32/windows/menu.c >trunk/reactos/lib/user32/windows/message.c >trunk/reactos/lib/user32/windows/messagebox.c >trunk/reactos/lib/user32/windows/nonclient.c >trunk/reactos/lib/user32/windows/paint.c >trunk/reactos/lib/user32/windows/window.c >trunk/reactos/w32api/include/winuser.h > >Deleted files: >trunk/reactos/lib/user32/controls/controls.h >trunk/reactos/lib/user32/include/debug.h >trunk/reactos/lib/user32/misc/dde_private.h > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Please revert the changes in include/wine/debug.h. Your changes enables the TRACE and WARN statements for all wine dlls. The debug messages are no longer useful, because the output is flooded with thausends of unwanted messages. - Hartmut

19 years, 11 months

Please commit these patches

by Saveliy Tretiakov

I sent this to ros-dev about 3 months ago but nobody commited. ChangeLog: Correct return values. Fix suggested by w3seek. Index: misc/comm.c =================================================================== --- misc/comm.c (revision 16707) +++ misc/comm.c (working copy) @@ -834,7 +834,7 @@ CommConfigDialogA(LPCSTR lpszName, HWND hWnd, LPCOMMCONFIG lpCC) { PWCHAR NameW; - BOOL result; + DWORD result; /* don't use the static thread buffer so operations in serialui don't overwrite the string */ @@ -858,9 +858,9 @@ STDCALL CommConfigDialogW(LPCWSTR lpszName, HWND hWnd, LPCOMMCONFIG lpCC) { - BOOL (STDCALL *drvCommDlgW)(LPCWSTR, HWND, LPCOMMCONFIG); + DWORD (STDCALL *drvCommDlgW)(LPCWSTR, HWND, LPCOMMCONFIG); HMODULE hSerialuiDll; - BOOL result; + DWORD result; //FIXME: Get dll name from registry. (setupapi needed) if(!(hSerialuiDll = LoadLibraryW(L"serialui.dll"))) @@ -869,7 +869,8 @@ return FALSE; } - drvCommDlgW = GetProcAddress(hSerialuiDll, "drvCommConfigDialogW"); + drvCommDlgW = (DWORD (STDCALL *)(LPCWSTR, HWND, LPCOMMCONFIG)) + GetProcAddress(hSerialuiDll, "drvCommConfigDialogW"); if(!drvCommDlgW) { @@ -879,8 +880,10 @@ } result = drvCommDlgW(lpszName, hWnd, lpCC); + SetLastError(result); FreeLibrary(hSerialuiDll); - return result; + + return (result == ERROR_SUCCESS ? TRUE : FALSE); } Index: serialui.h =================================================================== --- serialui.h (revision 16707) +++ serialui.h (working copy) @@ -11,8 +11,7 @@ #include "resource.h" #define UNIMPLEMENTED \ - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); \ - return FALSE; + return ERROR_CALL_NOT_IMPLEMENTED ; #define DEFAULT_BAUD_INDEX 6 #define DEFAULT_BYTESIZE_INDEX 3 @@ -45,27 +44,27 @@ * ************************************/ -BOOL WINAPI drvCommConfigDialogW(LPCWSTR lpszDevice, +DWORD WINAPI drvCommConfigDialogW(LPCWSTR lpszDevice, HWND hWnd, LPCOMMCONFIG lpCommConfig); -BOOL WINAPI drvCommConfigDialogA(LPCSTR lpszDevice, +DWORD WINAPI drvCommConfigDialogA(LPCSTR lpszDevice, HWND hWnd, LPCOMMCONFIG lpCommConfig); -BOOL WINAPI drvSetDefaultCommConfigW(LPCWSTR lpszDevice, +DWORD WINAPI drvSetDefaultCommConfigW(LPCWSTR lpszDevice, LPCOMMCONFIG lpCommConfig, DWORD dwSize); -BOOL WINAPI drvSetDefaultCommConfigA(LPCSTR lpszDevice, +DWORD WINAPI drvSetDefaultCommConfigA(LPCSTR lpszDevice, LPCOMMCONFIG lpCommConfig, DWORD dwSize); -BOOL WINAPI drvGetDefaultCommConfigW(LPCWSTR lpszDevice, +DWORD WINAPI drvGetDefaultCommConfigW(LPCWSTR lpszDevice, LPCOMMCONFIG lpCommConfig, LPDWORD lpdwSize); -BOOL WINAPI drvGetDefaultCommConfigA(LPCSTR lpszDevice, +DWORD WINAPI drvGetDefaultCommConfigA(LPCSTR lpszDevice, LPCOMMCONFIG lpCommConfig, LPDWORD lpdwSize); Index: serialui.c =================================================================== --- serialui.c (revision 16707) +++ serialui.c (working copy) @@ -98,7 +98,7 @@ /* * @implemented */ -BOOL WINAPI drvCommConfigDialogW(LPCWSTR lpszDevice, +DWORD WINAPI drvCommConfigDialogW(LPCWSTR lpszDevice, HWND hWnd, LPCOMMCONFIG lpCommConfig) { @@ -106,7 +106,7 @@ if(!lpszDevice || !lpCommConfig) { - return FALSE; + return ERROR_INVALID_PARAMETER; } DialogInfo.lpszDevice = lpszDevice; @@ -119,7 +119,7 @@ /* * @implemented */ -BOOL WINAPI drvCommConfigDialogA(LPCSTR lpszDevice, +DWORD WINAPI drvCommConfigDialogA(LPCSTR lpszDevice, HWND hWnd, LPCOMMCONFIG lpCommConfig) { @@ -136,13 +136,13 @@ return result; } else - return FALSE; + return ERROR_NOT_ENOUGH_MEMORY; } /* * @unimplemented */ -BOOL WINAPI drvSetDefaultCommConfigW(LPCWSTR lpszDevice, +DWORD WINAPI drvSetDefaultCommConfigW(LPCWSTR lpszDevice, LPCOMMCONFIG lpCommConfig, DWORD dwSize) { @@ -152,7 +152,7 @@ /* * @unimplemented */ -BOOL WINAPI drvSetDefaultCommConfigA(LPCSTR lpszDevice, +DWORD WINAPI drvSetDefaultCommConfigA(LPCSTR lpszDevice, LPCOMMCONFIG lpCommConfig, DWORD dwSize) { @@ -162,7 +162,7 @@ /* * @unimplemented */ -BOOL WINAPI drvGetDefaultCommConfigW(LPCWSTR lpszDevice, +DWORD WINAPI drvGetDefaultCommConfigW(LPCWSTR lpszDevice, LPCOMMCONFIG lpCommConfig, LPDWORD lpdwSize) { @@ -172,7 +172,7 @@ /* * @unimplemented */ -BOOL WINAPI drvGetDefaultCommConfigA(LPCSTR lpszDevice, +DWORD WINAPI drvGetDefaultCommConfigA(LPCSTR lpszDevice, LPCOMMCONFIG lpCommConfig, LPDWORD lpdwSize) { @@ -231,7 +231,7 @@ /* Initialize baud rate combo */ if(!(hBox = GetDlgItem(hDlg, IDC_BAUDRATE))) - EndDialog(hDlg, 0); + EndDialog(hDlg, ERROR_CANCELLED); for(i = 0; Bauds[i]; i++) { @@ -246,7 +246,7 @@ /* Initialize byte size combo */ if(!(hBox = GetDlgItem(hDlg, IDC_BYTESIZE))) - EndDialog(hDlg, 0); + EndDialog(hDlg, ERROR_CANCELLED); for(i = 0; ByteSizes[i]; i++) { @@ -261,7 +261,7 @@ /* Initialize parity combo */ if(!(hBox = GetDlgItem(hDlg, IDC_PARITY))) - EndDialog(hDlg, 0); + EndDialog(hDlg, ERROR_CANCELLED); for(i = 0; Parities[i].StrId; i++) { @@ -278,7 +278,7 @@ /* Initialize stop bits combo */ if(!(hBox = GetDlgItem(hDlg, IDC_STOPBITS))) - EndDialog(hDlg, 0); + EndDialog(hDlg, ERROR_CANCELLED); for(i = 0; StopBits[i].StrId; i++) { @@ -295,7 +295,7 @@ /* Initialize flow control combo */ if(!(hBox = GetDlgItem(hDlg, IDC_FLOW))) - EndDialog(hDlg, 0); + EndDialog(hDlg, ERROR_CANCELLED); if(LoadStringW(hDllInstance, IDS_FC_NO, wstr, sizeof(wstr) / sizeof(wstr[0]))) { @@ -337,11 +337,11 @@ switch(wParam) { case IDC_CANCELBTN: - EndDialog(hDlg, FALSE); + EndDialog(hDlg, ERROR_CANCELLED); break; case IDC_OKBTN: OkButton(hDlg); - EndDialog(hDlg, TRUE); + EndDialog(hDlg, ERROR_SUCCESS); break; } return TRUE; @@ -349,11 +349,11 @@ case WM_CLOSE: { - EndDialog(hDlg, FALSE); + EndDialog(hDlg, ERROR_CANCELLED); return TRUE; } /* WM_CLOSE */ - default: + default: return FALSE; }

19 years, 11 months

API status

by Casper Hornstrup

Hi. I've set up the API status at: http://svn.reactos.com/api/ Casper

19 years, 11 months

RE: [ros-diffs] [ea] 16854: Various fixex to make HEAD compile.

by Casper Hornstrup

Why not just remove the code in #if 0/#endif? It serves no purpose. ________________________________________ From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of ea(a)svn.reactos.com Sent: 29. juli 2005 12:05 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [ea] 16854: Various fixex to make HEAD compile. Various fixex to make HEAD compile. I hope I did break nothing. Modified: trunk/reactos/hal/halx86/generic/processor.c Modified: trunk/reactos/lib/advapi32/sec/trustee.c Modified: trunk/reactos/lib/advapi32/service/scm.c Modified: trunk/reactos/subsys/csrss/win32csr/desktopbg.c Modified: trunk/reactos/subsys/ntvdm/ntvdm.c Modified: trunk/reactos/subsys/smss/client.c Modified: trunk/reactos/subsys/system/setup/setup.c Modified: trunk/reactos/subsys/system/winlogon/setup.c Modified: trunk/reactos/subsys/win32k/ntuser/keyboard.c ________________________________________ Modified: trunk/reactos/hal/halx86/generic/processor.c --- trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 09:51:08 UTC (rev 16853) +++ trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 10:04:38 UTC (rev 16854) @@ -39,7 +39,9 @@ HalStartNextProcessor(ULONG Unknown1, ULONG ProcessorStack) { +#if 0 DPRINT("HalStartNextProcessor(%x %x)\n", ProcessorNumber, ProcessorStack); +#endif return TRUE; }

19 years, 11 months

Re: [ros-dev] Regression in 15402

by Filip Navara

19 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev July 2005