- Ros-dev - ReactOS.org

by reactos

You used the BIOS USB to PS/2 bridge, not a USB driver. Yours sincerely, Jaix Bly ----Ursprungligt meddelande----- From: TwoTailedFox twotailedfox(a)gmail.com Date: Sat, 30 Jul 2005 17:52:59 +0200 To: Andrew Murphy andrewm1986(a)gmail.com Subject: Re: [ros-dev] USB mouse support > Oddly enough, I used 0.2.6 with a USB Mouse on my P4 System. The > cursor did appear, but the mouse sensitivity was way off. I could > roughly get it where I wanted to by moving very, very slowly, but this > wasn't practical, so I switched back to my USB-to-PS/2 way of using > the mouse. > > Good to hear it's near to being useable. > > On 7/30/05, Andrew Murphy <andrewm1986(a)gmail.com> wrote: > > > > > > On 30/07/05, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > > > Good to hear. > > > > > > Working support for my Microsoft Optical Intellimouse Explorer USB Optical > > > Mouse is one of the 2 things I want before I will try ROS on real hardware > > > again. (the other is support for my Belikn Wireless Network Card and > > > software and enough networking support so I can talk to the wireless > > router > > > and from there to the internet) > > > > > > > > > _______________________________________________ > > > Ros-dev mailing list > > > Ros-dev(a)reactos.com > > > http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.com > > http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > -- > "I had a handle on life, but then it broke" > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

20 years, 1 month

1
0
0 0

Re: [ros-diffs] [hbirr] 16901: If a mutex already exist, open it instead of create.

by Joseph Galbraith

Are you sure that we should be acquiring the mutex in the open case? MSDN says: bInitialOwner [in] Specifies the initial owner of the mutex object. If this value is TRUE and the caller created the mutex, the calling thread obtains ownership of the mutex object. Otherwise, the calling thread does not obtain ownership of the mutex.... Thanks, Joseph hbirr(a)svn.reactos.com wrote: > If a mutex already exist, open it instead of create. > Modified: trunk/reactos/lib/kernel32/synch/mutex.c > Modified: trunk/reactos/lib/kernel32/synch/mutex.c > --- trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:00:33 UTC (rev 16900) > +++ trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:03:34 UTC (rev 16901) > @@ -92,10 +92,24 @@ > MUTEX_ALL_ACCESS, > &ObjectAttributes, > (BOOLEAN)bInitialOwner); > + if (Status == STATUS_OBJECT_NAME_COLLISION) > + { > + Status = NtOpenMutant(&MutantHandle, > + MUTEX_ALL_ACCESS, > + &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + if(bInitialOwner) > + { > + WaitForSingleObject(MutantHandle, INFINITE); > + } > + SetLastError(ERROR_ALREADY_EXISTS); > + } > + } > if (!NT_SUCCESS(Status)) > { > - SetLastErrorByStatus(Status); > - return NULL; > + SetLastErrorByStatus(Status); > + return NULL; > } > > return MutantHandle;

20 years, 1 month

1
0
0 0

rbuild: module attributes

by Emanuele Aliberti

Hi all, I think the *module* node needs two more attributes - *subsystem* and *windows* - because at present module type and module subsystem are merged in the *type* attribute and its values are a bit confusing to me; also cui/gui information is hidden into value names. I don't know the rbuild code and I can't therefore say if it is an easy task splitting the logic behind the *type* attribute into tree attributes whitout affecting the whole program logic. A short rationale follows. ___ Valid values for the *type* attribute should be: - library (static) - hal - driver - program - dll Valid values for the *subsystem* attribute should be: - none - native - windows - posix - os2 - vms (default "windows"; "none" required for type "library"; "native" required for types "hal", "driver") Valid values for the *windows* attribute should be: - no - yes (default "no"; "no" required for types "library", "hal", "driver") ___ Examples: *ntdll.dll* <module name="ntdll" type="dll" ...> note that, at present, it is incorrectly described this way <module name="ntdll" type="dll" subsystem="native" ...> *ntoskrnl.exe* <module name="ntoskrnl" type="program" subsystem="native" ...> *atapi.sys* <module name="atapi" type="driver" subsystem="native" ...> -- :Emanuele Aliberti

20 years, 1 month

2
4
0 0

Reactos.com problems

by Ge van Geldorp

There are pretty strong indications that the reactos.com box was cracked. It took part in a DDoS attack. As a consequence, it was isolated from the network. Unfortunately, I'm on vacation right now so I don't have physical access to the box and am unable to fix/reinstall. For the moment, I've moved the mailing lists to a backup box. I am not moving the website, since it seems the attack was carried out via the website (a vulnerability in one of the php script packages we use). I'll put up a dummy page informing visitors. Not sure how far along the release of 0.2.7 is, but I'd like to suggest to put it off for at least another week, until I'm back and can sort things out. Apologies for the inconvenience, Ge van Geldorp.

20 years, 1 month

4
5
0 0

[Fwd: Re: [ros-dev] Regression in 15402 - fix in 16860

by Gge

Svn 16860 has fixed this problem (drivers\net\ndis\ndis\io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0x9) InterruptLevel (0x9) SharedInterrupt (1) InterruptMode (0x0) (drivers\net\ndis\ndis\io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector (0x49) Affinity (0xFFFFFFFF). (drivers\net\ndis\ndis\io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0). I'll test again "ping" command with head Regards Gerard

20 years, 1 month

1
0
0 0

Re: [ros-dev] USB mouse support

by reactos

Hello mr. Wilson and all others who is interested in USB mouse & keyboard. USB mouse and keyboard is being worked on right now, and it will be ready before 0.3.0 and probably after 0.2.7. We are talking weeks not months. Then again, this will be the USB Key and mouse driver, so expect some time for it to mature. Keyboard drivers is probably to be released first because this driver doesn't need HID stack, then the mouse driver will be developed, but there is a need there if some one could find a USB mouse driver C source that doesn't use a HID stack it will be done a lot faster. One interesting detail is that the development will be tested on XBox hardware which will make the XBox-port usable as a development platform. Yours sincerely, Jaix Bly ----Ursprungligt meddelande----- From: Jonathan Wilson jonwil(a)tpgi.com.au Date: Sat, 30 Jul 2005 02:21:02 +0200 To: ReactOS Development List ros-dev(a)reactos.com Subject: [ros-dev] USB mouse support > How far away is support for USB mice? > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

20 years, 1 month

4
3
0 0

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

20 years, 1 month

2
1
0 0

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

20 years, 1 month

2
1
0 0

USB mouse support

by Jonathan Wilson

How far away is support for USB mice?

20 years, 1 month

1
0
0 0

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

20 years, 1 month

10
17
0 0

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

20 years, 1 month

1
0
0 0

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

20 years, 1 month

2
1
0 0

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; }

20 years, 1 month

2
2
0 0

API status

by Casper Hornstrup

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

20 years, 1 month

2
2
0 0

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; }

20 years, 1 month

2
1
0 0

Re: [ros-dev] Regression in 15402

by Filip Navara

20 years, 1 month

2
1
0 0

Geda Tool GSchem with Gdi Object Bug

by James Tabor

Hi, If anyone likes EDA programming tools and stuff. I've been testing geda tools from http://geda.seul.org/. The mingw32 tool set. At least I had the canvas and the info window popped up. Still more work to be done, but better than ~9 mo ago. Here is the debug log, (lib/ntdll/ldr/utils.c:2037) Failed to create or open dll section of 'Wintab32.d ll' (Status c0000135) GDI32: GetTextCharsetInfo is unimplemented, please try again later. (lib/ntdll/ldr/utils.c:2094) Relocating (10000000 -> dc1000) C:\geda\lib\pango\1 .2.0\modules\pango-basic-win32.dll (lib/ntdll/ldr/utils.c:1215) LdrGetExportByName(): failed to find g_module_check _init (lib/ntdll/ldr/utils.c:1215) LdrGetExportByName(): failed to find g_module_unloa d (lib/ntdll/ldr/utils.c:2037) Failed to create or open dll section of 'usp10.dll' (Status c0000135) WARNING: NtGdiGetGlyphOutline at subsys/win32k/objects/text.c:2163 is UNIMPLEME NTED! WARNING: NtGdiGetGlyphOutline at subsys/win32k/objects/text.c:2163 is UNIMPLEME NTED! <snip... .> WARNING: NtGdiGetGlyphOutline at subsys/win32k/objects/text.c:2163 is UNIMPLEME NTED! (ntoskrnl/io/file.c:3366) Invalid access rights (lib/ntdll/ldr/utils.c:2094) Relocating (10000000 -> de1000) C:\geda\lib\gtk-2.0 \2.2.0\loaders\libpixbufloader-xpm.dll (lib/ntdll/ldr/utils.c:1215) LdrGetExportByName(): failed to find g_module_check _init (lib/ntdll/ldr/utils.c:1215) LdrGetExportByName(): failed to find g_module_unloa d WARNING: NtGdiGetGlyphOutline at subsys/win32k/objects/text.c:2163 is UNIMPLEME NTED! <snip... .> WARNING: NtGdiOffsetClipRgn at subsys/win32k/objects/cliprgn.c:330 is UNIMPLEME NTED! WARNING: NtGdiOffsetClipRgn at subsys/win32k/objects/cliprgn.c:330 is UNIMPLEME NTED! WARNING: NtGdiOffsetClipRgn at subsys/win32k/objects/cliprgn.c:330 is UNIMPLEME NTED! (ntoskrnl/mm/mm.c:300) Address: ffffffff _SEHCallHandler: REG 006de75c _SEHCallHandler: REG 006dec28 _SEHCallHandler: REG 006dec28 Unhandled exception Address: 7c819641 C:\ReactOS\system32\kernel32.dll CS:EIP 1b:7c819641 DS 23 ES 23 FS 3b GS 0 EAX: 7c8b95c8 EBX: 27100250 ECX: 006df0f0 EDX: 00005453 EBP: 006df148 ESI: 10043ea3 ESP: 006df100 EDI: 000003d7 EFLAGS: 00010217 Frames: 7c800000+199b9 C:\ReactOS\system32\kernel32.dll 80b000+62493 C:\geda\lib\libglib-2.0-0.dll 10000000+4e718 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+442b0 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+334d6 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+33b67 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+3ea1 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+3ea1 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+1f133 C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+3ea1 C:\geda\lib\libgdk-win32-2.0-0.dll 9de000+1512a3 C:\geda\lib\libgtk-win32-2.0-0.dll 9de000+1571b2 C:\geda\lib\libgtk-win32-2.0-0.dll 9de000+21090e C:\geda\lib\libgtk-win32-2.0-0.dll 9de000+2109af C:\geda\lib\libgtk-win32-2.0-0.dll 9de000+eeffa C:\geda\lib\libgtk-win32-2.0-0.dll 966000+4469 C:\geda\lib\libgobject-2.0-0.dll 966000+3cbc C:\geda\lib\libgobject-2.0-0.dll 966000+1727f C:\geda\lib\libgobject-2.0-0.dll 966000+166f1 C:\geda\lib\libgobject-2.0-0.dll 966000+16b36 C:\geda\lib\libgobject-2.0-0.dll 9de000+1fe4bb C:\geda\lib\libgtk-win32-2.0-0.dll 9de000+ed9dd C:\geda\lib\libgtk-win32-2.0-0.dll 10000000+2123e C:\geda\lib\libgdk-win32-2.0-0.dll 10000000+212da C:\geda\lib\libgdk-win32-2.0-0.dll 9de000+44160 C:\geda\lib\libgtk-win32-2.0-0.dll 80b000+1c865 C:\geda\lib\libglib-2.0-0.dll 80b000+1d07c C:\geda\lib\libglib-2.0-0.dll 80b000+1d6e3 C:\geda\lib\libglib-2.0-0.dll 80b000+1a21f C:\geda\lib\libglib-2.0-0.dll 9de000+ed0e9 C:\geda\lib\libgtk-win32-2.0-0.dll 400000+8f60 C:\geda\bin\gschem.exe 6eb00000+1dae1 C:\geda\lib\libguile.dll 6eb00000+2113c C:\geda\lib\libguile.dll 6eb00000+45696 C:\geda\lib\libguile.dll 6eb00000+20ef8 C:\geda\lib\libguile.dll 6eb00000+20dcb C:\geda\lib\libguile.dll 6eb00000+1db0b C:\geda\lib\libguile.dll 400000+9266 C:\geda\bin\gschem.exe 400000+1182 C:\geda\bin\gschem.exe 400000+1018 C:\geda\bin\gschem.exe 7c800000+2efec C:\ReactOS\system32\kernel32.dll _SEHCallHandler: REG 006deca8 _SEHCallHandler: REG 006dffb8 _SEHCallHandler: REG 006dffb8 (subsys/win32k/objects/gdiobj.c:545) GdiHdr->Locks: 1 Assertion 'FALSE' failed at subsys/win32k/objects/gdiobj.c line 549 KeBugCheckWithTf at ntoskrnl/ke/catch.c:228 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0x80000003,0x8009fdc1,0x9dcf624e,0x00000009) *** ntoskrnl.exe - Address 0x8009fdc1 base at 0x80000000, DateStamp 0x0 Breakpoint Exception: 3(0) Processor: 0 CS:EIP 8:8009fdc1 <ntoskrnl.exe:9fdc1 ({standard input}:23 ())> cr2 76179ed5 cr3 3ac9d000 Proc: 816d71b0 Pid: 120 <gschem.exe> Thrd: 816d8c40 Ti d: 124 DS 10 ES 10 FS 30 GS 0 EAX: 00000044 EBX: 000000d5 ECX: 00000000 EDX: 000003f8 EBP: 9f0ffc14 ESI: 006dfef0 ESP: 9f0ffb84 EDI: 9f0ffd74 EFLAGS: 00000292 kESP 9f0ffb84 kernel stack base 9f0fd000 Frames: <win32k.sys:802d8 (subsys/win32k/objects/gdiobj.c:549 (GDIOBJ_FreeObj))> <win32k.sys:805f2 (subsys/win32k/objects/gdiobj.c:670 (GDI_CleanupForProcess))> <win32k.sys:3aea3 (subsys/win32k/main/dllmain.c:102 (Win32kProcessCallback))> <ntoskrnl.exe:82bce (ntoskrnl/ps/win32.c:99 (PsTerminateWin32Process))> <ntoskrnl.exe:7a6a2 (ntoskrnl/ps/kill.c:295 (PspExitThread))> <ntoskrnl.exe:7ae16 (ntoskrnl/ps/kill.c:591 (NtTerminateProcess))> <ntoskrnl.exe:958b2 ({standard input}:177 (KiSystemService))> <kernel32.dll:32222 (lib/kernel32/process/proc.c:592 (ExitProcess))>

20 years, 1 month

1
0
0 0

Forward to or put a link to http://reactosde.re.funpic.de on the ROS homepage?

by reactos

Wouldn't it be good to forward web-users to http://reactosde.re.funpic.de ? or at least put a link for those wanting to go on with something? Yours sincerely, Jaix Bly

20 years, 1 month

2
1
0 0

Upgrading Subversion to 1.2.1

by Casper Hornstrup

Hi. I'm upgrading Subversion on svn.reactos.com to version 1.2.1 to correct some memory leaks in svnserve. Subversion 1.2.x also brings us: Faster access to old revisions. svn blame, svn checkout, svn update, svn diff, svn merge will be faster. Locking. If you have an 1.2.x client you can lock files and directories. This is mostly useful for binaries so it's possibly not something we will use much. For faster access to old revisions, a "dump and load" of the repository is needed so the repository will be unavailable for a few hours today. Casper

20 years, 1 month

1
1
0 0

Regression in 15402

by Alex Ionescu

Hi, It seems that the problem regarding Ged's RTL network card is related to patch 15402: http://svn.reactos.com/viewcvs?view=rev&rev=15402. Is it possible that the card is incorrectly (or not in the same way we are expecting) telling us its resource data? Or that somethign has been overlooked? Ged has done a terrible deal of network testing for us but he's been unable to work since his network card couldn't even ping anymore. I've helped him find the regression and I hope someone more experienced in PnP can help him out... at least we know what patch did it. Best regards, Alex Ionescu

20 years, 1 month

1
1
0 0

Re: [ros-diffs] [ion] 16730: - Final ROSRTL removal patch. The next patch will remove the actual library and code.

by Hartmut Birr

ion(a)svn.reactos.com wrote: >- Final ROSRTL removal patch. The next patch will remove the actual library and code. >- Changes: > - CreateProcess > * Cleanup creation of the initial thread using new utility functions and remove rosrtl > * Almost entirely rewrote the function to support features such as: > - SxS (locally only, patch will follow), > - SFP (SAFER) (locally only, patch will follow), > - DllPaths (locally only, patch will follow), > - Proper process environment/paramter block creation > - Proper console handle management (needs more work in kernel32/csr), > - Tokens/CreateProcessAsUser (locally only, patch will follow), > - Simpler code for path lookup, and more robust. > - Support for "auto-correction" (see Raymond Chen's blog) > - 16-bit/NE detection > - A variety of creation flags are now properly supported > - Added support for an undocumented-yet-known (see comment) shell flag > - Alert for flags we don't support yet > - Catch invalid flag combinations and other caller errors > - Improve and correct path searcing to use documented behaviours > - Created a multitude of helper functions to make the code easier to read > and allow them to be used for other apis as time goes on. > > - BaseProcessStartup > * Call NtSetThreadInformation to let the Kernel know of the Thread's Start Address. > * Correct prototype of Thread Startup function for this case. > >This fixes MANY things, some of which may not be evident, and possibly creates regressions which I have not yet seen but will try to correct. Some of these may be caused by the fact that I've seen code send CreateProcessW incorrect flags. Some things of note: DO NOT send partial names as "lpApplicationName". It's not supposed to work unless you're in the same current directory. Also, do NOT send CREATE_UNICODE_ENVIRONMENT if you don't have a unicode environement, and vice-versa. I've seen lots of code doing mistakes related to this. I hope you appreciate this patch and won't all jump on me for possbile regressions :(. > >Modified: trunk/reactos/lib/kernel32/process/create.c >Modified: trunk/reactos/lib/kernel32/thread/i386/thread.S >Modified: trunk/reactos/lib/kernel32/thread/thread.c >Modified: trunk/reactos/ntoskrnl/mm/process.c > > > ------------------------------------------------------------------------ Hi, your rewrite of CreateProcess is broken. Before you can inform csrss about the process creation, you have to gather all informations about handles and creation options. After your commit, each console application creates its own console window and the redirection of standard handles is broken. It seems also that the inheritance of msvcrt file id's is broken. This stops compiling ros on ros. - Hartmut

20 years, 1 month

3
2
0 0

Crash by starting OOo1.4 setup.exe (r16740)

by reactos

OOo1.4 Setup is crashing ROS, here comes a crashreport ROS r16740 Yours sincerely, Jaix Bly

20 years, 1 month

3
2
0 0

Re: [ros-svn] [ion] 16728: - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please?

by Alex Ionescu

ion(a)svn.reactos.com wrote: > - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please? > > > With the combination of this patch + Hartmut's patch + DBG = 0 build (and/or disabling RZ detection), Winrar runs fine again. However, pressing OK in the dialog bug causes a crash in RtlFreeUnicodeString->RtlpFreeMemory->ExFreePool. It seems the buffer is invalid. So it looks like two things have to be fixed for Winrar and other apps to work fine (Windows Commander does work now): 1) Stop the GDI Object from being freed twice. This will fix the first bugcheck and allow Winrar to work in DBG = 1 with RZ enabled. Disabling RZ is only a hack and shouldn't be used a solution. The stack trace ships the double-free routine pretty well, but I'm not well versed in win32k to fix this. 2) Find out why we are RtlFreeUnicodestring-ing what seems to be an invalid pointer. I think if we can fix these two issues we'll have many more apps working again! I've tested Winrar 3.50 b7, btw. Best regards, Alex Ionescu

20 years, 1 month

3
3
0 0

Re: [ros-diffs] [ion] 16804: - Include ctype.h by default.

by Hartmut Birr

ion(a)svn.reactos.com wrote: >- Include ctype.h by default. > >Modified: trunk/reactos/w32api/include/winnt.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/w32api/include/winnt.h* > >--- trunk/reactos/w32api/include/winnt.h 2005-07-27 16:34:14 UTC (rev 16803) >+++ trunk/reactos/w32api/include/winnt.h 2005-07-27 16:55:40 UTC (rev 16804) >@@ -34,6 +34,7 @@ > > extern "C" { > #endif > > > >+#include <ctype.h> > > > #include <winerror.h> > > #ifndef RC_INVOKED > > Hi, this changing is wrong (and some other with ctype.h). You can't include ctype.h from mingw for optimized builds (DBG = 0), because ctype.h from mingw needs to import msvcrt.dll. - Hartmut

20 years, 1 month

2
1
0 0

Blockers...

by Alex Ionescu

Hi, Here is a current update on the 0.2.7 blockers...if you can help, please DO! BUG: - Green icon in run dialog REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD. CAUSE: Incorrect icon was added to resource file. FIXED: Yes. Fix needs to be merged into 0.2.7 branch. ------------------- BUG: - Common Dialog Control Broken for File/Save. REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669. CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed. ---------------------- BUG: - If you use the arrow keys in the explorer start menu to expand an entry, you cannot use them anymore to go up and down. No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code? --------------------- BUG: - If you right-click on the desktop to show the context menu, then right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore. No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides. ------------------- BUG: - Several applications have regressed due to "memory corruption" and a bugcheck related to NtGdiRealizePallette. More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps. -------------------- BUG: - AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe others). REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression. Best Regards, Alex Ionescu

20 years, 1 month

21
36
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev