- Ros-dev - ReactOS.org

[Fwd: Delivery Notification: Delivery has failed]

by Alex Ionescu

-- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

1
0
0 0

Trunk. Development. Testing.

by Aleksey Bragin

Hello, I have thought long time before writing this email, and finally it's time to write it... N.B. I don't intend to hurt or offense anyone in this email. And there is not so much use from a project leader who only says "yes", "good", "agreed". We all see ReactOS became quite a big thing. Big everywhere - source code, goals, development time... I think one would wish every FOSS project to gain that level and speed of development. If someone of you played Civ during youth, you certainly remember that your cities can't grow, grow and grow without any efforts - people become unhappy, city is ovecrowded, demanding sanitation and special facilities in order to continue growth. If you don't provide those needed facilities, the city is going to at least stop its development, and usually goes into disorder due to unhappines. Similar thing happens in software development too. Once project reached certain size (even in terms of SLOC), developers' "tools" should be upgraded and enhanced. That's it for theory. Let's have a look at ReactOS, and more specifically its trunk. I'm getting more and more complaints that trunk is unstable, remains unstable, and most of the time doesn't even boot, and the time came to actually solve this problem, once and for ever. As an example, I will show only one of common scenario: Some developer commits his code, which works for him on his, say, qemu but doesn't work for another dev on his real hardware. That developer continues to commit code, and in some time encounters that dev whose machine doesn't boot reactos and he says: "hey, you ...ng ...rd, you broke trunk!". I don't even dare to cite which reply follows, because it would take a few pages to quote. The developer who broke trunk starts to regress test, reverting revision by revision, spending time to identify the regressed revision (this may take a few days, and we don't have fulltime paid developers), and then finally finds the bug, fixes and commits. By that time, another developer commits code with a regression in other place, and trunk is still unbootable. And blaming continues, flamewars start, who broke what, instead of actually enjoying the development process. Pretty unproductive, yeah? And you, the reader, are definately wondering - what is the solution? I answer: There are a few solutions, but as always I will list only a few 1) "Wine"-method. There is one leader who decides what, how and when to commit. He maintains the tree, he makes sure tree is in good shape, he spends all of his time to do testing, merging, reverting, remerging. It works really good for Wine. Will it work good for us? I am in doubts, really. 2) Improving our current development system. That's the direction I would like to use. Major and the first improvement needed is testing. Testing often, testing early, automating testing, getting more people to test, regress test and feed results back to developers. Buildbot was a step in this direction, but more steps are needed. If someone broke booting, a proper recognized complain would be "Revision NNXXY regresses 3rd boot with a bugcheck code NN stack trace attached". The sooner this information is available and developer is notified - the faster this bug will be solved. If developer is inaccessible within a long period of time, a decision to revert this revision might be taken (that should be a really rare case). This shouldn't come to absurd of course, I can tolerate having trunk broken for a few hours certainly, when developer is working on a certain feature, and, well, of course he may mistake, not fully commit something and so forth. But having it half-broken for 2 weeks AND noone took time to regress test and find the guilty revision. Or yet another example, fortunately last for this email. I implemented an "alpha" version of usb mouse driver, along with that recently incorporated NT4 compatible usb driver. And assumed, and even asked in irc to test it - it's not that hard, but gives me a chance to fix not-so-obvious issues before it'll be enabled by default in trunk and will drive people crazy with some regress which I didn't see on my machine, and, at last, even hearing "yay, your usb mouse driver works!" just simply motivates me to finish e.g. a usb keyboard driver, find and fix bugs, etc. Conclusions. 1) To improve development quality we must improve testing. Automate, gather bigger testing team, etc. 2) Developers must be way more careful during commit. Just remember a simple rule: Trunk is not a wastebin where you dump code to. It's quite the opposite. Feedback. Your feedback is greatly encouraged and awaited. Feel free to discuss this in this ML. With the best regards, Aleksey Bragin ReactOS Project Coordinator

18 years, 11 months

8
12
0 0

Testing Coordinator, position open November 22.

by James Tabor

Testing Coordinator, position open November 22. Disapproved! You are going to work 90 more days due to that GOD! DAMNED! AUDIT! Thank you for your service, Management

18 years, 11 months

3
2
0 0

Bug 1819

by Peter Quiring

I've fixed bug 1819 and added a patch to bugzilla, can someone verify and apply the patch. It works for me. Thanks. Peter Quiring

18 years, 11 months

1
0
0 0

svn.reactos.org/iso no longer works...

by Richard

http://svn.reactos.org/iso no longer has the latest isos. Last revision was 24295.

18 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 24383: add LPCDLGTEMPLATE definition

by Reuel ben Yisrael

gedmurphy(a)svn.reactos.org wrote: >============================================================================== >--- trunk/reactos/include/psdk/winuser.h (original) >+++ trunk/reactos/include/psdk/winuser.h Wed Oct 4 02:43:46 2006 >@@ -2631,6 +2631,13 @@ > short cy; > } DLGTEMPLATE,*LPDLGTEMPLATE,*LPDLGTEMPLATEA,*LPDLGTEMPLATEW; > typedef const DLGTEMPLATE *LPCDLGTEMPLATE; // <---- first >+typedef const DLGTEMPLATE *LPCDLGTEMPLATEA; >+typedef const DLGTEMPLATE *LPCDLGTEMPLATEW; >+#ifdef UNICODE >+typedef LPCDLGTEMPLATEW LPCDLGTEMPLATE; // <---- second (unicode) >+#else >+typedef LPCDLGTEMPLATEA LPCDLGTEMPLATE; // <---- second (ansi) >+#endif // UNICODE > #pragma pack(pop) > typedef struct tagDRAWITEMSTRUCT { > UINT CtlType; > > does this really compile? LPCDLGTEMPLATE appears to be duplicately typedef'd. ( see added comments above )

18 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hpoussin] 24379: Copy i8042prt driver from 0.3.1 branch to trunk. Try #2

by Alex Ionescu

hpoussin(a)svn.reactos.org wrote: > Author: hpoussin > Date: Tue Oct 3 22:04:03 2006 > New Revision: 24379 > > URL: http://svn.reactos.org/svn/reactos?rev=24379&view=rev > Log: > Copy i8042prt driver from 0.3.1 branch to trunk. Try #2 > > Added: > trunk/reactos/drivers/input/i8042prt/ > - copied from r24378, branches/ros-branch-0_3_1/reactos/drivers/input/i8042prt/ > > Why are we copying it from branch to trunk? Shouldn't it be copied from trunk to the branch? -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

3
3
0 0

Build Hive Error

by James Tabor

Rev 24339 with gcc 3.4.2, bin utils 2.15.94 [COPY] reactos/system32/win32k.sys [CC] tools/mkhive/binhive.c include/psdk/intrin.h: In function `_InterlockedCompareExchange8': include/psdk/intrin.h:193: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedCompareExchange16': include/psdk/intrin.h:200: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedCompareExchange': include/psdk/intrin.h:207: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedCompareExchange64': include/psdk/intrin.h:236: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedCompareExchangePointer': include/psdk/intrin.h:250: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedExchange': include/psdk/intrin.h:257: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedExchangePointer': include/psdk/intrin.h:264: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `_InterlockedExchangeAdd': include/psdk/intrin.h:271: error: undefined named operand 'retval' include/psdk/intrin.h:271: error: undefined named operand 'Addend' include/psdk/intrin.h:271: error: output operand constraint lacks `=' include/psdk/intrin.h: In function `__writecr0': include/psdk/intrin.h:1009: error: undefined named operand 'value' include/psdk/intrin.h: In function `__writecr3': include/psdk/intrin.h:1014: error: undefined named operand 'value' include/psdk/intrin.h: In function `__writecr4': include/psdk/intrin.h:1019: error: undefined named operand 'value' make: *** [obj-i386/tools/mkhive/binhive.o] Error 1

18 years, 11 months

2
2
0 0

Actual NTLDR boot screenshot

by Alex Ionescu

Sometimes pictures speak better then commit messages, so here's the current boot status: http://www.tinykrnl.org/ros_by_ntldr.png It fails because our Memory Manager early-boot initialization depends on some freeldr information. If I can/have time, I'll try to make it not depend on them, and/or use NTLDR structures instead. Anyways, serial debug printing works and the GDT, IDT, TSS, KPCR are all setup, so this can now be used as a good tool for blackboxing ntldr. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

2
1
0 0

Working trunk?

by Alex Ionescu

Hi, I took a break from the project hoping any regressions I might've caused could be found/fixed... isntead, I now find myself with an OS that won't recognize my mouse/keyboard. I've tried rebooting it to re-start 2nd stage (which used to work before), but all this does is gradually damage the registry more and more, either leading to aSSERTs or freeldr codepage error. This is with a 100% clean trunk on QEMU 0.8.2. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

1
0
0 0

Time date control panel applet bug and DrawStatusText issues

by Felipe Villarroel

Hello list!, i have two questions that i hope that someone of you could answer. The first one: - Should RegOpenKeyExW() do a SetLastError() or it just return an error code? I ask this because in the timedate control panel applet, GetSyncSetting() reads a key from the registry using that function and if it fails it calls the function GetError() that calls FormatMessage() using GetLastError() as an argument. For some reason in my computer this call fails and i receive an window that says "ERROR_INVALID_WINDOW_HANDLE" that obviously is not the right error code. This bug could be reproduced by double clicking in the Hour located in the right corner of the start menu bar. Next you click the Internet Time tab and you should receive the error. To fix this i can think of two possibilities: - Modify RegOpenKeyExW() to do a SetLastError() if this fails to set a right code for GetLastError(), or - Modify the GetError() function in the timedate control panel applet I don't know which is the right way to fix this. Finally in my opinion, if an error occurs in this situation i think that no message should appear because i think that is not too bad if this key isn't present. And the second question follows... - I have written a program that displays a Status bar using the DrawStatusText() function. In Windows it is working pretty well but in ReactOS it doesnt. DrawStatusText() in ReactOS doesnt draw a background when calling this function thus my status window draws over itself each time i receive a WM_PAINT message. So its clear that in windows DrawStatusText() draws a background before painting the text, but in ReactOS it doesnt. Currently i have hacked the DrawStatusText() function to draw a background like this: void WINAPI DrawStatusTextW (HDC hdc, LPRECT lprc, LPCWSTR text, UINT style) { RECT r = *lprc; UINT border = BDR_SUNKENOUTER; HBRUSH hBkBrush, hOldBrush; if (style & SBT_POPOUT) border = BDR_RAISEDOUTER; else if (style & SBT_NOBORDERS) border = 0; DrawEdge (hdc, lprc, border, BF_RECT|BF_ADJUST); /* now draw text */ if (text) { int oldbkmode = SetBkMode (hdc, TRANSPARENT); UINT align = DT_LEFT; if (*text == L'\t') { text++; align = DT_CENTER; if (*text == L'\t') { text++; align = DT_RIGHT; } } r.left += 3; if (style & SBT_RTLREADING) FIXME("Unsupported RTL style!\n"); // yep this fixed the problem, but i don't know what the // right color it is hBkBrush = GetSysColorBrush(GetSysColor(COLOR_BTNFACE)); hOldBrush = SelectObject(hdc, hBkBrush); FillRect(hdc, lprc, hBkBrush); DrawTextW (hdc, text, -1, lprc, align|DT_VCENTER|DT_SINGLELINE|DT_NOPREFIX); SelectObject(hdc, hOldBrush); SetBkMode(hdc, oldbkmode); } } Attached i send the code that shows this "bug" and a precompiled binary. Also i have tested this program under WINE with the same results (0.9.x i think). Thats all, Best regards, Felipe Villarroel -- _______________________________________________ Get your free email from http://www.linuxmail.org Powered by Outblaze

18 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hpoussin] 24286: Support mount manager in disk.sys

by Alex Ionescu

hpoussin(a)svn.reactos.org wrote: > Author: hpoussin > Date: Thu Sep 28 20:33:12 2006 > New Revision: 24286 > > URL: http://svn.reactos.org/svn/reactos?rev=24286&view=rev > Log: > Support mount manager in disk.sys > > Modified: If you're going to add this kind of support, I'd appreciate it if you took a look at TinyKRNL/WDK to see how this should be done. FTDISK is responsible for all the code you've added, not disk.sys, and if we're going to implement NT5+ Storage stack features on top of an NT4 driver, this will mean either one of these two things: 1) A crappy "ROS" stack that's incompatible with anything NT offers (and the storage stack is heavily documented in NT, so we're at a big loss if we do this). 2) Someone will have to eventually re-write even more code to make it compatible. I suggest you work on implementing an XP/2K3 style classpnp driver first. The WDK and TinyKRNL have sample source code (non-reversed), and there's 50 pages of documentation on it. Once that works, a new disk.sys can be written (same information as above is available). Then ftdisk should follow. It handles all Fault-Tolerance stuff, but about 6000 lines of it are responsible for the glue layer between the storage stack. TinyKRNL has just finished implementing it, so the information and documentation located there should be helpful (using TinyKRNL documentation and code for learning purposes is fully in-line with our IP policy and the whole point of the project). Then partmgr, mountmgr can be written. These are also implemented in TinyKRNL completely. (Except GPT support). Finally, some parts of the kernel's IoMgr needs to be changed in the method in which it sets up disk letters, and kernel32 needs some new code (which Filip has on his disk). -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

1
0
0 0

MSCoder Magazine

by Katarzyna Chauca

Dear Friends Here I am again. I would like to prepare the CD with ReactOS live. But I need a description - how to instal, why use it, how use it, what works on it etc for our readers. Please let me know if someone can help us and write it. Best Regards Kate www.mscoder.org/es --- Katarzyna Chauca Market Manager Editorial Software 0048228871457

18 years, 11 months

1
0
0 0

test

by Magnus Olsen

Hi I have not resive any mail for 48hours from reactos mailing list, so I am trying see if they are working or not

18 years, 11 months

2
1
0 0

RE : Usb Fault

by James Tabor

Hi, Sylvain Petreolle wrote: > Hi James, > why dont you try the new driver ? > (drivers/usb/nt4compat/usbdriver) I guess I can try it. I moved the drivers out of the directory and the system just sit there doing nothing. Thanks, James

18 years, 11 months

1
0
0 0

Usb Fault

by James Tabor

Hi! Happy to boot again! Thank you Arty and Hervé! So, USB fault with real hardware. r24264 in second stage boot. It lockup on first stage and I did not get the setup gui. (dll/win32/newdev/newdev.c:736) Installing PCI-ISA bridge (PCI\VEN_1106&DEV_3177 &SUBSYS_31771106&REV_00\1&f103bba4&11) (dll/win32/newdev/newdev.c:525) Installing driver (Generic system devices): Standard PCI to ISA bridge (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\isapnp.sys" - > L"C:\\ReactOS\\System32\\drivers\\isapnp.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/newdev/newdev.c:736) Installing USB controller (PCI\VEN_1106&DEV_3104 &SUBSYS_73401462&REV_82\1&f103bba4&70) (dll/win32/newdev/newdev.c:525) Installing driver (Generic USB devices): EHCI USB controller (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbport.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbport.sys" (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbehci.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbehci.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/rpcrt4/ndr_marshall.c:928) unhandled data type=09 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ldr/loader.c:262) Could not open module file: \SystemRoot\System32\drivers\usbehci.sys (Status 0xc0000034) (ntoskrnl/io/pnpmgr/pnpmgr.c:2371) Initialization of service usbehci failed (Status c0000034) (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/newdev/newdev.c:736) Installing USB controller (PCI\VEN_1106&DEV_3038 &SUBSYS_30381106&REV_80\1&f103bba4&50) (dll/win32/newdev/newdev.c:525) Installing driver (Generic USB devices): UHCI USB controller (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbport.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbport.sys" (dll/win32/setupapi/queue.c:1456) copy error 2 L"C:\\ReactOS\\inf\\usbuhci.sys" -> L"C:\\ReactOS\\System32\\drivers\\usbuhci.sys" (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (dll/win32/rpcrt4/ndr_marshall.c:928) unhandled data type=09 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/usbport/usbcore.c:15) Miniport 0x81C5AB48 registered (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x81C7A128, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 0: A05850B8 A05803F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 172 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 1: A0585114 A05802F0 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called. .. (drivers/usb/usbport/hub.c:1230) hub_thread startingEntered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0xCDCDCDF1 could not be read: Page not present. kdb:> bt Eip: <usbuhci.sys:65b4 (drivers/usb/miniport/common/pdo.c:132 (UsbMpPdoPnp))> Frames: <usbuhci.sys:5ac2 (drivers/usb/miniport/common/main.c:402 (DispatchPnp))> <ntoskrnl.exe:3630a (ntoskrnl/io/iomgr/irp.c:1084 (IofCallDriver))> <ntoskrnl.exe:3b906 (ntoskrnl/io/pnpmgr/pnpmgr.c:944 (IopInitiatePnpIrp))> <ntoskrnl.exe:3c3c0 (ntoskrnl/io/pnpmgr/pnpmgr.c:1753 (IopActionInterrogateDeviceStack))> <ntoskrnl.exe:3c0e2 (ntoskrnl/io/pnpmgr/pnpmgr.c:972 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:3c0f7 (ntoskrnl/io/pnpmgr/pnpmgr.c:986 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:3c119 (ntoskrnl/io/pnpmgr/pnpmgr.c:1011 (IopTraverseDeviceTree))> <ntoskrnl.exe:3d822 (ntoskrnl/io/pnpmgr/pnpmgr.c:2542 (IopInvalidateDeviceRelations))> <ntoskrnl.exe:35a75 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:22f38 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:69bbc (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:73ad2 (ntoskrnl/ke/i386/ctxswitch.S:258 (KiThreadStartup@156))> kdb:>

18 years, 11 months

2
3
0 0

Mailserver and website migration over

by Aleksey Bragin

Hello, The ReactOS server is finally fully migrated now, including mailing lists, webserver with all its contents, SVN server, etc. Thanks for your patience during the server movement, we had to change really a lot of stuff, to make future transfers easier, to prevent "slashdotting" and many many other things. I am very pleased to announce that now everything is in place and is expected to work as it always did. There is a note however, for translators and admins, the static webpages are cached now and are automatically updated every 2 hours. So a change in the static web page can take as much as 2 hours before it goes "live". With the best regards, Aleksey Bragin. P.S. That spammer in ros-dev is unsubscribed from the list.

18 years, 11 months

2
1
0 0

Re: [ros-dev] Contato na Syxt

by Alex Ionescu

Samuel serapion wrote: > looks like spam... from what little i understand of it > Please have the decency not to re-include the entire 10KB html email and to add your own 6KB 1-line reply. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 11 months

1
0
0 0

reactos can't boot in vmware 4.5, please fix asap

by Saveliy Tretiakov

Recent revisions can't boot in vmware 4.5. I tested some other revisions: 23800 - same problem, 23520 - boots for me. Debug log: (ntoskrnl\kd\kdio.c:193) --------------------------------------------------------------- (ntoskrnl\kd\kdio.c:194) ReactOS 0.4-SVN (Build 20060902-r23887) Used memory 131072Kb (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (lib\cmlib\hiveinit.c:154) ChunkSize: e000 (ntoskrnl\cm\import.c:73) Adding new hive (lib\cmlib\hiveinit.c:154) ChunkSize: 4000 (ntoskrnl\cm\import.c:73) Adding new hive (ntoskrnl\vdm\vdmmain.c:42) VME detected but not yet supported (0,8D3DAA90,36) (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ldr\loader.c:267) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (ntoskrnl\ldr\loader.c:267) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\io\iomgr\device.c:347) You are seeing this because the following ROS driver: \Driver\cdfs sucks. Please fix it's AddDevice Routine (./base/system/smss/initwkdll.c:70) NtOpenFile() failed (Status c000000e) (ntoskrnl\io\iomgr\device.c:347) You are seeing this because the following ROS driver: \Driver\cdfs sucks. Please fix it's AddDevice Routine (./base/system/smss/initwkdll.c:70) NtOpenFile() failed (Status c000000e) (lib\cmlib\hiveinit.c:154) ChunkSize: 20000 (lib\cmlib\hiveinit.c:154) ChunkSize: 2000 (lib\cmlib\hiveinit.c:154) ChunkSize: 2000 (lib\cmlib\hiveinit.c:154) ChunkSize: 3000 (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\process.c:692) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (ntoskrnl\ps\thread.c:503) FIX PS SDs!! *** Fatal System Error: 0x0000001e (0xC0000005,0x8001AE2C,0x00000000,0x0000000E) <ntoskrnl.exe:2518 (ntoskrnl/ke/bug.c:1069 (KeBugCheckEx))> <ntoskrnl.exe:6e5c7 (ntoskrnl/ke/i386/exp.c:790 (KiDispatchException))> <ntoskrnl.exe:76af6 (ntoskrnl/mm/i386/pfault.c:133 (KiPageFaultHandler))> <ntoskrnl.exe:71354 (ntoskrnl\ke\i386\trap.s:1412 (KiTrap14))> <ntoskrnl.exe:1ae2c (ntoskrnl/ex/resource.c:2253 (ExTryToAcquireResourceExclusiveLite))> <ntoskrnl.exe:a7cd (ntoskrnl/cc/view.c:254 (CcRosFlushDirtyPages))> <ntoskrnl.exe:4581d (ntoskrnl/mm/mpw.c:92 (MmMpwThreadMain))> <ntoskrnl.exe:63ed7 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))>

19 years

3
5
0 0

win32k coding standart

by Saveliy Tretiakov

Hi. I have two questions: 1) Do we still use DECLARE_RETURN\CLEANUP macros, or it is obsolete and shouldn't be used any more? Why not use goto directly? 2) Do we still use MmCopyFromCaller\MmCopyToCaller or not? (I heared the new standart is to use probing macros and SEH )

19 years

1
0
0 0

Re: [ros-dev] Command line

by Thomas Weidenmueller

> "Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive." That's why you have to unmount the drive when ie. formatting or chkdsk'ing it. Defragmentation however can be done whithout unmounting, because the fs driver handles this job. The IOCTLs are documented in the platform sdk, defragmentation really doesn't work using fmifs/ufat/untfs/u... - Thomas

19 years

1
0
0 0

Re: [ros-dev] Command line

by Imre Leber

>From the sysinternals website that is somewhat involved with microsoft: "Neither UNTFS.DLL nor UFAT.DLL call file system drivers to take any part in a format or chkdsk operation - they directly read and write raw clusters on the drive." Imre >-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Monday, September 4, 2006 03:42 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > > >> The big benefit of using this library is that it let's you write code to >> manipulate the FAT file system that works on FAT12, FAT16, FAT32 without >> knowing the exact FAT file system this is going to run on. The same code >> works for FAT12, FAT16, FAT32 without having code that looks like: > >In ROS each FS driver has to implement the defrag APIs. An application can >defrag any FS by using the 3 publicly documented IOCTLs. >UFAT/UNTFS/Uxxx... is not used for fs defragmentation. > >> Anyway this could be used as the basis for ufat.dll. The utilities that >> already use this library could then also be put in here. And the rest can >> then be easily written. > >As mentioned above, defragmentation is done by the fs drivers in kernel mode. > >> What would then be needed is the actual functions that make up the >> interface to ufat.dll. > >We can design the interfaces to ufat, untfs, ... as we wish. These >interfaces are not documented publicly as there is no standard. each FS >should come with it's own utilities. Chkdsk can only be used with the file >systems that come with windows/reactos, other FS need to provide their own >tools. > >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

19 years

1
0
0 0

Re: [ros-dev] Command line

by Imre Leber

The current design of defrag, chkdsk, recover FAT manipulation utilities in FreeDOS is that there is a FAT manipulation library called the "FAT transformation engine" that all the other utilities use. The big benefit of using this library is that it let's you write code to manipulate the FAT file system that works on FAT12, FAT16, FAT32 without knowing the exact FAT file system this is going to run on. The same code works for FAT12, FAT16, FAT32 without having code that looks like: if it is FAT12 do this, and if it is FAT16 do that and if it is FAT32 do again something else. Like is done in the reactos loader (freeloader?) This is optimized code that is used in real life programs. Anyway this could be used as the basis for ufat.dll. The utilities that already use this library could then also be put in here. And the rest can then be easily written. What would then be needed is the actual functions that make up the interface to ufat.dll. I've seen that there is example code on the internet that uses these functions. On http://www.sysinternals.com/SourceCode/fmifs.html Imre >-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Monday, September 4, 2006 02:23 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >On 9/3/06, Aleksey Bragin <aleksey(a)studiocerebral.com> wrote: >> We are really in demand of a working check-disk utility, so I gladly >> accept any correctly working version compatible with Windows (as in: >> not depending on specific ReactOS's features). >> It doesn't stop us from implementing fmifs.dll, uFILESYSTEM.dll's, >> etc too. Even helps, I would say. > >Thats why I started porting the dosfsck a while back. Some of the >lower level dlls for filesystem checking are highly obfuscated. It >would be better to have a working tool now rather than never. > > >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

19 years

2
1
0 0

Re: [ros-dev] War Continues?

by Thomas Weidenmueller

> This needs to end, now! *WE* would have to do something, not them. The credibility is quite low, which is absolutely comprehensible. But that's not neccessary because I believe it's already too late. I don't think the relationship to wine is ever going to be the one it used to be again. Let's just live with it... - Thomas

19 years

2
1
0 0

War Continues?

by James Tabor

Hi, This needs to end, now! http://www.winehq.org/pipermail/wine-devel/2006-September/050661.html Thanks, James

19 years

4
5
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