- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [weiden] 25828: - Move around definitions to make the code a bit more modular - Use an about menu instead of an button

by Murphy, Ged (Bolton)

weiden(a)svn.reactos.org wrote: > > Modified: trunk/reactos/base/applications/charmap/charmap.c > + case WM_SYSCOMMAND: > + { > + switch(wParam) > + { > + case ID_ABOUT: > DialogBox(hInstance, > MAKEINTRESOURCE(IDD_ABOUTBOX), > hDlg, > AboutDialogProc); Modified: trunk/reactos/base/applications/charmap/map.c + if (RegisterClass(&wc)) + { + wc.lpfnWndProc = LrgCellWndProc; + wc.cbWndExtra = 0; + wc.lpszClassName = szLrgCellWndClass; > Modified: trunk/reactos/base/applications/charmap/precomp.h > -INT_PTR CALLBACK AboutDialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam); > -LRESULT CALLBACK LrgCellWndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam); Maybe I'm reading the diff wrong, but does this not break the build? (not been able to svn up this weekend) I'm guessing the 'case ID_ABOUT' should now call ShowAboutDlg, but what about the assignment of LrgCellWndProc? Ged. Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD. Registered in England: No. 2375355 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)eu.exide.com <mailto:postmaster@eu.exide.com> 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 <www.exide.com>

18 years, 3 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mbosma] 25812: Lester Kortenhoeven (lester(at)ko rtenhoeven(dot)de)

by Murphy, Ged (Bolton)

mbosma(a)svn.reactos.org wrote: > +WCHAR ApplicationText[700]; ... > - StrCatW(DescriptionText, Strings[IDS_VERSION]); > - StrCatW(DescriptionText, SelectedApplication->Version); > - StrCatW(DescriptionText, L"\n"); > + StrCatW(ApplicationText, Strings[IDS_VERSION]); > + StrCatW(ApplicationText, SelectedApplication->Version); > + StrCatW(ApplicationText, L"\n"); This doesn't fix anything, there is still a potential overflow issue. Quickly skimming through the app, there are numerous other issues too. Ged. Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD. Registered in England: No. 2375355 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)eu.exide.com <mailto:postmaster@eu.exide.com> 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 <www.exide.com>

18 years, 4 months

1
0
0 0

Changelog for 0.3.1

by Zachary Gorden

Hi all, I'm one of the release engineers (with Colin_Finck) and we're starting to put together the changelog. We're asking any devs that want to to add what they feel might be a noteworthy accomplishment/change made to 0.3.1 in the Highlights of this Release section on the changelog. Here's the link: http://www.reactos.org/wiki/index.php/ChangeLog-0.3.1 Also, as we branch out and begin cataloging the changes in more detail, you're all welcome to add in or clarify things. However, we do reserve the right to make edits to your contributions either for formatting, clarity, or general readability issues. Thank you for your attention, we now return to your regular programming. Z98

18 years, 4 months

3
4
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25794: patch from Physicus, implement TOOLTIPS_NotifyFormat, it now retrurn the type of the string if it unicode or ansi. before it did not return any type at all. it did a heap crash from downloader mangers when

by Steven Edwards

On 2/14/07, Saveliy Tretiakov <saveliyt(a)gmail.com> wrote: > Ged Murphy пишет: > > IIRC, Julliard stated that if test cases were submitted along with the > > patch, he would accept code. > > No, not always. My rpc code with testcases was not accepted, because it > was from reactos. I think Alexandre has loosened his restrictions a bit. If I recall correctly you had a widl patch, he might be interested in some of them now as he is having to do a bit of work on that code. Thanks -- 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

18 years, 4 months

5
7
0 0

WIDL

by Jacques Mony

Hi, I've read somewhere on a Wine list archive that WIDL was supposed to be imported into RosBE, back in... 2005? Can someone tell me what happened and if there is a reason why it's not present at the moment. Thanks, -- Jacques Mony

18 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25794: patch from Physicus, implement TOOLTIPS_NotifyFormat, it now retrurn the type of the string if it unicode or ansi. before it did not return any type at all. it did a heap crash from downloader mangers when it try figout what type of sting the toolstips use. it is tested in 0.3.1 and not whole implemnent is tested yet. it should be right for all case.

by Ged Murphy

greatlrd(a)svn.reactos.org wrote: > URL: http://svn.reactos.org/svn/reactos?rev=25794&view=rev > Log: > patch from Physicus, Did anyone actually bother to read Thomas' last email about keeping our comctl32 in line with Wines?

18 years, 4 months

5
5
0 0

Re: [ros-dev] about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Thomas : ZwQueryDefaultLocale is located in ntoskrnl and it is call on NtQueryDefaultLocale check by my self let us take a look at NtUserGetKeyboardLayoutName 1. it return a keyboard name the keyboard name is the current active Keyboard LCID to optain it we can use ZwQueryDefaultLocale (check reactos code in ntoskrnl how it works) so let us use ZwQueryDefaultLocale to optain the current activate keyboard with follow call ZwQueryDefaultLocale(FALSE, &LocaleId); what happen then let us take a look at ZwQueryDefaultLocale if (UserProfile) *DefaultLocaleId = PsDefaultThreadLocaleId; else *DefaultLocaleId = PsDefaultSystemLocaleId; return DefaultLocaleId; etiher we get current threed local or local system keyboard LCID with this call depns on it is current user or not. depns what we whant. so it is a correct impement to use it. now we can check other thing as well please check how it works in ntoskrnl in ex/local.c then we can talk how it works.

18 years, 4 months

4
6
0 0

Re: [ros-dev] [ros-diffs] [tretiakov] 25758: Add multiple keyboard layout support. Implemented NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName.

by Aleksey Bragin

On Feb 9, 2007, at 11:48 PM, tretiakov(a)svn.reactos.org wrote: > Author: tretiakov > Date: Fri Feb 9 23:48:37 2007 > New Revision: 25758 > > URL: http://svn.reactos.org/svn/reactos?rev=25758&view=rev > Log: > Add multiple keyboard layout support. Implemented > NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, > NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName. > > > -NtUserLoadKeyboardLayoutEx 6 > +NtUserLoadKeyboardLayoutEx 2 Magnus says that this change is incorrect (and respective change of the prototype is incorrect too, because, he says, we had a Win2003- compatible prototype). Can you comment on this please? WBR, Aleksey Bragin.

18 years, 4 months

4
6
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 25768: Property sheet: - Set focus to defpushbutton or to first WC_EDIT child window if present, like it works on windows. - update wine diff This fixes the regression in 2nd stage setup when no keyboard focus was present.

by Thomas Weidenmueller

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sun Feb 11 01:02:45 2007 > New Revision: 25768 > > URL: http://svn.reactos.org/svn/reactos?rev=25768&view=rev > Log: > Property sheet: > - Set focus to defpushbutton or to first WC_EDIT child window if present, like it works on windows. > - update wine diff > This fixes the regression in 2nd stage setup when no keyboard focus was present. > > Modified: > trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > trunk/reactos/dll/win32/comctl32/propsheet.c Why is it so difficult to keep differences with wine code as minimal as possible? Who's supposed to merge all these things in case conflicts appear in the future? Why not submit the patches to wine? - Thomas

18 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25763: reverting 25758 : for follow reason 1. it cause regress of loading keyboard layout from the regsiter when reatcos booting. 2. it does not follow windows implement 3. it does not using ntoskrnl for it is ntoskrnl that handling the keyboard not the win32k. 4. it does not using right protoype for some syscall 5. some syscall does not working like windows. it mess it up instead. 6. Do not implement own design on public api and syscall

by Aleksey Bragin

REVERT WARS ARE NOT ALLOWED in the repository. Fix the code together with its author or wait my approval for reverting. Your SVN account has been temporarily suspended now for periodical violation of the established revert-rules (major part of which were proposed actually by Magnus). Aleksey Bragin. On Feb 10, 2007, at 5:52 PM, greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sat Feb 10 17:52:46 2007 > New Revision: 25763 > > URL: http://svn.reactos.org/svn/reactos?rev=25763&view=rev > Log: > reverting 25758 : for follow reason > 1. it cause regress of loading keyboard layout from the regsiter > when reatcos booting. > 2. it does not follow windows implement > 3. it does not using ntoskrnl for it is ntoskrnl that handling the > keyboard not the win32k. > 4. it does not using right protoype for some syscall > 5. some syscall does not working like windows. it mess it up instead. > 6. Do not implement own design on public api and syscall

18 years, 4 months

2
1
0 0

Re: [ros-dev] about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Hi some example ZwQueryDefaultLocale is located in ntoskrnl it call on NtQueryDefaultLocale it is to get current keyboard name file ntoskrnl/ex/locale.c in that file it exists all api to get and set the a keyboard. a keyboard are being loading either from user mode or kmode. in kmode it is loading by ntoskrnl or win32k depns on the case which keyboard that is active are set by ntoskrnl not win32k to get defult or current keyboard is the ntoskrnl jobb not win32k so on. so do not change my implement of NtUserGetKeyboardLayoutName it is correct test in Windows and in ReactOS. we need using same api as windows and same prototype. even undocument thing. but what I provide is a start to use it. but not complete what I did give about NtUser* so change it to 7 param and use the protoype I gave u. use the x2 and x6 I put in, so we can change it to same as windows when we got more informations how it works. I do not have time to dig after any more doc about it. one more thing use the Zw* api when u call on ntoskrnl from win32k. and the keyboard work are split betwin user32.dll, win32k.sys, ntoskrnl. they doing diffeting thing, but theý are linked toghther like user32.dll -> win32k.sys -> ntoskrnl.exe | | --------------- | \ / Keyboard drv both talk with the keyboard drv and can loading it depns on the case all setting are done by ntoskrnl and win32k is relay those msg when it is need it to ntoskrnl

18 years, 4 months

3
2
0 0

about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Hi The commit 25758 are complete wrong, more I looking at more foualt I found we are not longer windows comptable with the keyboard with this commit. it mean win32k syscall does not longer working as it should do in windows. and it also fuckup loading process of the keyboard. example ntoskrnl is setting which defualt keyboard that should be in use and so on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying set it will mess up the keyboard loading. the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA pProcessWindowStation, x6, IN INT Flags); But x2 and x6 are not in use. I have not figout x3,x4 yet

18 years, 4 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [tretiakov] 25758: Add multiple keyboard layout support. Implemented NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName.

by Thomas Weidenmueller

> + if(!*phModule) DPRINT1( "Failed to load %wZ\n", &FullLayoutPath ); > + else DPRINT( "Loaded Keyboard Layout: %wZ\n", &FullLayoutPath ); Code like this might expand incorrectly, which is why it's highly recommended to use {...} - Thomas

18 years, 4 months

2
1
0 0

COM development with MingW for ReactOS

by Jacques Mony

Hi, I recently decided to give a hand on the project. So I joined the IRC channel and asked for ideas of applications I could make for ReactOS, in order to make it more "complete". Alex Ionescu suggested, among other ideas, an implementation of MMC. So, I decided to jump on the idea. However, I have minimal knowledge of COM programming in C and minimal knowledge of C++. Although, I have good knowledge of assembly (x86), C in general, as well as VB6. So, I decided to look at how MMC works. I quickly realized that I would need to implement some interfaces (like IUnknown, for a simple one). MingW doesn't seem to handle COM development very well. However, I read in some places that it could support COM development when doing pure C programming. I like the idea since I do know C much better than C++... so I read the following tutorial: http://www.codeproject.com/com/com_in_c1.asp That was interesting until I tried to do that with MingW. No succes. So, I'd like to know if someone managed to do that yet (ie a COM "component", which implements interfaces). Thanks, -- Jacques Mony

18 years, 4 months

1
0
0 0

Tree Cleanup

by Alex Ionescu

Hi all, After talking to some developers about the recent state of the ReactOS tree, compiler times and disk space, I've analyzed our tree and found the following preliminary round of changes that should be made to stay in line with our policy that ReactOS provides what Windows does, at the core level. Any extra functionality or applications not provided by Windows have always been supposed to go into rosapps, as well as test applications. For testing/regression testing, I actually recommend the creation of a ros-tests repository, which will contain the tests in rosapps plus the ones I've mentionned below. This isn't just about disk space or compiling speed, but also to keep our tree clean and conformant. Here's the list: \base\applications\devmgmt should go into a new folder called "mscutils" along with similar MSC clones. \base\applications\getfirefox should be removed. \base\applications\devmgr should be removed. \base\applications\downloader should be moved to rosapps. \base\applications\gettype should be moved to rosapps. \base\applications\ibrowser should be removed. \base\applications\imagesoft shoudl be moved to rosapps. \base\applications\network\roshttpd should be moved to rosapps. \base\applications\reporterror should be removed. \base\applications\screenshot should be moved to rosapps. \base\applications\servman should go into a new folder called "mscutils" along with similar MSC clones. \base\applications\shutdown should go to \cmdutils. \base\applications\sm should be removed. \base\applications\testsets should go to rosapps. \base\applications\utils should go to rosapps. \base\applications\winefiel should to rosapps. \base\services\dhcpd should go to rosapps. \drivers\base\debugout should be removed. \drivers\base\green should go to rosapps. \drivers\base\ramdrv should go to rosapps. \drivers\base\test should go to rosapps. \drivers\filesystems\ext2 should go to rosapps. \drivers\filesystems\minix should go to rosapps. \drivers\filesystems\template should go to rosapps. \drivers\multimedia\avtest should go to rosapps. \drivers\network\tditest should go to rosapps. \regtests should go to rosapps. As well, there has been talk that \tools should become part of RosBE as -O3, heavily optimized binaries on Windows. They should stay in the default reactos trunk download, but building them shouldn't be done on Windows unless the binaries can't be found or the option has been forced. This will make bug reporting and testing safer since we'll know the tools are the same ones the developers are using (at least on Windows, where we can manage this better). I am very much pushing for this change to happen, as it will make our life easier for a variety of reasons: - MSVC or GCC 4.2 -O3 tools decrease build times. A highly optimized rbuild binary does dependency checking almost twice as fast as a regular -Os binary. - Decrease build times since the tools don't have to be rebuilt/cleaned each time. - Decrease storage space for developers that want to locally delete the entire tree. - Reduce the number of potential problems that outside testers might have to due to improper building of their tools. The tools Microsoft releases in the DDK are the same ones they use internally, so any bugs appear on both versions, and it makes diagnosing a lot easier. Unfortunately binaries can't be provided for Linux, but since /tools would stay in the reactos directory, Linux builders would be completely unaffected (except they wouldn't have the added advantages). As far as I know, Aleksey, Christoph and Johannes are willing to back this up and do the necessary changes for the /tools; I'll handle fixing the .xml files and doing the tree moves. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

5
5
0 0

regression on 2nd stage setup

by Timo Kreuzer

GreatLord told me about a regression that might be caused by one of my patches. In fact it was two patches working together: 1.) 25410, win32k: Make NtUserSetFocus accept NULL window. This patch is correct. Win XP behaves the same way. 2.) 25412, user32.dll: remove focus from window, when it gets disabled I have tested this and compared results to XP, I am sure it works the same on XP. On XP when you disable a control you will hear a sound when trying to use tab / arrow keys after that. Focus is not moved to another control. The regression coming from those patches is that on 2nd stage setup keyboard focus is removed from the Back/Next buttons. I found one problem in comctl32: When using PropSheet_SetWizButtons() the appropriate button will be set as defpushbutton, but not recieve focus. This can be corrected with a small patch, wich would solve most of the regression. But it introduces another bug: On 2nd stage AckPage (2nd page) the focus should be set to username edit control. But it would be set to Next button, even if SetFocus(<usernameeditcontrol>) was called after calling PropSheet_SetWizButtons() So I compiled syssetup as an exe to work on XP and tried to find out how it works on XP. On XP syssetup behaves the way that I think it should. More testing gave me the following result: The propsheet sets the focus automatically to the first editcontrol (maybe other controls, too, didn't test) that was defined in the resource. It is independed from the control ID and position of the control. Only thing that is important is the position at wich the control was defined in the rc file. So my question: How dows windows know the position of the control inside the resource? Do we have something like that implemented in ROS? Any help appreaceated. Another minor thing: XP displays no focus rect (dotted rect on buttons that have focus) until a tab / arrow key was used. Then it stays. It's only a visual enhancement, but it woud be nice to also have this. Does anyone know how win does this? BTW: Should I patch comctl32 to fix that regression, or send a patch to wine? I also have another patch for the updown control that behaves incorrect with wine code. And another thing: I first tried to execute syssetup.dll on XP with rundll32 (rundll32.exe syssetup.dll,InstallWizard), but it said it could not find InstallWizard. Can someone tell me why it does not work? Greetings, Timo

18 years, 4 months

1
0
0 0

My ReactOS PR Efforts

by Alex Ionescu

Hi all, I just wanted to keep you update of the various ReactOS presentations, lectures and exhibitions that I will be part of to help push ReactOS out to more people. Three weeks ago I was at CUSEC, where I demoed ReactOS in front of about 60 people, all software engineering students, mostly. They were very impressed and I exchanged contact information with 5-6 of them, who hope to join development eventually (probably this summer). On Friday, I'm flying over to LA at SCALE 5x (South California Linux Expo 2007) where Arty will be exhibiting ReactOS and I will be a speaker to give a lecture on ReactOS and Open Source involvement. A couple of weeks later, on the 27th, I'm flying over to University of Waterloo to meet the students in their CS club and other interested students in Software Engineering/CS to talk about ReactOS, my work, and also on using ReactOS as an educational tool, possibly to replace their current NachOS-based curriculum. In April, on the 11th, I will be flying to Porto Alegre in Brezil, at the 8th International Free Software Forum, where I will be a lecturer. Again, I will talk about ReactOS -- although I haven't found a specific topic yet, since I don't want to re-hash the SOCAL presentation. I have also been invited to demo ReactOS at a DemoCamp in all of Montreal, as far as I remember this date is in April as well. The other date I am aware of is FOSSCON 2007, which will be on the 22nd of September in San Diego (IIRC). Again, I will probably present about ReactOS -- definite topic to be determined. I have also mentionned ReactOS profusely in some personal interviews which will appear in some Montreal and even worldwide newspapers, as well as various online sources such as Slyck. My blog entry has recently motivated a donor to donate 1000$ US to the foundation; I am working with him to arrange a proper receipt. I hope that throughout the year, I'll be able to announce more events. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 25726: Make LoadCursorIconImage() find shared icons, even if they don't have the desired width/height. Now expl orer doesn't leak icons / bitmaps anymore. fixes bug 1554 See issue #1554 for more details.

by Murphy, Ged (Bolton)

tkreuzer(a)svn.reactos.org wrote: > + FreeResource(hResource); FreeResource is deprecated

18 years, 4 months

2
1
0 0

Wmi declarations in wmilib stub

by Felipe Villarroel

>From winddk.h: #define NTKERNELAPI DECLSPEC_IMPORT NTKERNELAPI NTSTATUS NTAPI WmiCompleteRequest( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp, IN NTSTATUS Status, IN ULONG BufferUsed, IN CCHAR PriorityBoost); In wmilib.c: NTSTATUS NTAPI WmiCompleteRequest(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp, IN NTSTATUS Status, IN ULONG BufferUsed, IN CCHAR PriorityBoost) winddk.h should be modified? This difference (in the three functions) breaks build (also the windows ddk define this as NTSTATUS only). (If i redefine the functions in wmilib.c i get a strange bug in gcc: [CC] drivers\wmi\wmilib.c drivers\wmi\wmilib.c: In function 'WmiSystemControl': drivers\wmi\wmilib.c:62: internal compiler error: in rest_of_handle_final, at final.c:3942 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. mingw32-make: *** [obj-i386\drivers\wmi\wmilib.o] Error 1 Best regards, Logan_V8

18 years, 4 months

1
0
0 0

Security problem in NtGdiCreateCompatibleDC?

by Timo Kreuzer

Please have a look at that code: NtGdiCreateCompatibleDC @ 192: ... hNewDC = DC_AllocDC <http://www.reactos.org/generated/doxygen/de/dcc/dc_8h.html#a12>(&OrigDC->DriverName <http://www.reactos.org/generated/doxygen/d9/de9/struct__DC.html#o8>); if (NULL == hNewDC) { DC_UnlockDc(OrigDC); if (NULL != DisplayDC) { NtGdiDeleteObjectApp <http://www.reactos.org/generated/doxygen/d7/de8/subsystems_2win32_2win32k_2…>(DisplayDC); } return NULL; } NewDC = DC_LockDc( hNewDC ); ... I am not completely sure (GreatLord said it was fine) but i think it might not be. Let's think of a condition when process x, thread 0 does try call NtGdiCreateCompatibleDC and Allocates the DC. Wouldn't there be the chance of thread 1 to get a lock on the DC (by guessing it's handle) just after it was created and make DC_LockDC return NULL? GDIOBJ_LockObj checks if the ProcessID is the same as PsGetCurrentProcessId() , but not more. So I think a second thread might do a timed attack and get a lock on the just created DC.

18 years, 4 months

1
0
0 0

problems building with gcc 4.1.2 (RosBE 0.3.4)

by Felipe Villarroel

Hi, today i tried to compile ReactOS with gcc 4.1.2 under RosBE 0.3.4 (previously i used both gcc 3.4.5 and gcc 4.1.2, with a previous svn revision). Before trying to switch compilers i have successfully built an iso image with gcc 3.4.5. So, i issued a make clean in the gcc 3.4.5 enviroment. Then i changed to gcc 4.1.2 and issued a make bootcd (with current SVN). In the building process i got this error message: [CC] lib\intrlck\i386\compareexchange.c [AR] obj-i386\lib\intrlck\intrlck.a [LD] output-i386\dll\ntdll\ntdll.dll [RSYM] output-i386\dll\ntdll\ntdll.dll [LD] output-i386\dll\win32\kernel32\kernel32.dll obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedCompareExchange@12': d:/reactos/current/include/psdk/intrin.h:110: undefined reference to `__sync_val_compare_and_swap_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedIncrement@4': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedDecrement@4': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedExchangeAdd@8': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status mingw32-make: *** [output-i386\dll\win32\kernel32\kernel32.dll] Error 1 I'm using ReactOS Build Environment 0.3.4-4.1.2-20061229-prerelease-patched. Probably i could comment the gcc version checking in intrin.h to get this to compile, but that isn't nice/right :P. As far as i know __sync_* functions are supplied by the compiler and they should be present in gcc 4.1.2. Is this right? Anyone got an idea why this doesn't work? Thanks in advance for your help, Best regards, Logan_V8 d:\reactos\current>echo __GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__ > p.txt d:\reactos\current>cpp < p.txt cc1.exe: warning: is shorter than expected # 1 "<stdin>" # 1 "<built-in>" # 1 "<command line>" # 1 "<stdin>" 4 * 10000 + 1 * 100 + 2

18 years, 4 months

1
1
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25667: - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Feb 1 01:30:59 2007 > New Revision: 25667 > > URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev > Log: > - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change. > This does not fix the freeze/slowdown/issue I am seeing with the NT scheduler disabled. I still can't boot to desktop. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25667: - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Feb 1 01:30:59 2007 > New Revision: 25667 > > URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev > Log: > - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change. > > I still get a hang after pressing "Next" on the last 2nd stage setup wizard page. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

2
3
0 0

How it went: running Burn under ReactOS

by Alexander Rødseth

Hi, A few weeks ago, I received an e-mail asking me to test Burn, my old drawing-program for Dos, on ReactOS. However, I've lost that e-mail somehow, so I'm hoping this mailinglist is the right place to send my reply, as a substitute. The original e-mail was from someone affiliated with ReactOS. I used ReactOS 0.3-RELEASE (Build 20060827-r23747), running under Qemu. A screenshot of how it went is included. ("Bad command or filename", even though the command was valid). Burn works perfectly well under DosBox. Hope this was of any help whatsoever, and thanks for your contributions to the world of open source. Best regards, Alexander Rødseth

18 years, 4 months

1
0
0 0

Crash on exit

by hto＠mail.cnt.ru

> Can't really fix this, this is a side effect of > the fact that NT checks that the initial boot > process didn't die, and the fact that our setup > code actually replaces the initial process. It can be fixed on process level, not on the kernel level.

18 years, 4 months

1
0
0 0

LiveCD and 0.3.1

by Alex Ionescu

This should go in the branch: http://www.reactos.org/bugzilla/attachment.cgi?id=1125&action=view -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

1
0
0 0

FreeLDR improvement

by Alex Ionescu

http://www.reactos.org/bugzilla/show_bug.cgi?id=1881 Please commit 1051. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

1
0
0 0

A slightly more aggressive mm patch

by art yerkes

http://www.superheterodyne.net/reactos/freelist_remove_type.diff This removes the redundant notion of .Flags.Type in freelist, and leaves only the non-redundant MM_PHYSICAL_PAGE_BIOS. MM_PHYSICAL_PAGE_FREE is reported when the page has a 0 reference count and MM_PHYSICAL_PAGE_USED is reported when the reference count is nonzero. A function, MmGetPageType is added to replace the old functionality. Init memory being freed seems to cause a lot of grief. I'm going to see if there's a way to decentralize how those pages are set up, given that the method used to dispose of them is spread out too. -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

18 years, 4 months

2
1
0 0

A patch for page dereferencing

by art yerkes

This patch makes ReferenceCount include MapCount so we don't get into the quite common situation where the balance manager wants to expel a mapped section. I've been seeing this error running quite a number of things and recently even in the first stage installer. Lightly tested, probably wrong as usual. http://www.superheterodyne.net/reactos/fix_page_reference.diff -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

18 years, 4 months

1
0
0 0

Hardware Boot Error Rev 25642

by James Tabor

Hi! Look at the cmd line options! It did display the debug printout for the devices. Cool, Kick A$$, Rosxor! Alex! James (ntoskrnl/kd/kdio.c:193) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:194) ReactOS 0.4-SVN (Build 20070126-r25642) (ntoskrnl/kd/kdio.c:195) Command Line: DEBUGPORT=COM1 NOGUIBOOT SOS (ntoskrnl/kd/kdio.c:199) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)partition(1) \ReactOS\ (ntoskrnl/ke/i386/cpu.c:514) Not handling AMD caches yet Used memory 1015744Kb (ntoskrnl/se/semgr.c:36) FIXME: SeAccessCheck has been HACKED to always grant access! (ntoskrnl/se/semgr.c:37) FIXME: Please fix all the code that doesn't get proper rights! (ntoskrnl/ke/i386/kiinit.c:43) Large Page support detected but not yet taken advantage of! WARNING: HaliQuerySystemInformation at hal/halx86/generic/sysinfo.c:26 is UNIMPLEMENTED! (ntoskrnl/ke/i386/patpge.c:62) Advanced Memory features detected but not yet taken advantage of. (ntoskrnl/ke/i386/mtrr.c:24) Your machine supports MTRR but ReactOS doesn't yet. (ntoskrnl/io/iomgr/driver.c:908) Driver 'buslogic.sys' load failed, status (c0000001) (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1 (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 10001 (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1 (ntoskrnl/vdm/vdmmain.c:42) VME detected but not yet supported (lib/fslib/vfatlib/vfatlib.c:215) VfatChkdsk() unimplemented! (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff *** Fatal System Error: 0x0000001e (0x80000003,0x81022F94,0x00000000,0x00000000) <ntoskrnl.exe:2891 (ntoskrnl/ke/bug.c:1078 (KeBugCheckEx))> <ntoskrnl.exe:86b66 (ntoskrnl/ke/i386/exp.c:995 (KiDispatchException))> <ntoskrnl.exe:8913b (ntoskrnl/ke/i386/trap.s:681 (CommonDispatchException))> <81022F95>

18 years, 4 months

2
1
0 0

RosBE Buils Error ntoskrnl\ke\thrdschd.c

by James Tabor

Hi! RosBE 4.1.2 in revision 25638. [CC] ntoskrnl\ke\thrdschd.c cc1.exe: warnings being treated as errors ntoskrnl\ke\thrdschd.c: In function 'KiSwapThread': ntoskrnl\ke\thrdschd.c:480: warning: pointer targets in passing argument 1 of 'InterlockedOr' differ in signedness mingw32-make[1]: *** [obj-i386\ntoskrnl\ke\thrdschd.o] Error 1 mingw32-make[1]: Leaving directory `C:/reactos/reactos' mingw32-make: *** [depends] Error 2 Thanks, James

18 years, 4 months

1
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25627: revers r25623 Acdring to Sylvai n Petreolle, spetreolle at yahoo.fr this is copy paste from windows xp cp l, it is not allown todo a copy paste of sentence from windows xp, he did compare it.

by Murphy, Ged (Bolton)

greatlrd(a)svn.reactos.org wrote: > revers r25623 Yeeey, greatlord is back to his old reverting ways ;) > Acdring to Sylvain Petreolle, spetreolle at yahoo.fr > this is copy paste from windows xp cpl, it is not allown > todo a copy paste of sentence from windows xp, he did > compare it. Most of our control panel text is the same as Windows.

18 years, 4 months

2
1
0 0

0.3.1 Branch First Boot Linux BE

by James Tabor

SSDD,,, Hardware, etc,,,, kdb:> (ntoskrnl/kd/kdio.c:193) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:194) ReactOS 0.3.1-SVN (Build 20070124-r25623) (ntoskrnl/kd/kdio.c:195) Command Line: DEBUGPORT=COM1 (ntoskrnl/kd/kdio.c:199) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \ multi( 0)disk(0)rdisk(0)partition(1) \ReactOS\ (ntoskrnl/ke/i386/cpu.c:502) Not handling AMD caches yet Used memory 1015744Kb (ntoskrnl/se/semgr.c:41) FIXME: SeAccessCheck has been HACKED to always grant access! (ntoskrnl/se/semgr.c:42) FIXME: Please fix all the code that doesn't get proper rights! (ntoskrnl/ke/clock.c:92) FIXME: TIMER UPDATE NOT DONE!!! (ntoskrnl/ke/i386/kiinit.c:41) Your machine supports PGE but ReactOS doesn't yet. WARNING: HaliQuerySystemInformation at hal/halx86/generic/sysinfo.c:26 is UNIMPLEMENTED! (ntoskrnl/ke/i386/patpge.c:62) Your machine supports PAT but ReactOS doesn't yet. (ntoskrnl/ke/i386/cpu.c:745) Your machine supports XMMI exceptions but ReactOS doesn't (ntoskrnl/io/iomgr/driver.c:905) Driver 'buslogic.sys' load failed, status (c0000001) (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1 (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (Status 0xc0000034) (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (Status 0xc0000034) (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 10001 (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1 (ntoskrnl/vdm/vdmmain.c:42) VME detected but not yet supported (lib/fslib/vfatlib/vfatlib.c:215) VfatChkdsk() unimplemented! (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (./subsystems/win32/win32k/objects/dc.c:324) No InstalledDisplayDrivers value in service entry found (./subsystems/win32/win32k/objects/dc.c:479) FindDriverFileNames failed (ntoskrnl/io/iomgr/file.c:410) FIXME: Broken Parse due to invalid DesiredAccess: 1f01ff (dll/ntdll/ldr/utils.c:1198) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2024) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2024) Failed to create or open dll section of 'midimap.drv' (Status c0000135) <Here.......> (lib/cmlib/hiveinit.c:31) Verify Hive Header failed: (lib/cmlib/hiveinit.c:32) Signature: 0x66676572 and not 0x66676572, Major: 0x1 and not 0x1 (lib/cmlib/hiveinit.c:34) Minor: 0x3 is not >= 0x3, Type: 0x0 and not 0x0 (lib/cmlib/hiveinit.c:36) Format: 0x1 and not 0x1, Cluster: 0x1 and not 1 (lib/cmlib/hiveinit.c:38) Sequence: 0x17 and not 0x17, Checksum: 0x70e9199b and not 0x0 (lib/cmlib/hiveinit.c:159) Registry is corrupt: ChunkSize 20480 < sizeof(HBASE_BLOCK) 4096, or HvpVerifyHiveHeader() failed (ntoskrnl/cm/regfile.c:580) Failed to open hive (ntoskrnl/mm/mm.c:193) Page fault at high IRQL was 2, address cccccc94 Entered debugger on last-chance exception (Exception Code: 0xc0000006) (Unknown/ User defined exception) kdb:> bt Eip: <ntoskrnl.exe:4f24e (ntoskrnl/mm/npool.c:1556 (ExFreeNonPagedPool))> Frames: <ntoskrnl.exe:5296e (ntoskrnl/mm/pool.c:237 (ExFreePool))> <ntoskrnl.exe:5299e (ntoskrnl/mm/pool.c:249 (ExFreePoolWithTag))> <ntoskrnl.exe:71ff2 (ntoskrnl/rtl/libsupp.c:61 (RtlpFreeMemory))> <ntoskrnl.exe:97966 (lib/rtl/unicode.c:392 (RtlFreeUnicodeString))> <ntoskrnl.exe:11cb0 (ntoskrnl/cm/regfile.c:585 (CmiLoadHive))> <ntoskrnl.exe:105e9 (ntoskrnl/cm/ntfunc.c:2348 (NtLoadKey2))> <ntoskrnl.exe:1071f (ntoskrnl/cm/ntfunc.c:2238 (NtLoadKey))> <ntoskrnl.exe:7ce34 (ntoskrnl/ke/i386/trap.s:250 (KiFastCallEntry))> <ntdll.dll:85ad (dll/ntdll/main/i386/dispatch.S:265 (KiFastSystemCallRet@0))> <userenv.dll:3ab6 (dll/win32/userenv/profile.c:292 (CreateUserProfileW))> <syssetup.dll:1a2f (dll/win32/syssetup/install.c:619 (InstallReactOS))> <setup.exe:1099 (base/setup/setup/setup.c:107 (WinMain))> <setup.exe:133c (lib/mingw/main.c:78 (main))> <setup.exe:124d (lib/mingw/crt1.c:228 (__mingw_CRTStartup))> <setup.exe:128f (lib/mingw/crt1.c:262 (WinMainCRTStartup))> <kernel32.dll:1a8bd (dll/win32/kernel32/process/create.c:68 (BaseProcessStartup))> <00000000> kdb:> I haven't tested the RosBE 4.1.2 build yet. Thanks, James

18 years, 4 months

1
1
0 0

Are we changing official compiler?

by Samuel serapion

There has been much talk about different GCC versions in #reactos. So i just want a clear straight answer. Do we need a vote? are we waiting for something/someone to give the go ahead? What version is RosBuild using? Are we moving to a new recommended compiler?!? -- encoded Samuel Serapión Vega Computer Engineering, Polytechnic University of Puerto Rico.

18 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hyperion] 25617: * _ReadBarrier, _WriteBarrier: defined as aliases for _ReadWriteBarrier. Alas * __emul, __emulu: fixed to specify instruction length suffix * __rdtsc: removed "__volatile__" attribute from the inline asm. Hyperion recommends you fix your goddamn code instead * __emul, __emulu, __rdtsc, __readmsr, __readpmc: return 64-bit values with the "=A" constraint instead of horrible kludge

by Alex Ionescu

hyperion(a)svn.reactos.org wrote: > Author: hyperion > * __rdtsc: removed "__volatile__" attribute from the inline asm. Hyperion recommends you fix your goddamn code instead Congrats, you just broke ReactOS... did you even test this change, or did you just assume that the "goddamn code sucks"? Even if it did, you should've fixed it before breaking the OS. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 4 months

1
0
0 0

Boot Failure with Revision 25126

by James Tabor

Hi, On real hardware. Thanks, James (ntoskrnl/kd/kdio.c:193) ----------------------------------------------------- (ntoskrnl/kd/kdio.c:194) ReactOS 0.4-SVN (Build 20061211-r25124) (ntoskrnl/kd/kdio.c:195) Command Line: DEBUGPORT=COM1 (ntoskrnl/kd/kdio.c:199) ARC Paths: multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)partition(1) \ReactOS\ (ntoskrnl/ke/i386/cpu.c:502) Not handling AMD caches yet Used memory 1015744Kb (ntoskrnl/se/semgr.c:41) FIXME: SeAccessCheck has been HACKED to always grant access! (ntoskrnl/se/semgr.c:42) FIXME: Please fix all the code that doesn't get proper rights! (ntoskrnl/ke/clock.c:92) FIXME: TIMER UPDATE NOT DONE!!! (ntoskrnl/ke/i386/kiinit.c:41) Your machine supports PGE but ReactOS doesn't yet. WARNING: HaliQuerySystemInformation at hal/halx86/generic/sysinfo.c:26 is UNIMPLEMENTED! (ntoskrnl/ke/i386/patpge.c:62) Your machine supports PAT but ReactOS doesn't yet. (ntoskrnl/ke/i386/cpu.c:745) Your machine supports XMMI exceptions but ReactOS doesn't (ntoskrnl/io/iomgr/driver.c:901) Driver 'buslogic.sys' load failed, status (c0000001) (drivers/storage/atapi/atapi.c:3145) AtapiInterrupt(): reading overrun data! (drivers/storage/atapi/atapi.c:3145) AtapiInterrupt(): reading overrun data! (drivers/storage/atapi/atapi.c:3145) AtapiInterrupt(): reading overrun data! (drivers/storage/atapi/atapi.c:3145) AtapiInterrupt(): reading overrun data! (drivers/storage/atapi/atapi.c:3145) AtapiInterrupt(): reading overrun data! ,,,,,,,,on and on......

18 years, 4 months

1
1
0 0

Re: [ros-dev] ros development tasks as student thesis works?

by Murphy, Ged (Bolton)

Eduard Glatz wrote: > Now the question arised > if there would be an interest in student thesis works > as contributions to the reactos project. > > An overview of thesis works completed in the area of > systems software can be found under: > > http://windows.hsr.ch/studienarbeiten.html Many of the listed topic areas are either not relevant or too advanced for ReactOS to support at the moment. > If there is an interest in such contributions then > we will have to discuss next the type of suitable tasks. If the standard of work is high enough, i.e. if the student(s) are proficient in C and NT programming, then there would certainly be great interest from the ReactOS project in something like this. However, even if the standard of work was not particularly high, we would still encourage people to try and we would help in any way we could (or were permitted to). The only concern from submitting low quality work would be that it may not make it into the final ReactOS source code. A few good examples of things we are looking for are listed in our 2006 Google Summer of Code page. Two good contributions we received from this was a Windows clipboard implementation and Remote Desktop. Some suggestions are: - Network card drivers - mmc.exe replacement - printer spooler support - Explorer theming - a choice of directx dlls - bug fixing or improvements to a large choice of operating system components. - choosing existing win32 software, and ensuring ReactOS has the relevant support to run it. e.g. Apache, Ms Office, Photoshop, AutoCAD Hope this helps. Ged.

18 years, 4 months

1
0
0 0

ros development tasks as student thesis works?

by Eduard Glatz

Hello all, at our university we are offering thesis works for computer science students in several areas of interest. Many of those works result in contributions to existing open source projects or even initiate new ones. My interests are in the area of operating systems. Now the question arised if there would be an interest in student thesis works as contributions to the reactos project. An overview of thesis works completed in the area of systems software can be found under: http://windows.hsr.ch/studienarbeiten.html Unfortunatley those descriptions are only in german. But at least many of the english titles give you an indication what the tasks were. If there is an interest in such contributions then we will have to discuss next the type of suitable tasks. Kind regards, Edy Eduard Glatz, Prof. Dipl.-Ing. University of Applied Sciences HSR (Hochschule Rapperswil) Department of Computer Sciences (Abt. Informatik) Oberseestr. 10; 8640 Rapperswil; Switzerland; www.hsr.ch

18 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dcote] 25570: =================================================================== ntoskrnl/fsrtl/fastio.c =================================================================== Fixed @implemented/@unimplemented tags =================================================================== Index: ntoskrnl/cc/mdl.c =================================================================== Fixed a comment.

by Peter Ward

The ======== lines and stating the files that are modified are not really needed and come out bad in the IRC channel (files modified are already stated anyway). Regards Peter dcote(a)svn.reactos.org wrote: > Author: dcote > Date: Mon Jan 22 00:01:57 2007 > New Revision: 25570 > > URL: http://svn.reactos.org/svn/reactos?rev=25570&view=rev > Log: > =================================================================== > ntoskrnl/fsrtl/fastio.c > =================================================================== > Fixed @implemented/@unimplemented tags > > =================================================================== > Index: ntoskrnl/cc/mdl.c > =================================================================== > Fixed a comment. > > Modified: > trunk/reactos/ntoskrnl/cc/mdl.c > trunk/reactos/ntoskrnl/fsrtl/fastio.c > > Modified: trunk/reactos/ntoskrnl/cc/mdl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/cc/mdl.c?rev=2557… > ============================================================================== > --- trunk/reactos/ntoskrnl/cc/mdl.c (original) > +++ trunk/reactos/ntoskrnl/cc/mdl.c Mon Jan 22 00:01:57 2007 > @@ -34,7 +34,7 @@ > > /* > * NAME INTERNAL > - * CcMdlReadCompleteDev@8 > + * CcMdlReadComplete2@8 > * > * DESCRIPTION > * > > Modified: trunk/reactos/ntoskrnl/fsrtl/fastio.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/fastio.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/fsrtl/fastio.c (original) > +++ trunk/reactos/ntoskrnl/fsrtl/fastio.c Mon Jan 22 00:01:57 2007 > @@ -77,6 +77,9 @@ > } > > > +/* > + * @implemented > + */ > BOOLEAN > NTAPI > FsRtlCopyRead(IN PFILE_OBJECT FileObject, > @@ -244,6 +247,9 @@ > } > > > +/* > + * @implemented > + */ > BOOLEAN > NTAPI > FsRtlCopyWrite(IN PFILE_OBJECT FileObject, > @@ -715,6 +721,9 @@ > return FALSE; > } > > +/* > + * @implemented > + */ > BOOLEAN > NTAPI > FsRtlMdlReadComplete(IN PFILE_OBJECT FileObject, > > > >

18 years, 4 months

1
0
0 0

Crash

by hto＠mail.cnt.ru

// ntoskrnl/lpc/send.c NtRequestWaitReplyPort(...) { ... if (Callback) { ... } else { ... Thread->LpcReplyMessage = NULL; ... } ... LpcpReplyWait(...); // now Status == STATUS_USER_APC ... Message = Thread->LpcReplyMessage; ... if (Status == STATUS_SUCCESS) { ... } else { ... LpcpFreeToPortZone(Message, TRUE); ... } ... } // ntoskrnl/lpc/close.c LpcpFreeToPortZone(...) { ... if (!IsListEmpty(&Message->Entry)) // crash { ... } ... } // ntoskrnl/include/internal/lpc_x.h #define LpcpReplyWait(s, w) \ { \ ... \ Status = KeWaitForSingleObject(...); \ ... \ }

18 years, 4 months

2
1
0 0

Re: [ros-dev] NtGdiPie, NtGdiEllipse

by Murphy, Ged (Bolton)

P.s. it might help if I attached the app I mentioned ;) James Tabor wrote: > I have some arc code but it's not tested and I really want to finish this ASAP! After someone mentioned the state of the radio buttons the other day, I had a quick look at it. Our user32 code draws them pretty well (with one or two mods) As we're swapping test apps, I've attached one comparing the Windows and ROS variants. The problem ultimately comes down to NtGdiPie, NtGdiEllipse. If you don't have any updates to these 2 functions, I'll look at them when I get chance. > Here is a test program. Guess what part doesn't work? They all look pretty good, but strangely, they all appear to draw 1 pixel larger than the Windows version. Does the Windows code draw slightly undersize? Ged.

18 years, 4 months

1
0
0 0

Re: [ros-dev] NtGdiPie, NtGdiEllipse

by Murphy, Ged (Bolton)

James Tabor wrote: > I have some arc code but it's not tested and I really want to finish this ASAP! After someone mentioned the state of the radio buttons the other day, I had a quick look at it. Our user32 code draws them pretty well (with one or two mods) As we're swapping test apps, I've attached one comparing the Windows and ROS variants. The problem ultimately comes down to NtGdiPie, NtGdiEllipse. If you don't have any updates to these 2 functions, I'll look at them when I get chance. > Here is a test program. Guess what part doesn't work? They all look pretty good, but strangely, they all appear to draw 1 pixel larger than the Windows version. Does the Windows code draw slightly undersize? Ged.

18 years, 4 months

1
0
0 0

NtGdiPie, NtGdiEllipse

by Murphy, Ged (Bolton)

FAO JimT (or anyone else who may have secret fixes in their tree, Filip ;) ) Do you have any improvements to the mentioned functions. They need attention/improvement to improve the drawing of some of our UI controls. Don't wanna double up on work if someone already has something on this. Cheers, Ged.

18 years, 4 months

2
1
0 0

Broken Build

by Grant A. Brady

I have just tried to compile the current trunk and it was broken. I am using the latest trunk with the latest ROS Build. Grant A. Brady CIP Way too Much Fun Productions Email: Bragrsibak(a)gmail.com Email: WTMFP1(a)gmail.com Current project: Console Suite -- This email may or may not contain a virus. I really don't know because it was Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.13/632 - Release Date: 1/16/2007 4:36 PM

18 years, 5 months

2
1
0 0

Yet another VM

by Klemens Friedl

I read in the news that a new virtual machine software got released under GNU GPL v.2 (dual license) today (2007-01-15). It's called VirtualBox (VirtualBox.org) and is partly based on qemu code. On of the advantages are that it support Intel's VT (vanderpool), run as GUI app on Win and Unix and support WinNT 6 without glitches (as heise.de says). News entry and review (both in german): http://www.heise.de/newsticker/meldung/83680 http://www.heise.de/open/artikel/83678 Heise.de said it is ready to compete with the latest versions of VMware, Parallels and VirtualPC. If that statement is based on facts or not and if it is a good reliable tool; I don't know as I have not tested it myself, as I am busy right now. I just posted it here, as it might be useful for someone. Klemens

18 years, 5 months

4
4
0 0

Re: [ros-dev] Yet another VM

by Nathan Lane

I'll probably get another weird email from the postmaster for this, but it is sufficient to me to say that the GPL allows commercial ventures to include code without the requirement of making the product open source. There are a few rules though - and I'm not the one to ask about those, but I know of many companies that include GPL code in their product without the need to make their product open source. Nathan -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: Tuesday, January 16, 2007 8:41 AM To: ReactOS Development List Subject: Re: [ros-dev] Yet another VM Colin Finck wrote: > Thanks for the information. > > This VM seems to be very good. > I also did not test it, but looked at the screenshots: VirtualBox supports > multiple snapshots and the closed-source version, which is also available at > no price for personal use, also supports USB devices. You can connect to > virtual machines over RDP and the virtual USB ports will also be available > through RDP. > The closed-source version also has some unique features like mounting iSCSI > targets as virtual disks. AFAIK no other Workstation virtualization product > supports this at the moment. > > In my opinion, we should support VirtualBox as a new testing platform for > ReactOS, since it contains more features than QEMU and is open-source unlike > VMware. > It would also be easier to use for new users, who did not run a PC emulator > before. > > Regards, > > Colin It's funny how you're all going on about how good it is without even having tested it. QEmu supports multiple snapshots as well, as it does USB, and it's fully open source. QEmu supports named pipes, mounting raw hard drives and any other disk that Windows can see, audio, networking etc. So I don't think it contains anywhere near as many features as QEMU, especially since most of the advanced ones you mentionned are *not* Open Source. I'm also quite curious on how they were able to take QEMU (a GPL product) and add USB support under closed source (which QEMU already has as GPL). Sounds like a bunch of hacks to me. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

18 years, 5 months

1
0
0 0

A small patch

by Grant A. Brady

I noticed a small problem with ROS's calculator; it was missing 8 pixels from the bottom in both normal and scientific modes. This lead to the calculator appearing chopped off at the bottom and looking rather bad. Here is a small patch fixing it. Grant A. Brady A.K.A bragr p.s. Here is the unmodified ROS calculator compared to Microsoft's on Windows XP: http://wtmfp.boldlygoingnowhere.org/calcs.png -- This email may or may not contain a virus. I really don't know because it was checked with Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007 4:12 PM

18 years, 5 months

2
1
0 0

Re: [ros-dev] ROS Livecd issue

by Mikhail Y. Zvyozdochkin

Felipe Villarroel wrote: >On 1/5/07, Muguntharaj Subramanian <mugunth(a)gmail.com> wrote: > > >>... >>partition signature != 55AA >>... >> >> >You have a corrupted MBR or partition table. Reinstall ReactOS and do >proper partitioning. > > Hm, Hm... It's not so simply. I got same error with _fresh-installed_ ReactOS. WBR, DarkHobbit

18 years, 5 months

6
7
0 0

desk.cpl

by Timo Kreuzer

Hi, So of you might already know that I have been working on desk.cpl appearance page patch for some time. (bugzilla #1732, but I have already some more local changes/fixes) Eric Kohl is working on the same area now, so I'd like to talk about it with him, so we will not do the same work twice. I could not contact him so far. so if you read this, Eric, please reply, or if someone can contact him, please tell him. Thanks, Timo

18 years, 5 months

1
0
0 0

Hello Everybody

by Erkal DİNÇER

Hello Everybody, I am Erkal from Istanbul, Turkey. I am a C/C++ developer generally coding on Windows. I have a deep experience of C and C++ coding in fields like networking, 3D graphics, GUI programming. I want to be part of ReactOS development team. I'd like to start with localizing ReactOS for Turkey. There were no Turkish keyboard DLL's. I think it may be a good entrypoint. As an excited newbie, I am waiting for your valuable advices and directions. Best regards, Erkal Dinçer http://www.ibsyazilim.com IBS, İstanbul Bilgi İletişim Sistemleri Tic. ve San. A.Ş İstanbul Teknik Üniversitesi, Teknokent Arı 1 Binası No:6 34469 Maslak- İstanbul Tel : +90 212 328 26 26 Fax : +90 212 328 25 94 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

18 years, 5 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 25352: My first commit! NtGdiExtTextOut: - Unlock dc if failed - Copy string from usermode using MmCopyFromCaller

by Thomas Weidenmueller

MmCopyFromCaller is deprecated! Use probing and SEH instead. All Code using MmCopyFromCaller or MmCopyToCaller should be fixed, these APIs should no longer be used for new code. tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Mon Jan 8 00:18:34 2007 > New Revision: 25352 > > URL: http://svn.reactos.org/svn/reactos?rev=25352&view=rev > Log: > My first commit! > NtGdiExtTextOut: > - Unlock dc if failed > - Copy string from usermode using MmCopyFromCaller > > Modified: > trunk/reactos/subsystems/win32/win32k/objects/text.c

18 years, 5 months

1
0
0 0

bugzilla (bugs and some suggestions)

by Timo Kreuzer

Hi, Bugs in bugzilla: - There are still some bugs in bugzilla. you cannot view a single attachment, you can only view them all together. This is because the link doesn't include the attachment id. Same for diff and edit. - When trying to edit a patch from the view all page, you will see the reactos.org main page inside the edit window, wich is probably a similar bug. - Searching doesn't work anymore from the main page Enhancements: - Add VMWare Server to "Hardware" list - Compontenst: we currently have Documentation, Drivers, Kernel, Networking, Patches, Setup, Shell, sound, Win32 We should add Applications, Services, Tools, Subsystems, maybe unknown, if you don't know where the bug is located. Maybe also add bugzilla to Web Services component list. - Maybe a flag for regression would be nice - A flag for "3rd party comaptiblity" would also be nice, so we see, if the bug is effecting ROS itself or "only" a 3rd party app. Greetings, Timo

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Murphy, Ged (Bolton)

Why are you trying to partition a vmware drive? The correct way to setup vmware is to create a virtual disk (a few 100Mb will do) and allocate the space for this drive upon creation. You then install ROS into this. ROS needs to play no part in creating partition, it only needs to format the partition created by vmware. ROS is quite stable in vmware and qemu at the moment. -----Original Message----- From: Muguntharaj Subramanian [mailto:mugunth@gmail.com] Sent: 09 January 2007 07:18 To: ReactOS Development List Subject: Re: [ros-dev] ROS Livecd issue Hi All, I checked out the source again yesterday and built a fresh iso (bootcd). And again i find the same issue i.e "partition signature != 55AA" error while trying out the created iso with VMware. Has anybody else tried the same way? My objective is to compile the reactos iso from source first. Then plan to add applications and try to fix some bugs in my free time. For that i feel its better to use VMware instead of running fresh install (also i dont have spare machine to do fresh installation). Is the current builds working in QEMU? Regards, Mugunth On 1/8/07, Mikhail Y. Zvyozdochkin <mzvyozd(a)narod.ru <mailto:mzvyozd@narod.ru> > wrote: Felipe Villarroel wrote: >On 1/5/07, Muguntharaj Subramanian < mugunth(a)gmail.com <mailto:mugunth@gmail.com> > wrote: > > >>... >>partition signature != 55AA >>... >> >> >You have a corrupted MBR or partition table. Reinstall ReactOS and do >proper partitioning. > > Hm, Hm... It's not so simply. I got same error with _fresh-installed_ ReactOS. WBR, DarkHobbit _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev <http://www.reactos.org/mailman/listinfo/ros-dev> -- http://mugunth.blogspot.com <http://mugunth.blogspot.com> http://thamizha.com <http://thamizha.com> http://tamilblogs.com <http://tamilblogs.com> -- http://webspace2host.com <http://webspace2host.com> "Your friendly hosting provider"

18 years, 5 months

1
0
0 0

Important News and Updates

by Alex Ionescu

Dear ReactOS Users, Testers and Developers, I've chosen to write up a small letter with some recent news on ReactOS' development. I'm hoping that putting my name behind it will increase the number of people interested and informed. - First of all, a small update on the kernel. I'm currently working on Ob, the Object Manager. I have a large patch that I've split up into 4. The first patch addresses several bugs and adds more security paths and checks that will be required for later functionality. The second patch adds some lacking functionality to the Object Manager which might have caused bugs in the I/O Manager. The third patch adds locking and scalability improvements to the Object Manager, and fixes multiple race conditions which could've led to random crashes. The last patch should cleanup and remaining bugs/fixmes apart from non-implemented but not-critical functionality. After this is done, I plan on working in the Kernel itself to make sure that ReactOS boots on VMWare 6.0 and VMWare Server 1.1 (my current Vmware testing platforms). I generally use KQEMU, so VMWare bugs are usually hidden from me. I also have a nice piece of code from one of our older developers (blight/Gregor Anich) which should allow me to fix Mesa, aka OpenGL. After these low-level regressions have been fixed, I will then commit my new LPC code, and start working on cleaning up some old Ex code. These changes will basically make ReactOS more compatible and reliable, by auditing for broken code. - Secondly, on the topic of regression testing. I'm hoping most of you are now using the official RosBE, the ReactOS Building Environment. If you're not, please do so (on Windows). It is the *only* supported environment. If you're having problems with headers, compiling, or are seeing boot failures, please do not come to ask us for help until you are using the RosBE. This will help us avoid many compiler incompatibilities and make us bettter able to help you in a timely fashion. Because such problems can also arise from badly configured emulators, I will create the RosTE, or ReactOS Testing Environment. This will be a packaged version of KQEMU along with several helpful utilities and scripts, which will allow you to mount and unmount your qemu image, use make_install properly, use make install_registry properly, test ReactOS and the LiveCD/BootCD in the latest patched QEMU with the KQEMU Accelerator module in full-kernel mode (an improvement of 4x+ over standard QEMU), as well as the Serial Port Redirection Gateway which will allow you to get qemu's output in a telnet box with unlimited easy scrolling, as well as the ability to copy/paste text from it, which is normally impossible with QEMU. This version will also support using WinDBG to debug ReactOS, when our kernel implements Kd. In the end, the RosBE and RosTE should make it a lot easier to identify the source of some common problems experienced by testers. I cannot offer a similar TE for VMWare unfortunately, since that's a commercial product, and VMWare still offers an interesting testing framework because it behaves differently from QEmu in many ways. However, if you have an issue in VMWare, I strongly suggest you then try out to reproduce it in RosTE, once it will be available. That way, we'll be able to isolate the bug to an emulator. - I have been invited as a speaker to multiple conferences this year, where I will have a chance to talk about, and present ReactOS, in hopes of making stronger ties with the FOSS community, raise awareness for the project, and get more developers/support. One of them is the SOCAL 2007 Expo in Los Angeles in Feburary this year, and another one is the Intertional Free Software Forum in April, in Brazil. There also remains the possibility of other such expos. Because these conferences are not commercial, even speakers do not usually have their air fare or hotel costs covered. As I am a student, travel fare to these places makes a large dent in my savings, since a single conference alone can cost me 1500$ or more including air travel, hotel, food, transporation, etc. As a result, your donations would be greatly appreciated. The ReactOS Foundation should start an official fundraiser tomorrow or later this week as soon as the new webpage is properly working. I urge you to donate and help me out so that I can have the chance to promote ReactOS. Additionally, the money you donate will also help ReactOS with bandwidth costs, server upgrades, etc, so it's not a personal Alex fund. - Finally, Aleksey made some suggestions on my behalf recently, as well as posted some requests. I will re-address the latter here, because these are really important to me: 1) Someone please look at rbuild's dependency code and make it output a dependency tree, that can be read by a human. This should let me see things such as "oh ok, ntdll needs libfoo, and libfoo needs libbar". Or "oh, this 10KB application requires a 100MB library, can we do something better here?". 2) Someone please look at rbuild's XML parsing and "Component/module" creation so that it is possible to build an entire directory as a component. For example, "make drivers" should work, as well as "make base". - That's all, thank you for your time. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 5 months

2
1
0 0

Re: [ros-dev] ROS Livecd issue

by Alex Ionescu

hto(a)mail.cnt.ru wrote: >>IIRC, partitioning is broken in ROS, so you have to >>create the partition with something different than >>the ReactOS installer. I'd guess FreeDOS should work. > > > There is temporary patch to broken partitioning code: > www.reactos.org/bugzilla/attachment.cgi?id=1181&action=view > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > I don't think that's where the bug is... I'm going to write a test driver that calls the ROS and the Windows function and compare the results. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 5 months

1
0
0 0

ROS Livecd issue

by hto＠mail.cnt.ru

> IIRC, partitioning is broken in ROS, so you have to > create the partition with something different than > the ReactOS installer. I'd guess FreeDOS should work. There is temporary patch to broken partitioning code: www.reactos.org/bugzilla/attachment.cgi?id=1181&action=view

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by David Ianno

Hello, You need to change the bootup device options in the BIOS from the harddisk to the cdrom and run the bootcd again. Regards, David Ianno (Quip) Muguntharaj Subramanian <mugunth(a)gmail.com> wrote: On 1/5/07, Felipe Villarroel <fvillarroels(a)gmail.com> wrote: Hi, > Can you please explain this. Where exactly I have to make changes? Different timings and different memory locations could hide (or show) problems. You need to build bootcd. (mingw32-make bootcd) you can set DBG to 1 in config.rbuild to compile with debug messages. (based on config.template.rbuild). Boot your virtual machine with the created bootcd (ReactOS.iso, created after sucessful compilation), and install ReactOS on a virtual disk (> 200MiB should be good). (I'm assuming that you have the free VMware Server) Hi Felipe Villarroel, I have set the following in rbuild.conf <property name="DBG" value="1" /> And have successfully built bootcd (ReactOS.iso). When I tried it using vmware, I get the following error: partition signature != 55AA what could be the reason? How to get more information, where can i get the logs? Regards, Mugunth good luck, Logan_V8 -- http://mugunth.blogspot.com http://thamizha.com _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by David Hinz

IIRC, partitioning is broken in ROS, so you have to create the partition with something different than the ReactOS installer. I'd guess FreeDOS should work. Greets, David Hinz Felipe Villarroel schrieb: > On 1/5/07, Muguntharaj Subramanian <mugunth(a)gmail.com> wrote: >> When I tried it using vmware, I get the following error: >> >> partition signature != 55AA >> >> what could be the reason? How to get more information, where can i get the >> logs? >> > You have a corrupted MBR or partition table. Reinstall ReactOS and do > proper partitioning. For logs you have to redirect your virtual serial > port, look at the wiki for information. > > Best regards, > Logan_V8 > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Felipe Villarroel

On 1/5/07, Muguntharaj Subramanian <mugunth(a)gmail.com> wrote: > > When I tried it using vmware, I get the following error: > > partition signature != 55AA > > what could be the reason? How to get more information, where can i get the > logs? > You have a corrupted MBR or partition table. Reinstall ReactOS and do proper partitioning. For logs you have to redirect your virtual serial port, look at the wiki for information. Best regards, Logan_V8

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Muguntharaj Subramanian

On 1/5/07, Felipe Villarroel <fvillarroels(a)gmail.com> wrote: > > Hi, > > Can you please explain this. Where exactly I have to make changes? > Different timings and different memory locations could hide (or show) > problems. > You need to build bootcd. (mingw32-make bootcd) > you can set DBG to 1 in config.rbuild to compile with debug messages. > (based on config.template.rbuild). > Boot your virtual machine with the created bootcd (ReactOS.iso, > created after sucessful compilation), and install ReactOS on a virtual > disk (> 200MiB should be good). (I'm assuming that you have the free > VMware Server) Hi Felipe Villarroel, I have set the following in rbuild.conf <property name="DBG" value="1" /> And have successfully built bootcd (ReactOS.iso). When I tried it using vmware, I get the following error: partition signature != 55AA what could be the reason? How to get more information, where can i get the logs? Regards, Mugunth good luck, > Logan_V8 > -- http://mugunth.blogspot.com http://thamizha.com

18 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mbosma] 25290: Make Downloader perform better un der ReactOS: - Use other font. - Redraw buttons at resize.

by Murphy, Ged (Bolton)

mbosma(a)svn.reactos.org wrote: > ResizeControl(hApps, Split_Vertical+5, 60, > LOWORD(lParam)-10, Split_Hozizontal); > + RECT Rect = {Split_Vertical+5, Split_Hozizontal+5, > LOWORD(lParam)-10, HIWORD(lParam)-50}; > DescriptionRect = Rect; C++ hiccup

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Felipe Villarroel

Hi, > Can you please explain this. Where exactly I have to make changes? Different timings and different memory locations could hide (or show) problems. You need to build bootcd. (mingw32-make bootcd) you can set DBG to 1 in config.rbuild to compile with debug messages. (based on config.template.rbuild). Boot your virtual machine with the created bootcd (ReactOS.iso, created after sucessful compilation), and install ReactOS on a virtual disk (> 200MiB should be good). (I'm assuming that you have the free VMware Server) good luck, Logan_V8 On 1/4/07, Muguntharaj Subramanian <mugunth(a)gmail.com> wrote: > > > On 1/4/07, Felipe Villarroel <fvillarroels(a)gmail.com> wrote: > > Hi, > > sometimes trunk is unstable, but have you tried to install bootcd in a > > disk image instead?. > > Try to select ReactOS (debug) in Freeloader, instead of the ReactOS > > entry. Sometimes the debug messages make it works. > > Hi Felipe Villarroel, > Thanks for your reply. > > Can you please explain this. Where exactly I have to make changes? > > Regards, > Mugunth > > > If the current bootcd/livecd doesn't work, try again in a few days. > > > > Best regards, > > Logan_V8 > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Murphy, Ged (Bolton)

Muguntharaj Subramanian wrote: > Then I tried using this ReactOS-LiveCD.iso > using VMware installed in another Linux Machine. > It progresses upto ReactOS splash screen, then stops responding. > What could be the issue? Am I missing something? Livecd in trunk is broken, use the bootcd instead. There is no need to use a livecd in vmware anyway.

18 years, 5 months

1
0
0 0

Re: [ros-dev] ROS Livecd issue

by Muguntharaj Subramanian

On 1/4/07, Felipe Villarroel <fvillarroels(a)gmail.com> wrote: > > Hi, > sometimes trunk is unstable, but have you tried to install bootcd in a > disk image instead?. > Try to select ReactOS (debug) in Freeloader, instead of the ReactOS > entry. Sometimes the debug messages make it works. Hi Felipe Villarroel, Thanks for your reply. Can you please explain this. Where exactly I have to make changes? Regards, Mugunth If the current bootcd/livecd doesn't work, try again in a few days. > > Best regards, > Logan_V8

18 years, 5 months

1
0
0 0

ROS Livecd issue

by Muguntharaj Subramanian

Dear All, I am newbie to this list.This is my first post. I came to know about reactos recently. And tried reactos vmware image and was very much impressed. I would like to thank all of you who have been involved in this project. I tried my hand in building ReacOS Livecd today. I used WindowsXP machine to build this. Followed the steps given in these URLs: http://www.reactos.org/wiki/index.php/HOWTO/setup_a_build_environment_for_W… http://www.reactos.org/wiki/index.php/Building_ReactOS I used GCC 3.4.5 ReactOS build Environment and successfuly built ReactOS-LiveCD.iso in about 45 Minutes time. Then I tried using this ReactOS-LiveCD.iso using VMware installed in another Linux Machine. It progresses upto ReactOS splash screen, then stops responding. What could be the issue? Am I missing something? Regards, Mugunth -- http://mugunth.blogspot.com http://thamizha.com

18 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [mbosma] 25283: Do not show "Press any key to boot from CD"-Message if there is no MBR on the hard drive.

by Klemens Friedl

(forwarded for maarten bosma) > [03 Jan 07 16:03] * Morpheouss * i am here just to say, that change made in 25283 revision is not accurate > [03 Jan 07 16:04] * Morpheouss * it was introduced in windows 2000, and it fails when user have installed OS, MBR is not written, and OS is bootable... > [03 Jan 07 16:05] * Morpheouss * eg. i use Linux and grub to boot it up > [03 Jan 07 16:05] * Morpheouss * and windows 2000 doesn't show this message and boots up > [03 Jan 07 16:05] * Morpheouss * even if i wanted to boot linux > [03 Jan 07 16:06] * Morpheouss * so i don't think it was a good idea > [03 Jan 07 16:06] * Morpheouss * sometimes when i install windows i forget to eject CD :P > [03 Jan 07 16:06] * Morpheouss * it was better done in my opinion > [03 Jan 07 16:07] * Morpheouss * when user could control it even MBR is not written > [03 Jan 07 16:09] * Morpheouss * in my opinion it should be reverted Please comment. > Author: mbosma > Date: Wed Jan 3 17:33:41 2007 > New Revision: 25283 > > URL: http://svn.reactos.org/svn/reactos?rev=25283&view=rev > Log: > Do not show "Press any key to boot from CD"-Message if there is no MBR on the hard drive. > > Modified: > trunk/reactos/boot/freeldr/bootsect/isoboot.asm > > Modified: trunk/reactos/boot/freeldr/bootsect/isoboot.asm > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/bootsect/isob… > ============================================================================== > --- trunk/reactos/boot/freeldr/bootsect/isoboot.asm (original) > +++ trunk/reactos/boot/freeldr/bootsect/isoboot.asm Wed Jan 3 17:33:41 2007 > @@ -139,13 +139,21 @@ > jmp .kbd_buffer_test > .kbd_buffer_empty: > > - ; Check if there is harddisk > + ; Check for MBR on harddisk > pusha > - mov ax, 0800h > + mov ax, 0201h > mov dx, 0080h > + mov cx, 0001h > + mov bx, trackbuf > int 13h > popa > - jc .boot_cdrom > + jc .boot_cdrom ; could not read hdd > + > + push ax > + mov ax, word [trackbuf] > + cmp ax, 0 > + je .boot_cdrom ; no boot sector found (hopefully there are no weird bootsectors which begin with 0) > + pop ax > > ; Display the 'Press key' message and wait for a maximum of 5 seconds > call crlf

18 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25261: Adding stubed arm4 fo r my CpuToIntel tool. Now we got tree diffent arch we can port over to in tel x86 asm. But this tool are experment tool

by Murphy, Ged (Bolton)

Timo Kreuzer wrote: > Doesn't this break build of rosapps on linux? no > I thought everything has to be lower case(?) Nothing _needs_ to be lower case. The problem you're referring to is that Linux file names are case sensitive, where Windows isn't. This causes problem in Linux when rbuild files have the opposite case to the actual file. This normally flags up issues in asm files and resource files, e.g asm.S / asm.s En.rc / en.rc > Greetings and Happy New Year, And you ;) Ged.

18 years, 5 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25261: Adding stubed arm4 for my CpuToIntel tool. Now we got tree diffent arch we can port over to intel x86 asm. But this tool are experment tool

by Michael Fritscher

> Author: greatlrd > Date: Mon Jan 1 16:37:24 2007 > New Revision: 25261 > > URL: http://svn.reactos.org/svn/reactos?rev=25261&view=rev > Log: > Adding stubed arm4 for my CpuToIntel tool. > Now we got tree diffent arch we can port over to intel x86 asm. But this > tool are experment tool > > Modified: > trunk/rosapps/devutils/cputointel/CpuToIntel.c > trunk/rosapps/devutils/cputointel/cputointel.rbuild > > Modified: trunk/rosapps/devutils/cputointel/CpuToIntel.c I miss the new files ;) Hehe, perhaps reactos once boots up my psion 5 *g* Happy new year to all! mifritscher

18 years, 5 months

2
1
0 0

Little Off-Topic: Happy New Year!

by Felipe Villarroel

Hi!, I just wanted to say Happy New Year to everyone that works or likes ReactOS!. I hope that this new year will be better than 2006 for you and your family and that the changes in ReactOS will reflect the great and hard work of each of the developers that contribute to the project. I hope that 2007 will be a great year for ReactOS. Best Regards, Logan_V8

18 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25246: do not use hacked vfat drv revers the 25243 the hacked do not delete pendling or incomplte data and so on,

by Aleksey Bragin

Magnus, I beg my pardon, but since when is it allowed to revert someone else's commit without discussing first? There is a rule which might allow revert provided: 1) The change breaks booting 2) More than 24hours passed from the commit time 3) Author can not be contacted by any means None of the above was true, so why did you make a reverting commit? With the best regards, Aleksey Bragin. On Dec 30, 2006, at 4:11 AM, greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sat Dec 30 04:11:14 2006 > New Revision: 25246 > > URL: http://svn.reactos.org/svn/reactos?rev=25246&view=rev > Log: > do not use hacked vfat drv revers the 25243 > the hacked do not delete pendling or incomplte data > and so on, > > Modified: > trunk/reactos/drivers/filesystems/vfat/cleanup.c > trunk/reactos/drivers/filesystems/vfat/close.c > trunk/reactos/drivers/filesystems/vfat/create.c >

18 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25236: freetype cache glyth patch pass last all my test.patch ogrinal author of this patch is royce3, modify by tinus so it work again with trunk, ThePhysicist (timo dot kreuzer at web dot de) did fix the last bugs in it. at last long leave freetype glyth patch, now we got faster text output in reactos. and I where up to 38fps in winquake with this patch (debugbuild + serial debug on). This is very fast. I wonder what speed it give in release build or qemu now. See issue

by Alex Ionescu

greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Fri Dec 29 03:09:54 2006 > New Revision: 25236 > > URL: http://svn.reactos.org/svn/reactos?rev=25236&view=rev > Log: > freetype cache glyth patch pass last all my test.patch > ogrinal author of this patch is royce3, modify by tinus so it work again with trunk, ThePhysicist (timo dot kreuzer at web dot de) did fix the last bugs in it. at last long leave freetype glyth patch, now we got faster text output in reactos. and I where up to 38fps in winquake with this patch (debugbuild + serial debug on). This is very fast. I wonder what speed it give in release build or qemu now. > > I think you should remove the hits++ and misses++ and hits > 100/misses >100 code because it seems perf-debugging related only. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 5 months

1
0
0 0

Wrong place to ask I know - I logged in about a week ago, now I can't log in

by Nathan Lane

So I logged in and registered my user name about a week ago with ReactOS, and now I am unable to log in. I tried resetting my password on the site, and it still won't let me log in. Can you direct me to information on how I can get logged in, or what may have happened? Thanks, Nathan

18 years, 6 months

1
0
0 0

Re: [ros-dev] Discussion: Release policy changes

by Murphy, Ged (Bolton)

Ged Murphy wrote: > > *lots of things* > As there were no responses, I'm assuming everyone was relatively happy with the proposed system. The lack of action isn't doing ROS any favours though, the 0.3.1 release has been promised on various news sites for 31st December, and we haven't even branched for it yet!! I'm prepared to help kick start this new release system off, if it'll help to stop ROS going for another year without releasing. I propose we pick the most stable recent release, branch it and prepare for a Dec 31st release according to the new release system. If everyone is in agreement, I'll start making the necessary arrangements. Ged.

18 years, 6 months

3
2
0 0

A few ideas requiring discussion

by Aleksey Bragin

Hello, there are a few ideas I would like to get feedback about: 1) iBrowser. Do we need it nowadays in the tree, when we have firefox working? 2) In order to slightly decrease a load to our build servers, Alex proposes to build Debug version without any optimizations at all, thus increasing compilation speed. For regression testing, release builds should be used, since release builds are the most sensitive to possible errors. 3) RBuild improvement - the "components bundles" concept should be (re)introduced: if I type "make <directory name>", I would like to get all components inside that directory to be built. 4) Dependency map of ReactOS - maybe this should be implemented inside of RBuild too. Dependency map is a tree, which shows how modules depend from each other. Fortunately, we don't need to do this by hand, since we can use rbuild's parsers/etc. Output format of the map - open for suggestions. If someone feels he is able to do point 3 or 4 - this is greatly appreciated, and will help development of ReactOS. With the best regards, Aleksey Bragin.

18 years, 6 months

4
3
0 0

Discussion: Release policy changes

by Aleksey Bragin

Hello, I'd like to hear opinions regarding the change in release policy. The proposition: Release happens on a strict time basis, like once per month. That means, at the end of the month we look for the best revision inside this month (probably which is closer to the end of the month), branch from it, apply all fixes (if any), and release. Disadvantage: a few coming releases' quality will be overall lower, there might be things like 0.3.25 (if release frequency is set too high, and this is not a disadvantage actually). Advantages: in the long run quality goes up, more developers due to higher release rate, more publicity, people will finally realize it's an alpha product, more bugs reported, no signs of a dead project (I doubt there are healthy projects doing 1 release per year :)). Any thoughts are appreciated. With the best regards, Aleksey Bragin.

18 years, 6 months

8
9
0 0

The first newsletter

by Dana Burkart

Okay, I'm in the middle of composing a test newsletter that will hopefully be accepted. I would like all the developers to respond to this with a short description of what they're currently working on so I can be as accurate as possible in that section of it (and I don't want to forget anyone). Thank you.

18 years, 6 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [silverblade] 25108: Further stubbing of Kernel Streaming APIs (corrective path fix to follow...)

by Alex Ionescu

silverblade(a)svn.reactos.org wrote: > ============================================================================== > --- trunk/reactos/drivers/multimedia/drmk/drmk.def (added) > +++ trunk/reactos/drivers/multimedia/drmk/drmk.def Sun Dec 10 07:16:35 2006 > @@ -1,0 +1,12 @@ > +; > +; Exports definition file for drmk.sys > +; > + > +EXPORTS > +DrmAddContentHandlers@12 > +DrmCreateContentMixed@12 > +DrmDestroyContent@4 > +DrmForwardContentToDeviceObject@12 > +DrmForwardContentToFileObject@8 > +DrmForwardContentToInterface@12 > +DrmGetContentRights@8 > > Added: trunk/reactos/drivers/multimedia/drmk/drmk.rbuild We're so going to get slashdotted/hated for this :) -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25049: [AUDIT] Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed. If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation.

by Thomas Weidenmueller

> If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation. There's no way such a transfer could be legally backed if the person who owns the copyright doesn't agree with it. - Thomas

18 years, 6 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [mist] 25062: ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil. == A20 Gate and the Keyboard Controller == In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as i

by Aleksey Bragin

Thanks to these bugfixes, ReactOS now boots on Intel Macs (I tested it on Intel Core Duo MacMini), and in Parallels virtual machine. With the best regards, Aleksey Bragin. On Dec 4, 2006, at 6:00 PM, mist(a)svn.reactos.org wrote: > Author: mist > Date: Mon Dec 4 18:00:11 2006 > New Revision: 25062 > > URL: http://svn.reactos.org/svn/reactos?rev=25062&view=rev > Log: > ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil.

18 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 25001: allow the Americans their incorrect spellings and add a correct UK resource file ; )

by Alex Ionescu

gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Thu Nov 30 22:23:19 2006 > New Revision: 25001 > > URL: http://svn.reactos.org/svn/reactos?rev=25001&view=rev > Log: > allow the Americans their incorrect spellings and add a correct UK resource file ;) > We (Canadians) also know how to spell properly :) en-CA please! -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 6 months

9
11
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25049: [AUDIT] Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed. If this person doesn't contact me before finish of the audit, the copyright will

by Ged Murphy

On 12/4/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote: > > > If this person doesn't contact me before finish of the audit, the > copyright will be transferred to ReactOS Foundation. > > There's no way such a transfer could be legally backed if the person who > owns the copyright doesn't agree with it. I'm glad you said that, I was thinking the exact same thing but was gonna check before I posted anything. Ged.

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [arty] 25028: Partially unregress python 2.4 installer.

by Alex Ionescu

> Modified: branches/arty-stable/reactos/ntoskrnl/ps/process.c > URL: http://svn.reactos.org/svn/reactos/branches/arty-stable/reactos/ntoskrnl/ps… > ============================================================================== > --- branches/arty-stable/reactos/ntoskrnl/ps/process.c (original) > +++ branches/arty-stable/reactos/ntoskrnl/ps/process.c Sun Dec 3 13:42:35 2006 > @@ -560,6 +560,8 @@ > /* Create or Clone the Handle Table */ > ObpCreateHandleTable(Parent, Process); > > + memset(&Process->VadRoot, 0, sizeof(Process->VadRoot)); > + > /* Set Process's Directory Base */ > MmCopyMmInfo(Parent ? Parent : PsInitialSystemProcess, > Process, > > > Please use RtlZeroMemory in the kernel. Please keep in mind the compartmentalization of the kernel for large objects. Such a line should go somewhere like MmInitailizeXxx for the process. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 6 months

2
1
0 0

Greek keyboard layout

by stud1281＠freemail.gr

Hello guys. Sorry for bothering you again but can someone pls commit my Greek keyboard layout file? I want it to be included to version 0.3.1 - which I suppose will be available soon - so that we can have a true Greek character support with punctuation issues and other stuff. The link is the following http://www.reactos.org/bugzilla/show_bug.cgi?id=1831 And a screenshot with proof of it in action is here http://img148.imageshack.us/my.php?image=greekku9.jpg Thnx in advance!

18 years, 6 months

1
0
0 0

Gdi function Polygon

by Timo Kreuzer

Hi, Recently I have started reading Feng Yuan - Windows Graphics Programming Win32 GDI and found that this is a very interesting part of Windows / ReactOS I'd like to take a closer look to. I started to have a look at this when I noticed 2 things, that made my desk.cpl don't work correctly in ROS: 1.) SetDCPenColor is not implemented (I am currently working on a usermode implemenatation, I have finished GetDCPenColor, GetDCBrushColor is the same, Set... will follow soon.) 2.) Polygon() didn't work as expected. I used it to draw a tiny triangle on a button, but it doesn't look correct. I first thought it was because the triangle was simply too small (didn't show the lowest pixel), but it was because it is redirected to NtGdiPolygon. (instead of calling NtGdiPolyPolyDraw, wich is the way it works in windows. NtGdiPolygon doesn't seem to exist in Windows, so it seems it's currently only a Kernelmode implementation of Polygon and NtGdiPolyPolyDraw seems not to be implemented in ROS yet). Polygon is exspected to automatically close the polygon, but NtGdiPolygon doesn't do this. I will have a closer look on this later and hope I can fix this. My questions: Is there a reason it doesn't do it? Should the closing of the Polygon (simply by adding the first coordinates at the end?) be done in the usermode function (wich is not existing yet) or in the current implementation in win32k? Looking at the gdi code I found out that some things (handle validation for example) seem to be different than in windows. F.e. the reuse counter seems to be ignored. I have written a small GdiTest app to analyse the diffences between Win and ROS (General app is ready, I will write test functions soon, maybe tomorrow) . I'll start by writing some test cases, that I think might fail on ROS. If there's someone who likes to help me writing tests I'd really appreaciate that, just let me know. Then there's another thing that I thought about: Windows has one list of gdiobjects shared between kernel and all processes, although handles are only valid for the process that has created them (only Stockobjects are global). That seems to be a bad idea, I didn't try it yet, but what if a usermode app zeroes out the complete gdi handle table? I guess Windows would crash. And there might be more dangoerous risks, because of that. So why is the table not implemented locally? Some thoughts: Global handle list: + less memory needed - big chance of crashing windows by usermode apps Local handle list - more memory needed + better chance of paging the memory (global list would never be paged as it is always in use) + no chance for a user app to crash windows or crash other apps by messing up the handle table + no more need to veryfy the process member in the handle table entry A shared memory section seems to be a real risky thing. It's big enough to put binary data there and it might be possible to make another process with higher privaliges execute that code.I first thought of the DC's AbortProc, but that is probaly handled by the kernel to not exceed user limits(?). Implementing the handle table locally would not beak any APIs. Only some system apps that use the GdiQueryTable and directly use the table would experience a slightly different behaviour: Only locally created handles would be accessable. Would there be a problem doing that? At last my usermode implementation of GetDCPenColor, I would like some feedback: #define GDI_HANDLE_UPPER_MASK 0xffff0000 #define GDI_HANDLE_GET_UPPER(h) \ (((ULONG_PTR)(h)) & GDI_HANDLE_UPPER_MASK) COLORREF GetDCPenColor(HDC hDC) { PGDI_TABLE_ENTRY pEntry = GdiHandleTable + GDI_HANDLE_GET_INDEX(hGdiObj); if(pEntry->KernelData != NULL) { ULONG Upper = GDI_HANDLE_GET_UPPER(hGdiObj) if ( Upper == GDI_HANDLE_GET_UPPER(pEntry->Type) && GDI_HANDLE_GET_TYPE(Upper) == GDI_OBJECT_TYPE_DC ) { if((HANDLE)((ULONG_PTR)pEntry->ProcessId & ~0x1) == CurrentProcessId) { DC_ATTR* pDCData = (DC_ATTR*)pEntry->UserData if(pDCData) { return pDCData->crPenClr; } } } } return CLR_INVALID; }

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 24951: - mea culpa - hominem est erratum

by Thomas Weidenmueller

> - mea culpa > - hominem est erratum which means? Unfortunately only a tiny fraction of all people can read Latin ;) - Thomas

18 years, 6 months

2
1
0 0

Tr: Re: [Winpcap-users] [Installer] Architecture detection ?

by Sylvain Petreolle

Thanks, adding this value set to x86 made the WinPcap installer start. I wonder where we should set this. Since ReactOS has only x86 for now, I guess we can add it to the default registry set (hivesys.inf) Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com

18 years, 6 months

1
0
0 0

Resource files

by stud1281＠freemail.gr

Hi guys. Can anyone take care of the resource files we have added to bugzilla? It's been long time since a commit was made for these ones. Thnx in advance

18 years, 6 months

2
1
0 0

ReactOS Newsletter

by Samuel serapion

I have been an active member of the ReactOS community for some time now. I discovered this project a few months before the 0.2.9 release and was instantly amazed by the smart people and amount of hard work that has gone into this project now spanning a decade. Everyone knows me in #reactos by the name "encoded". Qualifications: - I compile and test ros almost every day, report bugs and participate in developer discussions. - I'm an amature coder, student of computer engineering(www.pupr.edu) - I like to program(a lot), so I understand what's going on pretty well. - I also know a bit of HTML. Goals for the newsletter: Not just the "there where commits about this and that this week" type of publication, I want to write articles about how foo.dll and bar feature work in windows, their current state in ROS. I want to create a medium which gives people outside the close nit ReactOS community a sense of belonging, that sparks the interest of coders and people in general. A medium that actually reflects the current state of affairs in ros, tips, tricks, how tos and even recent bugs and regressions! Note: -I am a full time student and also have a job, so I would prefer a bi-weekly newsletter, but could also work in a weekly time frame if needed. -Those nice little articles about foo.dll and bar features will be dependant(specially the ros side of it) on devs helping out in writing them. -I LOVE REACTOS!!!

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 24848: i386BootDrive and i386BootPartition are ULONGs, and before saving a byte value they must be zeroed. Thanks to Magnus for identifying the problem.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Mon Nov 27 00:46:45 2006 > New Revision: 24848 > > URL: http://svn.reactos.org/svn/reactos?rev=24848&view=rev > Log: > i386BootDrive and i386BootPartition are ULONGs, and before saving a byte value they must be zeroed. Ever heard of movzx? -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 24834: 1. revers 24831 to 24833 userenv.h does not exists in ms psdk and shall move to folder include/ndk or include/reactos 2. do not create new private header, we already have one, but it is in wrong folder. 3. This header should have been move long time ago. 4. do not doing #include "userenv-priv.h" it will not found the header in syssetup/install

by Aleksey Bragin

I wish Magnus would mention that this commit ALSO includes patch from bug #1837. WBR, Aleksey Bragin. On Nov 26, 2006, at 1:39 PM, greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sun Nov 26 13:39:50 2006 > New Revision: 24834 > > URL: http://svn.reactos.org/svn/reactos?rev=24834&view=rev > Log: > 1. revers 24831 to 24833 userenv.h does not exists in ms psdk and > shall move to folder include/ndk or include/reactos > 2. do not create new private header, we already have one, but it is > in wrong folder. > 3. This header should have been move long time ago. > 4. do not doing #include "userenv-priv.h" it will not found the > header in syssetup/install > > > Removed: > trunk/reactos/dll/win32/userenv/userenv-priv.h > Modified: > trunk/reactos/dll/win32/syssetup/install.c > trunk/reactos/dll/win32/syssetup/syssetup.rbuild > trunk/reactos/dll/win32/userenv/precomp.h > trunk/reactos/dll/win32/userenv/userenv.rbuild > trunk/reactos/drivers/input/i8042prt/mouse.c > trunk/reactos/include/psdk/userenv.h > > Modified: trunk/reactos/drivers/input/i8042prt/mouse.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/input/ > i8042prt/mouse.c?rev=24834&r1=24833&r2=24834&view=diff > ====================================================================== > ======== > --- trunk/reactos/drivers/input/i8042prt/mouse.c (original) > +++ trunk/reactos/drivers/input/i8042prt/mouse.c Sun Nov 26 > 13:39:50 2006 > @@ -903,6 +903,9 @@ > UCHAR Value; > UCHAR ExpectedReply[] = { 0xFA, 0xAA, 0x00 }; > unsigned ReplyByte; > + ULONG Counter; > + > + I8042Flush(); > > if (! I8042Write(DevExt, I8042_CTRL_PORT, 0xD4) || > ! I8042Write(DevExt, I8042_DATA_PORT, 0xFF)) > @@ -915,7 +918,12 @@ > ReplyByte < sizeof(ExpectedReply) / sizeof(ExpectedReply[0]) > && Ok; > ReplyByte++) > { > - Status = I8042ReadDataWait(DevExt, &Value); > + Counter = 200; > + > + do { > + Status = I8042ReadDataWait(DevExt, &Value); > + } while (Status == STATUS_IO_TIMEOUT && Counter--); > + > if (! NT_SUCCESS(Status)) > { > DPRINT1("No ACK after mouse reset, status 0x%08x\n", >

18 years, 6 months

1
0
0 0

Weekly newsletter author

by Dana Burkart

I have been following the ReactOS project for a while now, and would like to write your newsletters for you. Qualifications: - I have enough time to write the newsletter once a week. - English is my first language, and I can write fairly well. - I like to program in my free time, so I understand what's going on pretty well. - I don't know if I can do the IRC, though. - I also know HTML. If I am not picked, that's alright, I just wanted to help you guys out... I would help out with the actual project, but I don't think my programming skill is that advanced.

18 years, 6 months

1
0
0 0

Boot Crash in Usb

by James Tabor

Hi, Real hardware, svn 24795, (ntoskrnl/fstub/disksup.c:1618) (drivers/network/ndis/ndis/hardware.c:112)(NdisMQueryAdapterResources) No allocated resources! (drivers/network/ndis/ndis/miniport.c:1424)(NdisIPnPStartDevice) MiniportInitialize() failed for an adapter. (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\System32\drivers\usbehci.sys (Status 0xc0000034) (ntoskrnl/io/pnpmgr/pnpmgr.c:2372) Initialization of service usbehci failed (Status c0000034) (drivers/usb/usbport/usbcore.c:15) Miniport 0x81239618 registered (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x8122E2B8, 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: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 48 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 1: 80F01114 80EFC2F0 (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/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x8122F458, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 2: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 52 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 3: 80F01114 80EFC2F0 (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/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x812302A8, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 4: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 56 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 5: 80F01114 80EFC2F0 (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:3a2b9 (ntoskrnl/io/iomgr/irp.c:1084 (IofCallDriver))> <ntoskrnl.exe:3f99b (ntoskrnl/io/pnpmgr/pnpmgr.c:941 (IopInitiatePnpIrp))> <ntoskrnl.exe:40455 (ntoskrnl/io/pnpmgr/pnpmgr.c:1750 (IopActionInterrogateDeviceStack))> <ntoskrnl.exe:40177 (ntoskrnl/io/pnpmgr/pnpmgr.c:969 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:4018c (ntoskrnl/io/pnpmgr/pnpmgr.c:983 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:401ae (ntoskrnl/io/pnpmgr/pnpmgr.c:1008 (IopTraverseDeviceTree))> <ntoskrnl.exe:418f7 (ntoskrnl/io/pnpmgr/pnpmgr.c:2543 (IopInvalidateDeviceRelations))> <ntoskrnl.exe:39a25 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:256a6 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:6cc92 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:76fc2 (ntoskrnl/ke/i386/ctxswitch.S:258 (KiThreadStartup@156))> Okay so I did not update the new hives yet,,, so I did,,, (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 2001d. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 1d ServerID: 2 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x100000)! (base/system/winlogon/sas.c:88) RegOpenKeyEx() failed with error 2 (ntoskrnl/ps/process.c:686) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 0. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 0 ServerID: 0 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x60000, desired 0xf0001)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0xe)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0xe)! (subsystems/win32/csrss/api/wapi.c:132) CSR: CsrpHandleConnectionRequest: Handling: 00B3FF98 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:192) CSR: CsrpHandleConnectionRequest done (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 6. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 6 ServerID: 0 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x20000, desired 0x2000f)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x60000, desired 0x1f0001)! (drivers/base/bootvid/bootvid.c:278) Waiting for bootvid thread to finish. (drivers/base/bootvid/bootvid.c:281) Bootvid thread to finish. (./subsystems/win32/win32k/objects/dc.c:324) No InstalledDisplayDrivers value in service entry found (./subsystems/win32/win32k/objects/dc.c:479) FindDriverFileNames failed (dll/ntdll/ldr/utils.c:1197) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2022) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2022) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (ntoskrnl/mm/freelist.c:1209) Zeroed 239724 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 16 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 16 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/cm/registry.c:733) Hive is still in use (hc 0, rc 5) (ntoskrnl/cm/ntfunc.c:2784) CmiDisconnectHive() failed (Status c0000001) (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x100000)! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 2002c. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 2c ServerID: 2 (ntoskrnl/mm/freelist.c:1209) Zeroed 12 pages. ./subsystems/win32/win32k/ntuser/focus.c:205 ./subsystems/win32/win32k/ntuser/focus.c:92 (ntoskrnl/mm/freelist.c:1209) Zeroed 24 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 972 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 480 pages. System locked up with, EnableUserModePnpManager() Failed! Rebooting now! and a OK button. Ha ha real funny! Now can the joker but it back so it will work. James

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 24792: Remove the obsolete STDCALL decorations from .def files.

by Alex Ionescu

ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Mon Nov 20 00:17:42 2006 > New Revision: 24792 > > URL: http://svn.reactos.org/svn/reactos?rev=24792&view=rev > Log: > Remove the obsolete STDCALL decorations from .def files. I love you? I was JUST talking to Aleksey on how MSVC builds won't be linkable if this doesn't work. Please do this to every single .def file if you have time. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 6 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [ion] 24773: - MSVC VCPROJ Maker: * Don't insert NDEBUG as a define, files define this manually already. * Don't add _CRT flags, since the RTM WDK defines them properly. * Force warning.h to be i ncluded just like the WDK does. * Disable WP

by Murphy, Ged (Bolton)

ion(a)svn.reactos.org wrote: > - Please remember that you NEED the WDK 6000 RTM installed to > use MSVC for building ReactOS. Don't change global build > settings just because you were too lazy to download it and > think that because your Win32 app doesn't need it, it's ok to > break other people's native/system/kernel/hal builds. Change > it locally if you're lazy, but don't revert these changes again. I highly dissagree that we should break building of usermode code in MSVC just because someone doesn't have 1 header file which is included with the WDK. If it effects the building of HAL etc so much, then it should be a requirement for those components only, not for wingui/win32dll code. Maybe including a similar header into our own code is a more viable option. Ged.

18 years, 7 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [ion] 24767: - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem o

by Reuel ben Yisrael

ion(a)svn.reactos.org wrote: > Author: ion > Date: Thu Nov 16 10:09:37 2006 > New Revision: 24767 > > URL: http://svn.reactos.org/svn/reactos?rev=24767&view=rev > Log: > - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem on my machine with GCC 3.4.5. It is my hope it will do the same for everyone. This is a nasty bug, either stack related or some critical structure is being damaged. I am breaking trunk because it's been here for a long time, but now I found a way to repro it so that we can work together to try finding it. In a way, trunk was always broken, but this patch should force a freeze. Please help. > > Modified: > trunk/reactos/lib/rtl/registry.c > > Modified: trunk/reactos/lib/rtl/registry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/registry.c?rev=247… > ============================================================================== > --- trunk/reactos/lib/rtl/registry.c (original) > +++ trunk/reactos/lib/rtl/registry.c Thu Nov 16 10:09:37 2006 > @@ -94,6 +94,11 @@ > } > > /* And now append the path */ > + DPRINT1("I'm about to crash due to an overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > if (Path[0] == L'\\' && RelativeTo != RTL_REGISTRY_ABSOLUTE) Path++; // HACK! > Status = RtlAppendUnicodeToString(&KeyName, Path); > if (!NT_SUCCESS(Status)) return Status; > Where's # 6? I only see 5.. LOL

18 years, 7 months

1
0
0 0

Trunk is in frozen state

by Aleksey Bragin

Hello, trunk is frozen from any commits except for fixing that error mentioned in the last commit message ("ndis"-bug). Thanks for understanding, Aleksey Bragin.

18 years, 7 months

1
0
0 0

freetype cache

by Timo Kreuzer

Hi, Some time ago, I have done a small fix to make the freetype chache work. It still had the display bug with the original author (tinus) already experienced. I have fixed it now. As far as I have tested it is working correctly. And it speeds up text output by about 300%. Maybe someone should take a look at it. Bugzilla #511 Greetings, Timo

18 years, 7 months

3
4
0 0

Some feedback on ReactOS from LiveJournal

by Craig Talbert

http://community.livejournal.com/reactos/2373.html

18 years, 7 months

1
0
0 0

Re: [ros-dev] 0.3.1

by Murphy, Ged (Bolton)

Aleksey Bragin wrote: > There is an undecided problem: should we rebranch 0.3.1 or release it > as it is. I prefer rebranching from trunk, but that involves heavy > bugfixing of trunk, which I want to see any way. I don't know the state of 0.3.1 at the moment, but from what I remember it was quite stable. Why don't we just spend a day testing it to be sure and then release RC1. 0.3.2 could be branched directly after the 0.3.1 release. Ged.

18 years, 7 months

2
1
0 0

0.3.1

by Murphy, Ged (Bolton)

Any update on its progress? Release cycle speed doesn't seem to have improved since our last bungled attempt.

18 years, 7 months

2
1
0 0

ReactOS doesn't boot

by Justin Haygood

Under Virtual PC 2007, ReactOS r24721 (as well as the last few over the last few days) simply do not boot. Boot CD: Boots, installs under text mode, stops when switching to GUI mode, has ntoskrnl.dll error in debug mode Live CD: Never finishes booting. Compiler: RosBE 0.3.1 (GCC 3.4.5) Does it boot for anyone else? If so, I'll attempt to figure out a way to get it to boot.

18 years, 7 months

5
6
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 24722: KbdLayerDescriptor is a STDCALL function.

by Aleksey Bragin

Actually "@X" were removed from all .def files to maintain compatibility with MSVC compiler, and GCC will do this silently with "--enable-stdcall-fixup" (which didn't work for some reason when enabled a few month ago). WBR, Aleksey Bragin. On Nov 11, 2006, at 11:33 PM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat Nov 11 23:33:06 2006 > New Revision: 24722 > > URL: http://svn.reactos.org/svn/reactos?rev=24722&view=rev > Log: > KbdLayerDescriptor is a STDCALL function. > -=skip=- > Modified: trunk/reactos/dll/keyboard/kbdbe/kbdbe.def > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/keyboard/ > kbdbe/kbdbe.def?rev=24722&r1=24721&r2=24722&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/keyboard/kbdbe/kbdbe.def (original) > +++ trunk/reactos/dll/keyboard/kbdbe/kbdbe.def Sat Nov 11 23:33:06 > 2006 > @@ -4,5 +4,5 @@ > LIBRARY kbdbe.dll > > EXPORTS > -KbdLayerDescriptor > +KbdLayerDescriptor@0 > ;EOF -=skip=-

18 years, 7 months

2
1
0 0

Codefreeze

by Aleksey Bragin

Hello, as you might have already noticed I took the chance while upgrading SVN server to 1.4.0 and creating a mirror to effectively set it to readonly state for now. The blocker bug is the stack corruption issue, which somewhen (though rather frequently, but to be fully sure one needs at least 10 boots) results in "IoPageWrite() failed" during setup. Herve already took a lot of time to try to track down the revision number of the regression, however I'm not aware of his recent achievements. I would like to ask everyone (especially those who wants to become testers :) ) to please help and find the revision number which has this regression. Further commits can go only when this is fixed (the concept of bootable trunk). WBR, Aleksey Bragin.

18 years, 7 months

1
2
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 24722: KbdLayerDescriptor is a STDCALL function.

by Reuel ben Yisrael

> Modified: trunk/reactos/dll/keyboard/kbddv/kbddv.def > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/keyboard/kbddv/kbddv.d… > ============================================================================== > --- trunk/reactos/dll/keyboard/kbddv/kbddv.def (original) > +++ trunk/reactos/dll/keyboard/kbddv/kbddv.def Sat Nov 11 23:33:06 2006 > @@ -1,8 +1,8 @@ > ; > ; ReactOS Operating System > ; > -LIBRARY kbddvorak.dll > +LIBRARY kbdv.dll > > Did you mean "LIBRARY kbddv.dll"?

18 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 24711: - implement a GuiRunOnce sect ion for unatttended setup - with this we launch programs after 3rd boot ( programs / scripts) - another a little step for sysreg :)

by Murphy, Ged (Bolton)

janderwald(a)svn.reactos.org wrote: > > + if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, > + _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce"), > + 0, > + KEY_SET_VALUE, > + &hKey) != ERROR_SUCCESS) > + { > + DPRINT1("Error: failed to open HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\n"); There's a HKCU typo in the debug print. Also, is this the correct place to be storing this info? Ged.

18 years, 7 months

1
0
0 0

Re: [ros-dev] 24701: set most of trunk svn property eol-style:native

by Martin Fuchs

On 08.11.2006 11:49:19 janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Wed Nov 8 14:47:44 2006 > New Revision: 24701 > URL: http://svn.reactos.org/svn/reactos?rev=24701&view=rev > Log: > set most of trunk svn property eol-style:native Please revert this change (or part of it): It's plain wrong to set eol-style:native for files of type *.dsp, *.dsw, *.vcproj, *.sln and some other files like chinese resource scripts. Thanks, Martin -- Martin Fuchs fuchs.martin(a)gmail.com

18 years, 7 months

1
0
0 0

Cannot build trunk with multi-processor support enabled.

by David Ianno

Hello, I tried to to build trunk (rev.24696) with MP=1, but it doesn't build. ntoskrnl\ke\ipi.c:27:2: #error VerifyMe! ntoskrnl\ke\ipi.c: In function `KiIpiSendRequest': ntoskrnl\ke\ipi.c:37: warning: implicit declaration of function `Ke386TestAndSetBit' ntoskrnl\ke\ipi.c:53:2: #error VerifyMe! ntoskrnl\ke\ipi.c:102:2: #error VerifyMe! ntoskrnl\ke\ipi.c: In function `KiIpiServiceRoutine': ntoskrnl\ke\ipi.c:108: warning: implicit declaration of function `Ke386TestAndClearBit' ntoskrnl\ke\ipi.c:147:2: #error Not yet implemented! mingw32-make: *** [obj-i386\ntoskrnl\ke\ipi.o] Error 1 Regards, David (Quip) --------------------------------- Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.

18 years, 7 months

1
0
0 0

Website

by Ge van Geldorp

After wiping the "old" reactos.org box (the one at IP 130.161.165.129) and reinstalling Apache so I can use it for other projects I found that there are still some hostnames referring to the "old" box: links.reactos.org reactos.de reactos.pl www.reactos.de www.reactos.pl For the moment, I've set up redirection for (www.)reactos.de/.pl to www.reactos.org/?lang=de/pl and I have reloaded the scripts for links.reactos.org. I will terminate that service at the end of the month, so please update DNS before that. The critical one is links.reactos.org. The getfirefox applet will download Firefox using the link http://links.reactos.org/getfirefox. The script behind that URL will redirect to the "real" Firefox download location. This was done so it was possible to update the script to newer Firefox versions when they became available, without the need to recompile and redistribute getfirefox. Same thing is happening for the Mozilla ActiveX control. When links.reactos.org doesn't work anymore, this means getfirefox and the automatic Mozilla ActiveX download will cease to work. I assume the scripts were transferred already during the website move, if not I can provide them. Oh, and please fix the alias for root(a)www.reactos.org, it still points to my email address. I'm not interested in receiving that mail, a little while ago there was an error in a script somewhere, causing it to send me an email every ten minutes, 24 hours per day.... If there's a need to communicate about this, please email me directly, after this email gets through I'm unsubscribing again. Gé van Geldorp.

18 years, 7 months

1
0
0 0

Re: [ros-dev] Vote for a code freeze.

by Murphy, Ged (Bolton)

Richard wrote: > I believe it's time to do a code freeze. +1 I've stopped working on ReactOS as it's instability is frustrating. Ged.

18 years, 7 months

11
14
0 0

Re: [ros-dev] Vote for a code freeze.

by Murphy, Ged (Bolton)

Brandon Turner wrote: > > D. Hazelton wrote: > > (I once thought I might be able to help, but I am not used > to writing C++ for > > low-level interfaces - for those I've always used C) > > > > DRH > > > > > Good thing our whole kernel and system lib set is in C. ;) > Pretty much the entire operating system ..... Lol

18 years, 7 months

1
0
0 0

we are back online

by Magnus Olsen

Hi everyone have notice ReactOS website, svn, mailing list, went down. The svn and web server was never down the problem was the DNS server whent down by hardware failour and it took time getting it back online again. Longer that we did expect.

18 years, 7 months

2
2
0 0

Code Auditing 100% Complete

by Nate DeSimone

Hi everyone, I noticed that the code audit is now finished. Cheers!

18 years, 7 months

4
4
0 0

Rev 24626 Breaks Linux Build

by James Tabor

I've tried fixing this! 8^( include/psdk/winnt.h line 3666 is the orig. [CC] subsystems/win32/win32k/dib/dib1bpp.c In file included from subsystems/win32/win32k/w32k.h:16, from subsystems/win32/win32k/dib/dib1bpp.c:20: include/ddk/ntifs.h:404: error: redeclaration of `enum _AUDIT_EVENT_TYPE' include/ddk/ntifs.h:405: error: conflicting types for 'AuditEventObjectAccess' include/psdk/winnt.h:3666: error: previous definition of 'AuditEventObjectAccess' was here include/ddk/ntifs.h:407: error: conflicting types for 'AuditEventDirectoryServiceAccess' include/psdk/winnt.h:3668: error: previous definition of 'AuditEventDirectoryServiceAccess' was here

18 years, 7 months

4
3
0 0

Re: [ros-dev] [ros-diffs] [ion] 24636: - Add NtApphelpCacheControl, NtFilterToken (WARNING: PATENTED. TAKE CARE WHEN IMPLEMENTING). - Add all the recently added functions to their proper place in the NDK.

by Reuel ben Yisrael

ion(a)svn.reactos.org wrote: > Author: ion > Date: Tue Oct 24 01:19:15 2006 > New Revision: 24636 > > URL: http://svn.reactos.org/svn/reactos?rev=24636&view=rev > Log: > - Add NtApphelpCacheControl, NtFilterToken (WARNING: PATENTED. TAKE CARE WHEN IMPLEMENTING). > I'm assuming that the warning is in reference to NtFilterToken(). If someone other than you goes to implement this function, they probably won't look through svn history to see this comment. Wouldn't it be best to put a warning like this in the comments of the function source?

18 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ion] 24595: - Implement DbgkpQueueMessage. This is the main bi-directional communication routine for the newer non-LPC Debug Object. - Implement DbgkPostFakeProcessCreateMessages (and stub DbgkpPostFakeThreadMessages and DbgkpPostFakeModuleMessages). These are required when attaching to a process after threads have been created and modules loaded, so that the debugger can have a valid state. - Still missing the two functions to Set/Clear the Debug Object, will do these next.

by Thomas Weidenmueller

> - RtlCopyMemory(StateChange, > + /* Return our wait state change structure */ > + RtlMoveMemory(StateChange, > &WaitStateChange, > sizeof(DBGUI_WAIT_STATE_CHANGE)); RtlMoveMemory doesn't really make sense as the destination and source are never overlapping, resulting in unnecessary overhead. - Thomas

18 years, 7 months

2
3
0 0

Automated Testing

by Lucio Diaz

Aleksey Bragin wrote: "It should try every revision, otherwise there is no use from it at all. And automerge from trunk to stable branch is not possible, because patches usually depend on each other." Sorry,i explained myself wrong, i was not talking about automerging, or using the "stable branch" to send patches. No, patches would be still sent to the unstable branch, and no "automerging will be used", it will be just overwriting. The process i imagine like this: -Unestable not working. -Recent Stable working (1 day old). -You dont have the skill to fix unstable. -You download stable, work in your computer over stable. -Send changes to unstable (then things become interesting). -Check the files you are have touched. If no other person have touched them since the stable (1 day old) was made you can send your patches, if someone have touched, you cant and have to wait till the stable revision is updated. -Once unstable boot again, stable is override by the unstable, and now named stable. This would alow people working, maybe in the control panel, with little kernel or booting code knowledge, keep working without having to stop developing for dificult bugs in the kernel. What do you thing? Maybe is a crazy idea cause i dont know about the inners of SVN. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

18 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 24590: - provide a sample configurat ion file - allow other address line resolver than addr2line

by Murphy, Ged (Bolton)

> +; > +; ROSBOOT_CMD > +; > +; This value is the command which is executed to gain debugging data > +; this value is mandatory > + > +ROSBOOT_CMD=D:\sysreg\qemu\qemu.exe -serial file:debug.log > -boot c -m 128 -L D:\sysreg\qemu\ D:\sysreg\qemu\RosVM.vmdk > -cdrom D:\Reactos\ReactOS-RegTest.iso Is there scope to add vmware to the test? Ged.

18 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 24584: * beginning of a system regression tools

by Alex Ionescu

janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Fri Oct 20 19:49:46 2006 > New Revision: 24584 > > URL: http://svn.reactos.org/svn/reactos?rev=24584&view=rev > Log: > * beginning of a system regression tools > Can this be done in C? C++ only slows down the build even more. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 7 months

2
1
0 0

Re: [ros-dev] Interested in the Testing Coordinator position

by Murphy, Ged (Bolton)

I hate ugly text formatting ... Resending in a (hopefully) readable format. Jerry wrote: > After a team says that it has fixed the bug ... <snip> > Each team may have mentees associated with it. The teams would then > help and guide their mentees in testing and coding, and these mentees > will help with the work load that the regular testers have. The goal > here is to guide the mentees to be regular developers and either stay > in testing or move on to other parts of the project and have. I'm a little confused with the idea of the testing teams fixing bugs. Testers aren't usually coders. It's great if they are as they can fix the bugs they find, but in general testing positions are filled by people who want to help the project, but aren't programmers. If a tester is a programmer too, I think you'll find that do a lot more programming than testing, as shown by our tree instability at the moment ;) Ged.

18 years, 7 months

5
5
0 0

Re: [ros-dev] Interested in the Testing Coordinator position

by Murphy, Ged (Bolton)

Jerry wrote: > After a team says that it has fixed the bug ... <snip> > Each team may have mentees associated with it. The teams would then help > and guide their mentees in testing and coding, and these mentees will help > with the work load that the regular testers have. The goal here is to guide > the mentees to be regular developers and either stay in testing or move on to > other parts of the project and have. I'm a little confused with the idea of the testing teams fixing bugs. Testers aren't usually coders. It's great if they are as they can fix the bugs they find, but in general testing positions are filled by people who want to help the project, but aren't programmers. If a tester is a programmer too, I think you'll find that do a lot more programming than testing, as shown by our tree instability at the moment ;) Ged.

18 years, 8 months

1
0
0 0

Interested in the Testing Coordinator position

by Jerry

Hi, I'm interested in the Testing Coordinator position. A few ideas I have for testing in general are, 1) One step update and compile 2) Divide and conquer testing. Testing would be divided up into teams. Each team will have its own leader. Each team will be assigned (or assign themselves) a mixed slate of verified unverified bugs. After a team says that it has fixed the bug or the bug is a false positive, another team will come and verify their findings. All this activity will be logged as it happens. 3) Testing Mentor Program Each team may have mentees associated with it. The teams would then help and guide their mentees in testing and coding, and these mentees will help with the work load that the regular testers have. The goal here is to guide the mentees to be regular developers and either stay in testing or move on to other parts of the project and have. The goal of this project is to grow the 4) I will try to listen and consider any ideas that other people have and try to work with people instead of against them. If you have any questions, be free to ask. I hope to be able to serve this project better.

18 years, 8 months

1
0
0 0

Trunk stability

by Lucio Diaz

Even if i am not a developer in this proyect, may I give an advice? 1) You need two trunks, one experimental, the other 1 day old "booting trunk". 2)Your bot build the experimental trunk (you already have the build bot). 3) Once a day a "boot bot" would try boot the experimental trunk, if it is sucessful (i supouse, sending a "all ok" message throug com1) then it overwrithe the "booting trunk" with that experimental revision. 4)That way there is always a very recent trunk that is stable enough to boot, the testing is automatic, and you have quite narrowed the revisions with the problem. That way you could be working in a somewhat stable trunk, that can not be older than 1, 2 or 3 days if the experimental is failing. Best Regards, Lucio Diaz-Flores --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

18 years, 8 months

4
3
0 0

Request w/ Bounty

by sn0n

Ok, please don't shoot me if this is 'to large a request' for what im offering, or to little. But here goes.. World of Warcraft on ReactOS, w/ NVidia Drivers AND guide complete to logging in and speaking with some NPC's (from what i understand the latest wine works well with WoW as far as right clicking, correct me if im wrong) Beings as i dont know how much work will be involved, what im offering is a copy of WoW to the DevTeam, (or you can use a 10 day trial free from Blizzard) and a $50/Bounty upfront. If this amount is to low, willing to go as far as $150/total, mind you i fall under the 'student' classification. Other then the mentioned, i would also like windowed mode to work (my preferred). And i use a NVidia Card. Thank you. -- ~Rob http://sn0n.com/

18 years, 8 months

6
8
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 24553: Implement Get & Set batch limit.

by Alex Ionescu

jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Tue Oct 17 09:30:54 2006 > New Revision: 24553 > > URL: http://svn.reactos.org/svn/reactos?rev=24553&view=rev > Log: > Implement Get & Set batch limit. > > Modified: > trunk/reactos/dll/win32/gdi32/include/gdi32p.h > trunk/reactos/dll/win32/gdi32/misc/misc.c > trunk/reactos/dll/win32/gdi32/misc/stubs.c > > Modified: trunk/reactos/dll/win32/gdi32/include/gdi32p.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/gdi32/include/gd… > ============================================================================== Erm, shouldn't this be saved in the TEB? -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 8 months

2
1
0 0

[Fwd: Delivery Notification: Delivery has failed]

by Alex Ionescu

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

18 years, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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))>

18 years, 9 months

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 )

18 years, 9 months

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

18 years, 9 months

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

18 years, 9 months

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

18 years, 9 months

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

18 years, 9 months

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

18 years, 9 months

4
5
0 0

Re: [ros-dev] Command line

by Imre Leber

It seems that other people, from the FreeDOS site, are already working on the idea of making the FreeDOS utilities working as console applications on windows. There seems to be already a sourceforge project created. But I don't want to anounce the work of somebody else too much. So I'll be quiet about the rest. Making them available as windows console applications is probably best, that way they can be used in windows, reactos and FreeDOS (using the HX-DOS extender), exactly the same. People can then choose wether they want to use/bundle these with reactos. Imre >-----Original Message----- >From: Brandon Turner [mailto:turnerb7@msu.edu] >Sent: Sunday, September 3, 2006 05:58 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >Imre Leber wrote: >> A few hours ago the base part of FreeDOS version 1 was released. >> >> Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. >> >> Some of them are written in assembly and would inherently not be portable (deltree, ...). >> >> Imre >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >Well as long as windows has these application(and they have all the ones >you mentioned excluding move which is internal to cmd) they can be moved >to ReactOS\base\applications which is where we keep all these apps. >Though, we might want to stay away from the asm ones. My question is >whether we are going to do vendor drops and treat them like wine code >where we sync them back all the time and submit patches back to the >original project to get them when we sync again or whether we we are >just going to add them to the our tree? > >Either way, I can probably help in the process to move them over. > >-- >Brandon Turner >ReactOS Release Engineer >Blog: http://www.amateurgramming.com > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

1
0
0 0

Missing Network Info from CPL

by James Tabor

Hi Open network control panel,,, I have a driver installed, I can see it with explorer ntobjs. (dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only! (dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only! (dll/win32/powrprof/powrprof.c:318) (74AD0000, 1, 00000000) not fully implemented (dll/win32/powrprof/powrprof.c:318) (74AD0000, 0, 00000000) not fully implemented (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/shellord.c:821) MRU processing failed, handle zero (dll/win32/shell32/shlexec.c:1251) flags ignored: 0x00000004 (KERNEL32:dll/win32/kernel32/process/create.c:1098) Can't execute a DLL (ntoskrnl/ps/process.c:692) FIX PS SDs!! (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (dll/ntdll/ldr/utils.c:1194) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (dll/cpl/ncpa/ncpa.c:103) EnumRegKeys: RegEnumKeyEx failed for ...Ã¿ (rc 0x103) Thanks, James

18 years, 9 months

1
0
0 0

Re: [ros-dev] Command line

by Imre Leber

>-----Original Message----- >From: Brandon Turner [mailto:turnerb7@msu.edu] >Sent: Sunday, September 3, 2006 05:58 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >Imre Leber wrote: >> A few hours ago the base part of FreeDOS version 1 was released. >> >> Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. >> >> Some of them are written in assembly and would inherently not be portable (deltree, ...). >> >> Imre >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >Well as long as windows has these application(and they have all the ones >you mentioned excluding move which is internal to cmd) they can be moved >to ReactOS\base\applications which is where we keep all these apps. >Though, we might want to stay away from the asm ones. My question is >whether we are going to do vendor drops and treat them like wine code >where we sync them back all the time and submit patches back to the >original project to get them when we sync again or whether we we are >just going to add them to the our tree? > >Either way, I can probably help in the process to move them over. > Some of them I personally maintain, like diskcopy and chkdsk. I would very much like to extend this maintenance into reactos. I actually would like to volunteer for all these other tools coming from FreeDOS too. But then we do talk about fully 32/64 bit binaries that are fully aware of reactos. You could build thess from scratch for the reactos project, but I think it would be much more productive to start from an already very stable code base. Instead of maybe again spending 12 years of development. Imre >-- >Brandon Turner >ReactOS Release Engineer >Blog: http://www.amateurgramming.com > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

4
3
0 0

Re: [ros-dev] [ros-diffs] [ion] 23903: - Final cleanup for now: - main.c -> freeldr.c + cleanups and nice formatitng. - Move out variables that were in main.c to ex\init.c or cpu.c, depending. - Separate i386/kernel.c into i386/kiinit.c for X86-specific intiailization, and /krnlinit.c for portable initialization across all architectures. Also move out global variables appropriately. - main_asm.S -> cpu.S

by Alex Ionescu

ion(a)svn.reactos.org wrote: > Author: ion > Date: Mon Sep 4 01:06:30 2006 > New Revision: 23903 > - main_asm.S -> cpu.S That should've said -> boot.S. (as the change was actually done). Art, hopefully this should've all made your PPC stuff a bit easier to pan out architecturally in the kernel. These changes also made NTLDR compatibility a lot more possible (but still far away), since FREELDR-specific bootstrapping is now completely isolated (except 1 thing which will be deprecated soon enough). -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

2
1
0 0

Command line

by Imre Leber

A few hours ago the base part of FreeDOS version 1 was released. Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. Some of them are written in assembly and would inherently not be portable (deltree, ...). Imre

18 years, 9 months

3
2
0 0

Re: [ros-dev] wxwidgets

by Imre Leber

>-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Friday, September 1, 2006 01:01 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] wxwidgets > >> What is the standpoint of the reactos project on using libraries, like for >> example wxwidgets for implementing reactos software (like reactos movie >> maker)? > >This would just make the build process more complicated than neccessary, >and increase compile time and download size (sources). Tools/Applications >that come with ReactOS are not needed and expected to be ported to other >architectures. We should stick to plain Win32/64 APIs. Also C is preferred >over C++ a lot. > >> Further is there any specification that says for example "everything has >> to be compilable with mingw", or "everything has to run on i386/pentium >> xx"? > >- No other tools/libraries neccessary on the host than the minimum build >system (mingw, nasm, make) >- Only use C++ when it makes sense, prefer C (not just because g++ is so >extremely slow) >- Don't include pre-built binaries in the repository, everything needs to >be built from source code >- Don't bloat the repository with tons of huge libraries (do we still have >more than one xml library?!) >- Software that is included in the base repository should not use >frameworks for portability and use the APIs directly instead > >That's my personal opinions and doesn't neccessarily match with those of >the other developers. > Of course, I was suggesting wxWidgets since it seems that it is the closest thing to MFC, what most windows programmers would be accustomed to. That it also happens to run in linux is, of course, completely irrelevant. Imre >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

8
13
0 0

Re: [ros-dev] scope?

by Imre Leber

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > Actually, come to think of it. If dosfsck can be made to work reliably in reactos then FreeDOS chkdsk, which I wrote, should be portable to reactos, just by recompiling and rearanging some files. This is because i used the io.c file from dosfsck to port chkdsk to linux. And that also means that defrag can be recompiled the same way, since it is the same FAT manipulation code. Then only a windows interface would be needed! Actually i think I am going to add a method to defrag, that pretty much does what windows does (I think): move through the directories, and for every file that is fragmented, move it to a space where it can be store unfragmented. You could do this a number of times until a fixpoint is reached or a fixed number of times. And if you keep this up as long as defrag is running. You could build a defrag that automatically keeps all your files defragmented (as far as possible). If you want to do a full defragmentation then, maybe once a year, you would have to arrange it so that the drive became locked for the duration of the defragmentation. Imre >-- >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 > >

18 years, 9 months

1
0
0 0

Re: [ros-dev] scope?

by Imre Leber

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > This is very old code! There is DOSFSCK 2.11 now. It contains certain bugs that realy should require updating to the latest version. Imre >-- >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 > >

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 23826: Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code. but we need a C api for header to linking it right. Put the asm version to i386

by Reuel ben Yisrael

greatlrd(a)svn.reactos.org wrote: >Author: greatlrd >Date: Thu Aug 31 01:17:53 2006 >New Revision: 23826 > >URL: http://svn.reactos.org/svn/reactos?rev=23826&view=rev >Log: >Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code. > but we need a C api for header to linking it right. Put the asm version to i386 > > sure there must be away to avoid this double-function-call overhead? >+.globl _UlongByteSwap >+ >+.intel_syntax noprefix >+ >+/* FUNCTIONS ***************************************************************/ >+ >+_UlongByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov eax,[ebp+8] // load the ULONG >+ bswap eax // swap the ULONG >+ pop ebp // restore the base >+ ret > > this should work: _UlongByteSwap: mov eax,[esp+8] // load the ULONG bswap eax // swap the ULONG ret >+.globl _UlonglongByteSwap >+ >+.intel_syntax noprefix >+ >+/* FUNCTIONS ***************************************************************/ >+ >+_UlonglongByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov edx,[ebp+8] // load the higher part of ULONGLONG >+ mov eax,[ebp+12] // load the lower part of ULONGLONG >+ bswap edx // swap the higher part >+ bswap eax // swap the lower part >+ pop ebp // restore the base >+ ret > > _UlonglongByteSwap: mov edx,[esp+8] // load the higher part of ULONGLONG mov eax,[esp+12] // load the lower part of ULONGLONG bswap edx // swap the higher part bswap eax // swap the lower part ret >+_UshortByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov eax,[ebp+8] // load the USHORT >+ bswap eax // swap the USHORT, xchg is slow so we use bswap with rol >+ rol eax,16 // make it USHORT >+ pop ebp // restore the base >+ ret > > _UshortByteSwap: mov eax,[esp+8] // load the USHORT bswap eax // swap the USHORT, xchg is slow so we use bswap with rol rol eax,16 // make it USHORT ret or to save a byte... _UshortByteSwap: mov ebx,[esp+8] // load the USHORT mov al, bh mov ah, bl ret

18 years, 9 months

5
8
0 0

Re: [ros-dev] scope?

by Imre Leber

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > Maybe I should take a look then, I already once ported this to FreeDOS (not MSDOS) <small>it didn't work in MSDOS so Eric, from the other list didn't like it, so its his version that is in FreeDOS version 1</small>, so I know exactly what should be done (it's changing io.c and then it should work). Still it only works for FAT, not NTFS. Imre >-- >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 > >

18 years, 9 months

1
0
0 0

Re: [ros-dev] scope?

by Imre Leber

Well, the reason I ask is that i am also maintaining a defrag utility. It currently does FAT12, FAT16, FAT32. But it would most likely not be so difficult to change it so that it can use the reactos calls for manipulating the file system. So it also works with NTFS. It has a lot more functionality then is available in windows defrag. Like sorting directories, which I think is not possible in windows. And 5 methods of defragmenting drives. A new interface should also be easy to add. There have always been two interfaces. So the all the file system manipulation code is completely seperate. The defragmentation code already works in windows xp, on image files, because that is how i debug it with visual C++ 7.1. So, you can tell me wether this would be of interest to reactos. Imre >-----Original Message----- >From: Imre Leber [mailto:imre.leber@telenet.be] >Sent: Thursday, August 31, 2006 10:24 AM >To: ros-dev(a)reactos.org >Subject: [ros-dev] scope? > >What is actually the scope of the reactos project? > >Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)? > >Imre > > > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

4
4
0 0

PATCH - 64bit clean cabman (mostly)

by Steven Edwards

With this patch I can now build ReactOS with 64bit host gcc and not need the -m32 switch. I also tested with a 32bit gcc and cabinets still build and work properly in usetup. If someone has a better suggestion of how to fix this, please fix it. =) -- 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

18 years, 9 months

3
2
0 0

Re: [ros-dev] wxwidgets

by Imre Leber

>-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Friday, September 1, 2006 01:01 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] wxwidgets > >> What is the standpoint of the reactos project on using libraries, like for >> example wxwidgets for implementing reactos software (like reactos movie >> maker)? > >This would just make the build process more complicated than neccessary, >and increase compile time and download size (sources). Tools/Applications >that come with ReactOS are not needed and expected to be ported to other >architectures. We should stick to plain Win32/64 APIs. Also C is preferred >over C++ a lot. > >> Further is there any specification that says for example "everything has >> to be compilable with mingw", or "everything has to run on i386/pentium >> xx"? > >- No other tools/libraries neccessary on the host than the minimum build >system (mingw, nasm, make) >- Only use C++ when it makes sense, prefer C (not just because g++ is so >extremely slow) >- Don't include pre-built binaries in the repository, everything needs to >be built from source code >- Don't bloat the repository with tons of huge libraries (do we still have >more than one xml library?!) >- Software that is included in the base repository should not use >frameworks for portability and use the APIs directly instead > >That's my personal opinions and doesn't neccessarily match with those of >the other developers. > This seams reasonable. This should then be put in a specification of some sort and put on the web site. So everyone knows what they have to keep themselves to. Imre >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

1
0
0 0

wxwidgets

by Imre Leber

Hi, What is the standpoint of the reactos project on using libraries, like for example wxwidgets for implementing reactos software (like reactos movie maker)? Further is there any specification that says for example "everything has to be compilable with mingw", or "everything has to run on i386/pentium xx"? Imre

18 years, 9 months

2
1
0 0

scope?

by Imre Leber

What is actually the scope of the reactos project? Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)? Imre

18 years, 9 months

1
0
0 0

Re: [ros-dev] (Free)DOS subsystem

by Imre Leber

>-----Original Message----- >From: Myria [mailto:myriachan@cox.net] >Sent: Tuesday, August 29, 2006 10:14 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >have time. > >Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >of Win32. It runs DOS programs as Windows processes, using v86 mode to run >the programs. DPMI programs are supported by asking the kernel to allocate >LDT segments and running directly. (If you write a DOS32 program and know >the correct addresses, you can call MessageBoxW in user32.dll and it will >work.) > >This differs significantly from DOSBox, which is effectively a machine >emulator rather than an API translator. DOSEmu, in comparison, is >essentially the same design as NTVDM but for Linux. > >FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >self and is unaware that it's inside a VM. However, this doesn't work for >NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >modified, particularly because the NT kernel handles file I/O. Programs >inside the virtual DOS environment use illegal opcodes to talk to NTVDM. > FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu. The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu. What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor. For what I understood from reading a litle on the web is that it more or less works like this: You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded. When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows. ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session. Imre >Melissa > >----- Original Message ----- >From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> >To: "ReactOS Development List" <ros-dev(a)reactos.org> >Sent: Monday, August 28, 2006 14:19 >Subject: Re: [ros-dev] (Free)DOS subsystem > > >> Imre Leber wrote: >>> Hi, >>> >>> I guess i am new to this list. >>> >>> I have been a maintainer on the FreeDOS project for more then 7 years. >>> >>> I have also noticed that you are still looking into building a DOS >>> subsystem in reactos. >>> >>> After the release of FreeDOS version 1, I would like to see wether I >>> could not take up the task to having it running under reactos. >>> >>> My main idea involves using a port of DOSemu. >>> >>> Is there any documentation regarding the running of a DOS subsystem in >>> windows that I should study beforehand? >>> >>> Imre >>> >>> >> Hi Imre! >> Welcome to ReactOS! 8^D >> >> The idea is still open. >> >> We've tested Qemu under ReactOS running FreeDOS at one time and it does >> work. Another project that >> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/ >> >> >> Running a dos-subsystem and docs? Maybe one of the other developers can >> help here. You can look at >> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's >> incomplete, this would be >> your best starting point. There is allot more to it. You need to dive into >> the code and start >> reading. I do not recall any docs or books dealing with rolling your own >> subsystem. The best book >> you can get for understanding Windows or ReactOS is, Windows Internals. >> Understanding the Csrss >> subsystem would help with the os2 one. >> >> Anyway, some projects that could be good examples on how to do this, Posix >> subsystem, >> http://sourceforge.net/projects/winntposix ,and running linux bins in >> windows, >> http://sourceforge.net/projects/keow . One of our developers is currently >> working with CoLinux, >> http://www.colinux.org/ . >> >> Sorry I couldn't help you more here. >> >> Thanks, >> James >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

6
7
0 0

Re: [ros-dev] (Free)DOS subsystem

by Imre Leber

DOSemu has a 80386 emulator on board. Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that it is non-functional. But it is always easier to fix something then to restart from scratch. Imre >-----Original Message----- >From: Nate DeSimone [mailto:desimn@rpi.edu] >Sent: Wednesday, August 30, 2006 01:21 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >Not that I'm trying to rain on anyones parade, but it would be really >cool if for each program you could choose to run it in either an >emulation environment or in a V86 mode (ala WinNT NTVDM.EXE,) that way >older DOS games could be used. > >Imre Leber wrote: >>> -----Original Message----- >>> From: Myria [mailto:myriachan@cox.net] >>> Sent: Tuesday, August 29, 2006 10:14 AM >>> To: 'ReactOS Development List' >>> Subject: Re: [ros-dev] (Free)DOS subsystem >>> >>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >>> have time. >>> >>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >>> the programs. DPMI programs are supported by asking the kernel to allocate >>> LDT segments and running directly. (If you write a DOS32 program and know >>> the correct addresses, you can call MessageBoxW in user32.dll and it will >>> work.) >>> >>> This differs significantly from DOSBox, which is effectively a machine >>> emulator rather than an API translator. DOSEmu, in comparison, is >>> essentially the same design as NTVDM but for Linux. >>> >>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >>> self and is unaware that it's inside a VM. However, this doesn't work for >>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >>> modified, particularly because the NT kernel handles file I/O. Programs >>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >>> >>> >> >> FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu. >> >> The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu. >> >> What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor. >> >> For what I understood from reading a litle on the web is that it more or less works like this: >> >> You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded. >> >> When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows. >> >> ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session. >> >> Imre >> >> >> >> >>> Melissa >>> >>> ----- Original Message ----- >>> From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> >>> To: "ReactOS Development List" <ros-dev(a)reactos.org> >>> Sent: Monday, August 28, 2006 14:19 >>> Subject: Re: [ros-dev] (Free)DOS subsystem >>> >>> >>> >>>> Imre Leber wrote: >>>> >>>>> Hi, >>>>> >>>>> I guess i am new to this list. >>>>> >>>>> I have been a maintainer on the FreeDOS project for more then 7 years. >>>>> >>>>> I have also noticed that you are still looking into building a DOS >>>>> subsystem in reactos. >>>>> >>>>> After the release of FreeDOS version 1, I would like to see wether I >>>>> could not take up the task to having it running under reactos. >>>>> >>>>> My main idea involves using a port of DOSemu. >>>>> >>>>> Is there any documentation regarding the running of a DOS subsystem in >>>>> windows that I should study beforehand? >>>>> >>>>> Imre >>>>> >>>>> >>>>> >>>> Hi Imre! >>>> Welcome to ReactOS! 8^D >>>> >>>> The idea is still open. >>>> >>>> We've tested Qemu under ReactOS running FreeDOS at one time and it does >>>> work. Another project that >>>> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/ >>>> >>>> >>>> Running a dos-subsystem and docs? Maybe one of the other developers can >>>> help here. You can look at >>>> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's >>>> incomplete, this would be >>>> your best starting point. There is allot more to it. You need to dive into >>>> the code and start >>>> reading. I do not recall any docs or books dealing with rolling your own >>>> subsystem. The best book >>>> you can get for understanding Windows or ReactOS is, Windows Internals. >>>> Understanding the Csrss >>>> subsystem would help with the os2 one. >>>> >>>> Anyway, some projects that could be good examples on how to do this, Posix >>>> subsystem, >>>> http://sourceforge.net/projects/winntposix ,and running linux bins in >>>> windows, >>>> http://sourceforge.net/projects/keow . One of our developers is currently >>>> working with CoLinux, >>>> http://www.colinux.org/ . >>>> >>>> Sorry I couldn't help you more here. >>>> >>>> Thanks, >>>> James >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >>> >> >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >> > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

4
3
0 0

start

by Imre Leber

So, if nobody objects I guess i'll start porting DOSemu to reactos. After all, we need to start somewhere. And when this is done, it would be easier to talk about why it is or it is not a good replacement for ntvdm. Imre

18 years, 9 months

3
2
0 0

Re: [ros-dev] RE : Re: (Free)DOS subsystem

by Imre Leber

>-----Original Message----- >From: Sylvain Petreolle [mailto:spetreolle@yahoo.fr] >Sent: Wednesday, August 30, 2006 10:54 AM >To: 'ReactOS Development List' >Subject: [ros-dev] RE : Re: (Free)DOS subsystem > >Hi, >--- Imre Leber <imre.leber(a)telenet.be> a écrit : > >> >> DOSemu has a 80386 emulator on board. >> >> Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that >> it is non-functional. >> >> But it is always easier to fix something then to restart from scratch. >> >Like e.g. Windows ? Bad answer ;) > Windows??? Can you point me to the official download area? Imre >Kind regards, >Sylvain Petreolle (aka Usurp) >--- --- --- --- --- --- --- --- --- --- --- --- --- > > Run your favorite Windows apps with free ReactOS : http://www.reactos.org >Listen to non-DRMised Music: http://www.jamendo.com > > >Linux is not as well stable as it is told to. The proof is, mine has restarted two years ago, on the occasion of a power cut. >- H. Eychenne > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

1
0
0 0

(Free)DOS subsystem

by Imre Leber

Hi, I guess i am new to this list. I have been a maintainer on the FreeDOS project for more then 7 years. I have also noticed that you are still looking into building a DOS subsystem in reactos. After the release of FreeDOS version 1, I would like to see wether I could not take up the task to having it running under reactos. My main idea involves using a port of DOSemu. Is there any documentation regarding the running of a DOS subsystem in windows that I should study beforehand? Imre

18 years, 9 months

6
5
0 0

Re: [ros-dev] (Free)DOS subsystem

by Imre Leber

>-----Original Message----- >From: Imre Leber [mailto:imre.leber@telenet.be] >Sent: Tuesday, August 29, 2006 02:57 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > > >>-----Original Message----- >>From: Peter Dolding [mailto:oiaohm@bluebottle.com] >>Sent: Tuesday, August 29, 2006 01:33 PM >>To: 'ReactOS Development List' >>Subject: Re: [ros-dev] (Free)DOS subsystem >> >>Myria wrote: >>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >>> have time. >>> >>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >>> the programs. DPMI programs are supported by asking the kernel to allocate >>> LDT segments and running directly. (If you write a DOS32 program and know >>> the correct addresses, you can call MessageBoxW in user32.dll and it will >>> work.) >>> >>> This differs significantly from DOSBox, which is effectively a machine >>> emulator rather than an API translator. DOSEmu, in comparison, is >>> essentially the same design as NTVDM but for Linux. >>> >>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >>> self and is unaware that it's inside a VM. However, this doesn't work for >>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >>> modified, particularly because the NT kernel handles file I/O. Programs >>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >>> >>> Melissa >>> >>True Closest Freedos to Windows NT NTVDM is >>http://freedos-32.sourceforge.net/. Its was newer version under >>development. It could be stalled from 2005. >> > >Why? > >I never got it. It doesn't seem to add anything new. Nothing that can't be done in FreeDOS. > >FreeDOS is for all pratical purposes a capable 32 bit system. It can run 32 bit DOS and (some) windows programs and it has multithreading (eRTOS), TCP/IP (watt32), etc... . > Well. Maybe I should have said a 32 bit capable operating system. >I think it would not be very difficult to write a multitasking DOS extender either (maybe as an extension to cwsdpr0). > But who's ever going to care? >If it's because it is running in 32 bit, I am not all that convinced that DOS-C can not be ported to 32 bit. It was originally intended to run on apple macintosh. > >Imre Imre > >>Peter Dolding >> >>_______________________________________________ >>Ros-dev mailing list >>Ros-dev(a)reactos.org >>http://www.reactos.org/mailman/listinfo/ros-dev >> >> > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

1
0
0 0

Re: [ros-dev] (Free)DOS subsystem

by Imre Leber

>-----Original Message----- >From: Peter Dolding [mailto:oiaohm@bluebottle.com] >Sent: Tuesday, August 29, 2006 01:33 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >Myria wrote: >> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >> have time. >> >> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >> the programs. DPMI programs are supported by asking the kernel to allocate >> LDT segments and running directly. (If you write a DOS32 program and know >> the correct addresses, you can call MessageBoxW in user32.dll and it will >> work.) >> >> This differs significantly from DOSBox, which is effectively a machine >> emulator rather than an API translator. DOSEmu, in comparison, is >> essentially the same design as NTVDM but for Linux. >> >> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >> self and is unaware that it's inside a VM. However, this doesn't work for >> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >> modified, particularly because the NT kernel handles file I/O. Programs >> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >> >> Melissa >> >True Closest Freedos to Windows NT NTVDM is >http://freedos-32.sourceforge.net/. Its was newer version under >development. It could be stalled from 2005. > Why? I never got it. It doesn't seem to add anything new. Nothing that can't be done in FreeDOS. FreeDOS is for all pratical purposes a capable 32 bit system. It can run 32 bit DOS and (some) windows programs and it has multithreading (eRTOS), TCP/IP (watt32), etc... . I think it would not be very difficult to write a multitasking DOS extender either (maybe as an extension to cwsdpr0). If it's because it is running in 32 bit, I am not all that convinced that DOS-C can not be ported to 32 bit. It was originally intended to run on apple macintosh. Imre >Peter Dolding > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [arty] 23765: Menu displays. Need stdin/hid objects.

by Thomas Weidenmueller

http://svn.reactos.org/svn/reactos/branches/powerpc/reactos/boot/freeldr/fr… > ============================================================================== --- branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c (original) > +++ branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c Tue > Aug 29 11:16:16 2006 > @@ -30,6 +30,7 @@ > BOOLEAN AcpiPresent = FALSE; > char BootPath[0x100] = { 0 }, BootPart[0x100] = { 0 }, CmdLine[0x100] = { > 0 }; > jmp_buf jmp; > +char *video_mem = 0; > > void le_swap( void *start_addr_v, > void *end_addr_v, To avoid incorrect code generation with enabled optimizations, the variable video_mem needs to be defined as: volatile char *video_mem = NULL; - Thomas

18 years, 9 months

1
0
0 0

Frist test of clipboard patch from SoC project

by Magnus Olsen

Hi I I got the clipboard patch from thomas and waiting on the final dectsions from him. Thomas need some time to review it. for it is around 121Kbytes big I did test it in ReactOS and I alot happy 1. Copy text and picture betwin program is working with this big patch 2. Copy file from one place to anyther working. But I wisch it show file copy when it doing it 3. copy file to the desktop does not working nug in explore ?? 4. move icon on the desktop is a new bug in win32k. 5. mark the text is white background with white text instead for invert background with white text 6. cut/copy/paste is working 7. keys like cut/copy/paste (ctrl+x,ctrl+c,ctrl+v) is working in all program I tested. say this patch is really good sussess and adding a clipboard to reactos. that working betwin program and u can copy/paste files and more I say it it is up to thomas to aprove the code. I have not looked at the code at, more that a fast preview.

18 years, 9 months

3
3
0 0

GetSiteSidFromToken in advapi32

by Grzegorz Jaskiewicz

Hi folks based on my knowledge and some docs I used to read ages ago. Plus some recent googling, I kinda recreated function GetSiteSidFromToken from advapi32.dll - as it was missing there, and I couldn't start w2k taskmgr because of that. Of course simple stub returning NULL should be sufficient, but I gave it a shot and tried to implement it fresh and fully functional. First, I am not sure of few things there. And if someone is more knowledgable than I am - please let me know your thoughts. As far as I know the function returns pointer to SID from token. But there's more than one token. So it returns token that has "SITE" SID. Now, there were quite few SIDs missing in ROS, I tried to add them - mainly guessing their names based on some googling. Some docs on msdn say that they are all defined in ntseapi.h - but I couldn't found that file anywhere. For more details lookup attachment 1043 and corresponding bug. Function is quite simple, it iterates through all sids, trying to match the one with "SITE" authority. Question now arises - what if there's more than one such SID ? Does ROS use SIDs 1-6 to 1-8 at all ? is the SECURITY_INTERNETSITE_AUTHORITY the SITE authority or perhaps SECURITY_SITESERVER_AUTHORITY ? I don't know. I will try to write simple code that would ask original function from original dll about it, and see what it comes up with. First part of the code comes as simple c&p from other functions. The iteration is quite obvious. I didn't knew what should I use to compare SIDs, so I used memcmp. But perhaps simple comparing values in the table one by one would be simple, or maybe there's some sort of ROSish/NTish specific function that is more "right" than memcmp. Another question I have - is it normal practice that you alloc extra ram and return pointer to copy (seems to be in other places in your code), or should I just simply return pointer to the SID ? I do appreciate any comment. Patch is attached. if someone has the ntseapi.h file anywhere on their discs, I would like you to verify SECURITY_*_AUTHORITY names as well as values. I spent whole day gathering info, and I used all info I could find. Sorry for such long letter. Much too long I suppose. this is my first attempt to hack anything for ros. I promise next time I would try to take care of something more obvious and better documented. till than, ta. -- GJ

18 years, 9 months

1
0
0 0

Status of trunk

by Aleksey Bragin

Hello, after recent fixes by Alex Ionescu and Thomas Weidenmueller trunk works rather good again. What I tested: - bootcd: installs, 2nd stage install works, explorer shows up and is usable - livecd: doesn't boot due to broken mkhive (it should use cmlib and it doesn't do at the moment) - GDB support in ntoskrnl: I was able to connect to the GDB with a cmdline client, disassembly, however I wasn't able to test it more because our keyboard/mouse drivers don't work when vmware has no focus during booting. WBR, Aleksey Bragin.

18 years, 9 months

1
0
0 0

Shutdown

by James Tabor

Hi, Instead of posting things on chat and coming across as flames, so here we go. I added excerpts and opt edited from "Inside Microsoft Windows 2000". http://www.reactos.org/wiki/index.php/ShutdownProcess "Csrss in turn impersonates the caller and sends a Window message to a hidden window owned by Winlogon telling it to perform a system shutdown." The best way I could do this at one time, take for example. Find the program ntpmon.exe run it and open a console window. Type ctrl-C or break at the same time watch ntpmon. You will see cmd clone itself. One step further in the console window run listdlls.exe and watch ntpmon. You will see "impersonation", threads created under processes to access each process context. Cool right! I could have written this for lib/rtl/dbgbuffer.c but I thought KJK_Hyperions way was cooler and used NtReadVirtualMemory to peek at process context instead. I did have a note in lib/rtl/dbgbuffer.c alluded to this process but one of "the coders that knows more" removed it. So, impersonates; user access rights, its a thread in Csrss created under the user program process context, it finds the parent and sends the shutdown message. I guess, James

18 years, 9 months

2
1
0 0

serial.sys

by Rick Parrish

This email is directed mostly to Herve and anyone else familiar with SERIAL.SYS and how it works. Two years ago I implemented a small (5 kilobyte) WDM driver that "wrapped" SERIAL.SYS. It's an ugly hack that (almost) works. What I did was "hook" the interrupt service routine by directly modifying the IDT. It works most of the time but occassionally I get BSOD (and I don't know why). The driver installed ISR reads the MSR (modem status register) of the UART. The RDTSC instruction is used to generate a timestamp of when the MSR changed. Both pieces of data are stored in a FIFO - on every interrupt. A user mode program can later retrieve the information at regular time intervals. Hint: using the CTS, DCD, and DSR pins on a standard RS232 port, you can create a Poor Man's 3 Channel Logic Analyzer. Other applications include packet radio interface for amateur radio. What I'd like to do is merge the functionality directly into SERIAL.SYS (eg. work with the OS instead of around it). The extra functionality would be exposed through IOCTL or some other means but would not break ordinary serial COMM functionality. Disclaimer: I'm not a veteran author of kernel mode drivers. This is a relatively obscure application so if you want to reply off-list, that's perfectly fine by me. Here are my questions: 1. how robust is the current SERIAL.SYS driver (I see a few "FIXME"s in the comments) ? 2. does ReactOS support or require code-signing of drivers? (probably not yet) 3. Can I run the "Genuine" Reactos SERIAL.SYS on "Genuine" Windows 2K/XP? I think so (setting WFP aside). 4. is anyone in the ReactOS community interested in such a driver extension as described above? (probably not) Also, if anyone would like to see the logic analyzer program and related driver - please send me an email. Regards, Rick

18 years, 9 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 23696: add an 'uptime' command. Available in either Windows or Linux output. (defaulted to Windows)

by Michele Cicciotti [Khamsa S.A.]

Alex Ionescu wrote: > Please don't add 3rd-party utilities to the tree. Such applications need to go in ros-apps. Base is only for BASE applications. "uptime" isn't. > besides, we already have one. I wrote it. It's called tickcount

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 23696: add an 'uptime' command. Available in either Windows or Linux output. (defaulted to Windows)

by Alex Ionescu

gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Fri Aug 25 04:33:27 2006 > New Revision: 23696 > > URL: http://svn.reactos.org/svn/reactos?rev=23696&view=rev > Log: > add an 'uptime' command. > Available in either Windows or Linux output. (defaulted to Windows) > Please don't add 3rd-party utilities to the tree. Such applications need to go in ros-apps. Base is only for BASE applications. "uptime" isn't. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

3
4
0 0

Network card crash with Mozilla and Firefox.

by James Tabor

Hi, I forgot to leave this posted last thursday, @ revision 23605. sorry, James work/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0xA256B780) Packet (0xA256B784) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address: 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/miniport.c:808)(MiniportDpc) back from miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355370). (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x813553B8). (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/memory.c:39)(NdisAllocateMemoryWithTag) Called. (drivers/network/ndis/ndis/miniport.c:311)(MiniIndicateReceivePacket) indicating a 60-byte packet (drivers/network/ndis/ndis/miniport.c:237)(MiniIndicateData) XXX (875d1862) 8134bf60 0 8228c1f0 e 8228c1fe 2e 2e XXX (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0xA1745B58) Packet (0xA1745B5C) PoolHandle (0x81355000). (ntoskrnl/ex/work.c:658) Requesting a new thread. CurrentCount: 0. MaxCount: 1 (drivers/network/ndis/ndis/miniport.c:257)(MiniIndicateData) Leaving. (drivers/network/ndis/ndis/memory.c:121)(NdisFreeMemory) Called. (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (ntoskrnl/ex/work.c:658) Requesting a new thread. CurrentCount: 0. MaxCount: 1 (ntoskrnl/ex/work.c:397) EX: Creating new dynamic thread as requested (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (ntoskrnl/ex/work.c:397) EX: Creating new dynamic thread as requested (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355010). (driver(drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D7D9C8) Packet (0x80D7D9CC) PoolHandle (s/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355058).x81355000). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D7D964) Packet (0x80D7D968) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address : 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:89)(ServiceRoutine) Called. Adapter (0x8123A590) (drivers/network/ndis/ndis/io.c:98)(ServiceRoutine) Queueing DPC. (drivers/network/ndis/ndis/io.c:102)(ServiceRoutine) Leaving. (drivers/network/ndis/ndis/miniport.c:808)(MiniportDpc) back from miniport's SendPackets handler (drivers/network/ndis/ndis/io.c:34)(HandleDeferredProcessing) Called. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355010). (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355058). (drivers/network/ndis/ndis/io.c:64)(HandleDeferredProcessing) re-enabling the interrupt (drivers/network/ndis/ndis/io.c:69)(HandleDeferredProcessing) Leaving. (drivers/network/ndis/ndis/buffer.c:830)(NdisFreePacket) Packet (0x81355448). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D869C8) Packet (0x80D869CC) PoolHandle (0x81355000). (drivers/network/ndis/ndis/buffer.c:409)(NdisAllocatePacket) Status (0x80D86964) Packet (0x80D86968) PoolHandle (0x81355000). (drivers/network/ndis/ndis/protocol.c:223)(ProSend) Called. (drivers/network/ndis/ndis/protocol.c:245)(ProSend) acquiring miniport block lock (drivers/network/ndis/ndis/miniport.c:475)(MiniAdapterHasAddress) packet address: 0:c:76:2a:ffffffd8:ffffffc8 adapter address: 0:13:46:ffffffa4:ffffff91:66 (drivers/network/ndis/ndis/protocol.c:309)(ProSend) Not a loopback packet (drivers/network/ndis/ndis/miniport.c:617)(MiniQueueWorkItem) Called. (drivers/network/ndis/ndis/protocol.c:315)(ProSend) Queued a work item and returning (drivers/network/ndis/ndis/miniport.c:672)(MiniDequeueWorkItem) Called. (drivers/network/ndis/ndis/miniport.c:797)(MiniportDpc) Calling miniport's SendPackets handler (ntoskrnl/mm/mm.c:221) Page fault at high IRQL was 2, address c000009a Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0xC000009A could not be written: Page not present. kdb:> bt Eip: <fetnd5.sys:1b8e> Frames: <fetnd5.sys:2aba> <fetnd5.sys:26da> <ndis.sys:77bc (drivers/network/ndis/ndis/miniport.c:805 (MiniportDpc))> <ntoskrnl.exe:2628 (ntoskrnl/ke/dpc.c:558 (KiDispatchInterrupt))> <80550e52> <80550ece> <805511e3> <tcpip.sys:81bd (drivers/network/tcpip/tcpip/lock.c:27 (TcpipReleaseSpinLock))> <tcpip.sys:1f9f (drivers/network/tcpip/datalink/lan.c:688 (LANTransmit))> <tcpip.sys:11fc5 (lib/drivers/ip/network/neighbor.c:46 (NBSendPackets))> <tcpip.sys:12b6f (lib/drivers/ip/network/neighbor.c:467 (NBQueuePacket))> <tcpip.sys:14f0d (lib/drivers/ip/network/transmit.c:71 (IPSendFragment))> <tcpip.sys:15356 (lib/drivers/ip/network/transmit.c:212 (SendFragments))> <tcpip.sys:15573 (lib/drivers/ip/network/transmit.c:254 (IPSendDatagram))> <tcpip.sys:14633 (lib/drivers/ip/transport/tcp/event.c:107 (TCPPacketSend))> <tcpip.sys:231f5 (lib/drivers/oskittcp/oskittcp/ip_output.c:524 (ip_output))> <tcpip.sys:1b5be (lib/drivers/oskittcp/oskittcp/tcp_output.c:735 (tcp_output))> <tcpip.sys:1a544 (lib/drivers/oskittcp/oskittcp/tcp_input.c:1663 (tcp_input))> <tcpip.sys:16354 (lib/drivers/oskittcp/oskittcp/interface.c:426 (OskitTCPReceiveDatagram))> <tcpip.sys:d7e2 (lib/drivers/ip/transport/tcp/tcp.c:327 (TCPReceive))> <tcpip.sys:a467 (include/ddk/ndis.h:157 (IPDispatchProtocol))> --- Press q to abort, any other key to continue --- <tcpip.sys:c6c4 (lib/drivers/ip/network/receive.c:469 (ProcessFragment))> <tcpip.sys:c967 (lib/drivers/ip/network/receive.c:565 (IPv4Receive))> <tcpip.sys:c9d6 (lib/drivers/ip/network/receive.c:608 (IPReceive))> <tcpip.sys:1605 (drivers/network/tcpip/datalink/lan.c:331 (LanReceiveWorker))> <tcpip.sys:25d60 (lib/drivers/chew/workqueue.c:56 (ChewWorkItem))> <ntoskrnl.exe:305d0 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:1dee8 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:62637 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:6b6f5 (ntoskrnl/ke/i386/ctxswitch.S:82 (KiThreadStartup))> kdb:>

18 years, 9 months

1
0
0 0

Summer of Code, status report

by Michele Cicciotti [Khamsa S.A.]

And so this year's Summer of Code is over. I am moderately optimistic about the outcome, but it could have gone much better... What's there: * the porting! I gutted rdesktop and isolated the smallest subset possible required for the protocol and nothing else. Then I made it re-entrant, as rdesktop was affected by the "accumulate and fire" anti-pattern, setting function arguments in global variables and preventing multiple instances of the library from running (a no-no for an ActiveX control, and for any library in general. Then, again, rdesktop was no library in the first place) * the porting, part 2. I implemented all the "orders" supported by the RDP protocol in terms of Win32 GDI, meaning the display is fully functional (barring the occasional artifact) * the porting, part 3. I implemented mouse/keyboard input. You can interact with your session. That's it. Basically, the RDP client just... works. That's it * the ActiveX control itself, in its glorious hundreds of methods and properties. By far the hardest part of the project. Friends don't let friends code ActiveX controls without ATL! What's not there: * the effort in learning as quickly as possible the most fucked up component model in the history of computing had by far the largest impact on the project, meaning in practice I was stopped halfway through integrating the *actual* code with the extensive ActiveX dressing. In other words, the code currently in the repository is non-functional. Go back a couple of revisions to skip the ugly ActiveX meatworks and see the working proof-of-concept. My biggest mistake was assuming I could tame the ActiveX beast only armed with a stick * some useless ActiveX glue that does not pertain to the kind of control the RDP client is, but has to be there nonetheless * the redirectors were not ported, and no support yet for virtual channel plug-in DLLs. Not a giant effort, though * the mstsc.exe shell Miscellaneous issues: dependency on OpenSSL. This will be hard to eradicate. CryptoAPI isn't an option, beacuse it was designed primarily for PKI, not random arbitrary encryption protocols. In particular, the following limitations make it unfit for use in the RDP protocol: * each provider only supports a single size for RC4 keys, either 40 or 128 bits. Not a major obstacle, but it gets worse * it cannot import plaintext RC4 session keys, at least not without a convoluted workaround (see <http://support.microsoft.com/kb/228786/en-us>). Still not major, but a little bit worse * it cannot perform RSA encryption without padding, required for the session key exchange protocol. CryptoAPI will always pad the cipher with PKCS #1 padding, limiting the plaintext to 11 bytes less than the key size. No workaround for this Best solution: reimplement the internal cryptography library used by Microsoft (the library exported as SystemFunctionXXX from advapi32.dll), which is what the original client uses Afterword: I'll certainly continue working on this. It felt extremely irritating to be so close to a working implementation and just burning time on a huge glue layer probably larger than the implementation itself. Watch this space for future news on my progress! (not in the immediate future though. I'm still recovering from the trauma of hand-coding an ActiveX control)

18 years, 9 months

1
0
0 0

GSoC Status Report

by Pablo

Hi, Google Summer of Code is is ending, and I'm going to report what I've been doing this last months. (yes I know that is my first status report when all is ending, but as I said to Thomas, i'm little shamed of my English :) but it's my mistake. By the other hand I joined many times on IRC with my mentor, Thomas Weidenmüller, and he teach me, many basic concept about ReactOS and integration between kernel and user mode spaces, he's always been nice and helpful with me, and always ask at my questions, and it's was very appreciated by me. With time I'm learning more and more about ReactOS internal implementations, and the start was a little slow. My coding state was sometimes exceeded by external situations, like Alex's ob* implementation, I wrongly make an update of my tree, and many changes magically coming into my code! then sometimes of no-booting-trunk that annoying someone! then come some cm* issues, well, a joyride of code! well, here is a resume of what I've been doing (and done) in the clipboard: *Implemented the APIs to put and get data into clipboard in this formats: Ansi Text, Oem Text, Unicode Text, Bitmap, DIB and Application specific clipboard formats, with the ability of register new formats. Graphic formats still need some testing. *Implement the capability of Delayed Render Format, is like put a specific format type, but not the data, and then, when some application request this data, in this format, the requested application must render it and put it into the clipboard. * Implement the implicit data format conversions between some types of format, in example: if you put an Ansi text, then you can request a Unicode Text, and the same for graphics. * All the function to work with Formats, (not its data), like registering, counting, enumerating, getting the priority formats, query availability, etc. * Implement the window chaining, of the clipboard's viewers (when a format is getting into clipboard all this windows are notified), add, remove, query windows, in the chain. * Appropriate handling of owner window, that rules the clipboard! *Of course, open, close and empty clipboard functions. *Added many test cases to the regression tests of user32, clipboard area. and More: I worked very hard on shell32.dll to make work cut/copy & paste capabilities on shellfolders of explorer. (not on desktop ): now working! This implementation is indirectly related to clipboard, but is directly related to final user! Now you can copy a file and then paste its link, and create shortcuts of any file (even in desktop, but not from desktop), I don't test make a shortcut of a shortcut! I'm work now on that. This time I worked too on many small patches that I put in bugzilla. Some others patches still here on my working copy. Sorry again for my no communication. If someone want to ask me about this or else, my nick in IRC is P43LOk, I'm going there very often. Best Regards, Pablo

18 years, 9 months

1
0
0 0

ReactOS 0.3.0 RC2 Released

by Brandon Turner

I just released 0.3.0 RC2 to SourceForge and you can download it here: https://sourceforge.net/project/showfiles.php?group_id=6553&package_id=6629 This is our final sanity check before we release the final version. I am planing on uploading the release to to SourceForge on Wednesday night and then Thursday morning will be our official release time. Frik or MGW, will you be able to update the home page on Thursday morning? If not let me know and I can do it if we have a graphic ready. Note to all devs and contributors: We need a change log! I have made a svn log for all commits. It can be found at http://www.brandonturner.org/log.txt . Please let me know if you are going to do your own change log, otherwise I will do a change log for everyone else on Tuesday night, but no promises I will find everything you did. -- Brandon Turner ReactOS Release Engineer Blog: http://www.amateurgramming.com

18 years, 9 months

7
10
0 0

[Fwd: Indonesian translation for ReactOS]

by Alex Ionescu

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

18 years, 9 months

3
2
0 0

Request: SLOC stats of ReactOS 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0

by Klemens Friedl

Request: SLOC stats of ReactOS 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0 SLOC = source lines of code I would like to compose some neat statistics about ReactOS (for reactos.org) and I need help of people with unix compatible operating systems (because the only reasonable SLOC scan tool "sloccount") isn't available for Win32. If you get it working with Cygwin, CoLinux, etc. under Win32 it's fine too. sloccount: http://www.dwheeler.com/sloccount/ Please scan the source code (export it from svn; don't scan svn dir directly) of 0.0.1.0, 0.1.0, 0.2.0 & 0.3.0 (current 0.3.0 rc3 branch). General information about SLOC: http://en.wikipedia.org/wiki/Source_lines_of_code If you don't want to hassle with svn, then download the following source code archives from sourceforge: 0.0.1.0: http://prdownloads.sourceforge.net/reactos/0010_source.zip 0.1.0: http://prdownloads.sourceforge.net/reactos/0100_source.zip 0.2.0: http://prdownloads.sourceforge.net/reactos/reactos-0.2.0-source.zip 0.3.0 (rc2): http://prdownloads.sourceforge.net/reactos/reactos0.3.0-RC2-src.zip If you think you found a better tool to count SLOC's then share the results too. And please share the results from "sloccount", even someone else already posted stats about the same version. There might be differences in the results and it's better to have more stats of the same version to verify and use average values. Please scan the "reactos" dir (and all it's sub-dirs) and add specific of which version of ReactOS & sloccount you have used to gather the stats. Thanks for your help. Klemens

18 years, 9 months

4
5
0 0

About coding style / GNU indent

by Aleksey Bragin

Hello, I've experimented a little with the DrFred's GNU indent settings, they were good, however I advanced them more and found out almost perfect set of settings which suits our proposed/official coding style (the only debateble part was using TAB vs. SPACEs, but for some areas like ntoskrnl TAB-based indentind is de-facto not used at all). For further info / remaining problems, look to the following URL: http://www.reactos.org/wiki/index.php/GNU_Indent WBR, Aleksey Bragin.

18 years, 10 months

1
0
0 0

ReactOS cmd.exe

by Klemens Friedl

If someone has some freetime and want improve cmd.exe, the following website has listed a lof of undocumented commands, flags, tricks, etc. of several win version: http://www.robvanderwoude.com/ (click on batch files in the navigation bar)

18 years, 10 months

2
1
0 0

RC3 What?!?

by Brandon Turner

We are actually going to have an RC3 this release because we got 2 last minute bug fixes and will be adding a wallpaper to the bootcd. It will go out Sunday Aug 18th. This should be the last RC before final. Thanks for you time and understanding! -- Brandon Turner ReactOS Release Engineer Blog: http://www.amateurgramming.com

18 years, 10 months

1
0
0 0

[ros-kernel] How do device drivers fit into the project goal

by James Tabor

-------- Original Message -------- Subject: [ros-kernel] How do device drivers fit into the project goal Resent-Date: Fri, 16 Oct 1998 22:08:57 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Fri, 16 Oct 1998 20:05:44 -0700 From: rex <rex(a)lvcablemodem.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com> In a recent response to a message I posted, dennis mentioned that the goal of the project is to build an OS that gives the user a Win32 compatable environment. He also stated in that message that the guts will not necessarily be the same as WinNT or Win98, insted that might actually work correctly. A while ago a similar discussion came up and it was agreed (or so I remember) that we would try to remain compatable with device drivers so we don't have to reinvent them all. I was reading a status message from Connor and I realized that he has some interesting ideas for building a high performance video subsystem, but my brief glance at his description left me thinking that legacy drivers probably will not plug into it. This does not bother me, however we should discuss this and decide on a clear goal for ReactOS regarding driver compatability. It's my impression that the following statement sums up the goal of the project: ReactOS will be a freely distributable operating system capable of running Win32 applications, that is Win98 and WinNT applications. The main project page states the following: "ReactOS will be a free operating system that can run software and drivers compatible with Windows NT." I hope I'm not stepping on any toes, but I think before Conner builds a fast but not necessarily compatable video system, or Arindam builds a compatable but not necessarily most effecient network subsystem, perhaps we should reaffirm the goal so noone takes the wrong path. Personally, I vote for driver compatability. I think there is enough room internally for improvement over the MS design (though I haven't actually seen it) that we dont need to change the structure of the driver interface. Of course, I haven't yet seen the Network or Video driver interface other than block diagrams and broad overviews. Rex.

18 years, 10 months

4
4
0 0

[ros-kernel] Re: How do device drivers fit into the project goal

by James Tabor

-------- Original Message -------- Subject: [ros-kernel] Re: How do device drivers fit into the project goal Resent-Date: Sat, 17 Oct 1998 03:03:33 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Sat, 17 Oct 1998 01:03:07 -0700 (PDT) From: Jason Filby <jasonfilby(a)yahoo.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com Hi, ---rex <rex(a)lvcablemodem.com> wrote: >I hope I'm not stepping on any toes, but I think >before Conner builds a fast but not necessarily >compatable video system, or Arindam builds a >compatable but not necessarily most effecient >network subsystem, perhaps we should reaffirm >the goal so noone takes the wrong path. The goal states that WinNT drivers must be compatible with ReactOS. I should be able to take a graphics or network driver that was written for NT and use it with ReactOS. Compatibility is extremely important. That said, ReactOS drivers don't necessarily have to run under NT. See what I'm saying here? We MUST provide the mechanisms for NT drivers to work - but CAN also add additional mechanisms that only ReactOS drivers use so that they perform better. Personally, I'd prefer that the mechanisms that allow NT drivers to run 100% are implemented first -- then we can add our own mechanisms that only drivers written to take advantage of them use. But you don't necessarily have to go in that order. At the end of the day, we'll run drivers for NT perfectly (1st priority) and drivers for ReactOS even better (2nd priority). I don't know if I explain this all clearly enough -- so, if not, just tell me. - Jason Filby _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

18 years, 10 months

1
0
0 0

mkhive changes

by Aleksey Bragin

Hi, currently head has problems with the registry due to changes in structures which were not replicated in mkhive tool (thanks to a "good" code duplication between them). I'm now porting mkhive to use cmlib's headers so that there is no need to keep the same structure in a few places and forget to change it everywhere. It will be commited in a few hours when I get back. WBR, Aleksey Bragin.

18 years, 10 months

1
1
0 0

OpenOffice.org 2.0.3

by David Ianno

I tried to install OpenOffice.org 2.0.3 using r23543. The installation stopped because of an ASSERT in cmlib. nl\ps\thread.c:503) FIX PS SDs!! (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (ntoskrnl\ps\thread.c:503) FIX PS SDs!! (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsAlloc (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsGetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsSetValue (dll\ntdll\ldr\utils.c:1194) LdrGetExportByName(): failed to find FlsFree (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase\Content Type\application/vnd.stardivision.writer"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase\Content Type"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME\DataBase"!) (ntoskrnl\cm\ntfunc.c:437) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Classes\MIME"!) Assertion 'CellIndex != HCELL_NULL' failed at lib\cmlib\hivecell.c line 19 Entered debugger on embedded INT3 at 0x0008:0x8007fda0. kdb:> cont Assertion 'CellBlock < RegistryHive->Storage[CellType].BlockListSize' failed at lib\cmlib\hivecell.c line 29 Entered debugger on embedded INT3 at 0x0008:0x8007fda0. kdb:> cont Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x003FFFFC could not be read: Page not present. kdb:> cont KeBugCheckWithTf at ntoskrnl\ke\i386\exp.c:1241 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 (0xC0000005,0x8007F050,0x00000000,0x003FFFFC) *** ntoskrnl.exe - Address 0x8007F050 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:8007f050 <ntoskrnl.exe:7f050 (lib/cmlib/hivecell.c:30 (HvGetCell))> cr2 3ffffc cr3 299e000 Proc: 810401e8 Pid: 118 <msiexec.exe> Thrd: 820cb468 Tid: 134 DS 23 ES 23 FS 30 GS 0 EAX: 00000000 EBX: 8d22bd40 ECX: 00000032 EDX: 00000000 EBP: 9e879c98 ESI: 0007ffff ESP: 9e879c14 EDI: 8d22bcd8 EFLAGS: 00010286 kESP 9e879c14 kernel stack base 9e877000 Frames: <ntoskrnl.exe:fe79 (ntoskrnl/cm/regfile.c:1571 (CmiDeleteValueFromKey))> <ntoskrnl.exe:d94e (ntoskrnl/cm/ntfunc.c:2157 (NtDeleteValueKey))> <ntoskrnl.exe:6ec74 (ntoskrnl\ke\i386\trap.s:306 (KiFastCallEntry))> <advapi32.dll:88c0 (dll/win32/advapi32/reg/reg.c:2109 (RegDeleteValueA))> Entered debugger on embedded INT3 at 0x0008:0x8007fda6. kdb:> cont --------------------------------- Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta.

18 years, 10 months

2
3
0 0

ReactOS 0.3.0 RC2 problems

by Andrew Smith

Hi, I'm not sure if this is the correct place to post this, if it's not I'm sorry, just let me know where I should post things like this to. Right then, I downloaded the VMware RC2 image and loaded it up in VMware player. Booted fine (and i like the boot time ;-) and thought that I'd try the networking out. I was able to open up ibrowser and download the mozilla control fine and browse like that to a few sites (getfirefox.com, sf.net, 7-zip.org and guildwars.com). I wanted to try out Guild Wars (a DirectX MMORPG, very ambitious I know). I was able to go to the site fine and download the client, however, when I went to download 7-zip I was given a BSoD. I restarted and tried to download firefox instead and install that. The download was fine however part way through the install it just dropped out. I tried again and the same thing happened. I then noticed the 'Get Firefox' link in the start menu, which didn't do anything (just opened the download window and sat there). I looked around the C: drive and noticed that Firefox had installed the exe so I tried to run it but didn't get anything. I closed the 'Get Firefox' window and tried that again, same problem as before, this time though it wouldn't close. Opened up task manager and saw 2 firefox.exe running so I tried to kill them, this didn't worked. Tried to kill 'Get Firefox' process and that worked, but then a few seconds after that I got another BSoD. I've attached the vmware.log in case it's any use. The debug.txt file is empty for some reason, so I've not attached that. I'm going to try a few more things and I'll let you know what happens. If this kind of feedback isn't useful let me know, or let me know where to post it so it can become useful :-) -- Andy Smith - Def since birth

18 years, 10 months

1
0
0 0

[ros-diffs] [hpoussin] 23540: Add code to start the screensaver from winlogon

by James Tabor

Hi, It's worse! > This code should replace the existing one in win32k/csrss, but is not activated (yet) due to some bugs: > - Calling SetWindowsHookEx with WH_KEYBOARD_LL gives a BSOD when pressing a key Not sure,,, The hook code is a Wineie/GvG/w3seek hod podge thingy. > - Time field in PKBDLLHOOKSTRUCT/PMSLLHOOKSTRUCT should be in milliseconds > - Screen saver parameters can't be retrieved with SystemParametersInfoW > - Probably others... In ntuser/message.c & desktop.c, I noticed that the switch code uses a static PW_O InputDesktop. This is used in message.c when looking for broadcasting,, etc. It's indirectly called by IntGetDesktopWindow which returns the active desktop that is stored in InputDesktop. SO,,,,, multi desktops w/o a common root message hook?,,,,,, > > Plus a few less important ones: > - When sending a message with HWND_BROADCAST, the invisible SAS window doesn't get the message In ntuser/message.c, co_IntDoSendMessage doesn't support recursive entry for HWND_BROADCAST. A good example for doing this is UserPostMessage. If it does, I did not see yet. > - When calling (NtUser)SystemParametersInfo, WM_SETTINGSCHANGE message is not sent > - desk.cpl doesn't save (some) screensaver parameters to registry > SendNotifyMessage is UNIMPLEMENTED! Oh the Shock of seeing that! 8^O !NOOOOOOO! Okay, James

18 years, 10 months

1
1
0 0

svcctl.idl: Why "Scmr"-prefix?

by Elrond

Hi, I was looking at svcctl.idl in ros. I wonder, where the "Scmr"-prefix comes from? googling for say "ScmrCloseServiceHandle" gives only results from reactos, nothing else. "CloseServiceHandle" gives lots of results, of course. Was the prefix choosen arbitrarily and could have well been "Ros" instead? Elrond

18 years, 10 months

4
6
0 0

(no subject)

by Alex Ionescu

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

18 years, 10 months

1
1
0 0

2nd stage unattend setup - solution for locale setting

by Aleksey Bragin

Hello, after just a bit of searching I could find this: http://blogs.msdn.com/michkap/archive/2006/03/10/548670.aspx http://blogs.msdn.com/michkap/archive/2006/02/23/538455.aspx So instead of creating some weird function export, duplicating code or even creating a whole locality static lib, we can just use that compatible /F:unattend.inf switch! Also, it looks like we use exported func "LocalePageProc@16", which looks like a hack too. WBR, Aleksey Bragin.

18 years, 10 months

1
0
0 0

Big Bug in CreateWindowEx

by James Tabor

Hi, I guess Hervé has found something similar. We can not create a desktop window in createwindowex. I've looked at it again and at it's current state it would be imposable to do w/o some rewriting (already started). We need to fix this Atom issue I'm pushing! With a common atom we can fix this message problem. Setup the children so they can talk to each other. So far, we have four desktops w/o a root. Non of them can talk to each other. I can't see it! If this can be fixed, I bet things will magically start working. Well, look at this, it's from wine, I think they got it. #define DESKTOP_CLASS_ATOM MAKEINTATOMW(32769) /* create the desktop window */ hwnd = CreateWindowExW( 0, DESKTOP_CLASS_ATOM, NULL, WS_POPUP | WS_VISIBLE | WS_CLIPSIBLINGS | WS_CLIPCHILDREN, 0, 0, width, height, 0, 0, 0, NULL ); if (hwnd == GetDesktopWindow()) { SetWindowLongPtrW( hwnd, GWLP_WNDPROC, (LONG_PTR)desktop_wnd_proc ); SendMessageW( hwnd, WM_SETICON, ICON_BIG, (LPARAM)LoadIconW( 0, MAKEINTRESOURCEW(OIC_WINLOGO))); SetWindowTextW( hwnd, desktop_nameW ); SystemParametersInfoA( SPI_SETDESKPATTERN, -1, NULL, FALSE ); SetDeskWallPaper( (LPSTR)-1 ); <snip> LiteStep and DarkStep, look about the same thing except for the atom. We dont need much of this but the process looks sound. B^| James

18 years, 10 months

1
0
0 0

Problem drawing the desktop in the updated color

by Timo Kreuzer

Hi, First, this is going to be a long post, sorry ;-) You might have noticed, that I have been working on the desk.cpl appearance tab, wich is working partly. Here's the first version: http://www.reactos.org/bugzilla/show_bug.cgi?id=1732 Some things still don't work. For example the desktop doesn't get repainted in the new color. > ------- /Comment #5 > <http://www.reactos.org/bugzilla/show_bug.cgi?id=1732#c5> >From > jimtabor 2006-08-05 04:46:36 CET / [reply > <http://www.reactos.org/bugzilla/show_bug.cgi?id=1732#add_comment>] > ------- > Hi, > You can use WM_SYSCOLORCHANGE in the desktop proc if it is used, should be!, > user32/misc/desktop.c; > > static > LRESULT > WINAPI > DesktopWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) > { > DPRINT1("Desktop Class Atom!\n"); > switch(message) > { > case WM_NCCREATE: > return TRUE; > > case WM_CREATE: > /* when I spy I see notify */ > SendNotifyMessageW( hwnd, WM_SYSCOLORCHANGE , 0, 0 ); > break; > > case WM_SYSCOLORCHANGE: > /* update everything, well in theory anyway */ > RedrawWindow( hwnd, NULL, 0, RDW_INVALIDATE | RDW_ERASE | > RDW_ALLCHILDREN ); > break; > > default: > return DefWindowProcW(hwnd,message,wParam,lParam); > } > return 0; /* all other messages are ignored */ > } > > Its crude, I'm not sure if it will compile, its off the top of my head ATM. > 8^D > Thanks, > James > Thanks for helping, James. I tried it, but it doesn't work. 1.) Sending WM_SYSCOLORCHANGE on WM_CREATE will probably do nothing, because the desktop has just been created with the initial SysColors, no need to update them. 2.) RedrawWindow calls NtUserRedrawWindow wich calls co_UserRedrawWindow wich calls co_IntPaintWindows wich sends a WM_PAINT message to the desktop window. WM_PAINT is then passed to DefWindowProc and passed on to User32DefWindowProc wich does only repaint the icon as it seems. So WM_PAINT must be evaluated in DesktopWndProc. I tried the following: > case WM_PAINT: > { > PAINTSTRUCT ps; > HDC hdc = BeginPaint(hwnd, &ps); > PaintDesktop(hdc); > EndPaint(hwnd, &ps); > } PaintDesktop calls NtUserPaintDesktop, wich then paints the desktop. I have also replaced DesktopBrush = (HBRUSH)UserGetClassLongPtr(WndDesktop->Class, GCL_HBRBACKGROUND, FALSE); with DesktopBrush = IntGetSysColorBrush(COLOR_BACKGROUND); But the desktop is still painted in the original color, whereas the icon text is in the color I have set in the registry. I played a little around with the code in NtUserPaintDesktop. I added the following code before the desktop background is painted: > if (IntGetSysColor(COLOR_BACKGROUND) == 0) // This is true after > SysColors are loaded from Registry > { > DesktopBrush = IntGetSysColorBrush(COLOR_ACTIVECAPTION); > } And suddenly the desktop is painted in COLOR_ACTIVECAPTION. This is strange, because I also added CreateSysColorObjects(); at the beginning of NtUserPaintDesktop. Anybody any idea?

18 years, 10 months

4
8
0 0

Re: [ros-dev] [ros-diffs] [fireball] 23524: Force -fno-sibling-call-optimisation to every module's CFLAGs. This fixes *numerous* bugs (thanks to a bug in GCC itself), even in DBG=1 builds! Just an example, comctl32.dll doesn't crash anymore in LISTVIEW_Callback(). Thanks to Dmitriy Philippov (aka Shedon) for encountering the comctl32 bug and investigating it!

by Alex Ionescu

"Bugs? There's no bugs in GCC. GCC is perfect." "I've never encountered a bug in GCC that would have real-life effects, except a small one a long time ago" -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 10 months

1
0
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