Ros-dev

ros-dev@reactos.org

5789 discussions

by Steven Edwards

--- Maarten Bosma <maarten.paul(a)bosma.de> wrote: > If I understood you correctly you said that there is no need for > developing a compleatly new system, a Packagemanager only had to provide > a interface for the msi files. Right, You can interface directly to the MSI database in the registry. > First of all, I have to say that I don't know much about that msi stuff. > So my question is how would the msi file and the program communicte ? > The point with a packagemanager is that you choose to install lots of > packages and leave your PC alone. So the package manager had to send the > dessions of the user to the msi file and then the msi file had to do > it's operations senlitly. And send reports to the package manager from > time to time. And if something went wrong, it has to send a compleate > error report. Well MSI packages have a lot of options, more so than are used by most people. Most people just write a Install Shield wizard and have the software packaged in a msi but it can do self-repair and modification and all sorts of cool stuff. Most third partys now ship apps as MSI as its what Microsoft supports or they use NullSoft Install System so making a easy to use interface to both of them will win the most support. Its like a mini-sql database so you can even use XML to mess with it in your Package Manager. If I understand correctly the Microsoft tool for creating MSI packages "WiX", uses a xml file for input. The only problem is that WiX is CPL and not GPL so we cannot ship it with ReactOS unless we make it a seperate download. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com

20 years, 3 months

Idea for NTFS replacement

by Mike Swanson

NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT. Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;) -- Mike

20 years, 3 months

Package Manager

by Maarten Bosma

Hallo, As you might remember firk85 and me have started coding a package manager for ReactOS. More information and a download linkcan be found on the wiki on http://wiki.reactos.com/PackageManager . Since it is now so far that it is at least a bit useful, I'd like to ask what you think of adding it to the svn-tree ? Maarten Bosma

20 years, 3 months

Xen port of ReactOS

by Ge van Geldorp

Hello, After doing some research, I've decided to go ahead and start a port of ReactOS to Xen. For those in the Xen community not familiar with ReactOS: it's an open-source (GPL) re-implementation of the Microsoft Windows NT-based line of operating systems, aiming to provide binary compatibility for both applications and drivers (http://www.reactos.com). For those in the ReactOS community not familiar with Xen: it's an open-source (GPL) virtual machine monitor that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html). Initially I'll focus on getting ReactOS running as a guest OS. This should benefit ReactOS primarily, since this will make it possible to develop large parts of ReactOS (everything except for hardware drivers and some low-level memory management) inside Xen. It will also give ReactOS access to some hardware not natively supported yet (by using the Linux driver). The benefit for Xen at this stage would be the development of ReactOS device drivers for interfacing with Xen, which could also be used for a Windows XP port. On the longer term, I see no reason why ReactOS couldn't function as a driver domain. As driver compatibility improves in ReactOS, this could provide Xen guests access to hardware for which the manufacturer provides only Windows drivers (due to Xens nature, not every driver could be used this way, but I bet a large percentage of the drivers depend on the kernel to do the really low-level stuff). All in all, it seems a win-win proposition for both projects. And even more importantly, I think it's a cool project :-) I've made a branch in ReactOS svn, svn://svn.reactos.com/branches/xen, for this port. Of course, the goal is to merge the changes into trunk eventually. I expect the port to take at least a few months, my initial feeling is that it should be done by the end of the year (there's lots of other stuff in ReactOS I want to work on too). The wiki page at http://wiki.reactos.com/Xen_port will be used to keep track of progress. The game plan is just start working from the boot code, until a problem is hit. Fix that problem and continue until the next problem. Any support and help from the Xen and ReactOS communities are of course greatly appreciated. Gé van Geldorp.

20 years, 3 months

confusing smss routine (ea)

by Gunnar Dalsnes

I was doing some changes to RtlCreateUserProcess and saw the strage rotuine SmCreateUserProcess: http://svn.reactos.com/viewcvs/trunk/reactos/subsys/smss/smapiexec.c?rev=14… It has several bugs/problems/confusions: 1) RtlDestroyProcessParameters is not called if RtlCreateUserProcess failed. 2) If WaitForIt is TRUE and you specify a timeout, the caller in not notified if SmCreateUserProcess returned due to timeout. The process will stay running forever. 3) If TerminateIt is TRUE, handles are closed. This is wrong/confusing. Closing the handles does not terminate the process (wrong name?). 4) If you dont pass a UserProcessInfo and TerminateIt is FALSE, it will leak thread/process handles. 5) If you pass UserProcessInfo and TerminateIt is TRUE, the thread/process handles in UserProcessInfo will be invalid. etc.etc. VERY confusing and bug prone: SmCreateUserProcess is used once in the end of this file and it pass FALSE for TerminateIt and pass no UserProcessInfo thus the thread/process handles will never be closed. I should have fixed it myself if i just understod how this routine is _supposed_ to work:-D Regards Gunnar

20 years, 3 months

Network connection config dialog prototype

by Andrew "Silver Blade" Greenwood

Following some discussion with Art Yerkes via email, I've been toying around with a resource editor and shifted XP's network connection configuration dialog around: www.furrybeans.co.uk/stuff/netdlg.jpg Note that this will not be the final dialog, nor will that exact one be used - I'm using a resource editor just so I don't have to painstakingly recreate each control just to see what it looks like. It's just convenient for laying out a prototype. Ignore the image at the top left - that was there already. Compare with XP or 2000's dialog and let me know what improvements you can think of. -Andrew

20 years, 3 months

Re: [ros-dev] Idea for NTFS replacement

by Steven Edwards

--- Mike Swanson <mikeonthecomputer(a)gmail.com> wrote: > Hacking an existing *nix filesystem to work on ReactOS just doesn't > seem right, nor does it seem very practical. Some of us primarly run Linux and I host mine on ext3 partitions so having the ext2fsd working under ReactOS helps with the testing and migration path. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

20 years, 3 months

I think I know how uxtheme works...

by Jonathan Wilson

What I strongly suspect happens is this: 1.The themes service is always loaded and running and holds the theme data (and it contains details of which .msstyles file to use) 2.At some point (either at startup if the changes are global or when an app loads if the changes are app specific, I cant find where this bit happens but I suspect the themes service does this) control passes to ordinal 34 in uxtheme.dll (aka ThemeHooksInstall acording to uxtheme.pdb). This function calls an undocumented function in user32 called RegisterUserApiHooks (which appears to be taylor made for uxtheme to do what it needs to do). The function hooks: GetScrollInfo SetScrollInfo EnableScrollBar SetWindowRgn DefWindowProcW DefWindowProcA PreWndProc (probobly stuff that happens internally before the window procedure gets called) PostWndProc (probobly stuff that happens internally after the window procedure gets called) PreDefDlgProc (probobly connected to dialog boxes) PostDefDlgProc (probobly connected to dialog boxes) GetSystemMetrics SystemParametersInfoA SystemParametersInfoW DrawFrameControl DrawCaption MDIRedrawFrame (probobly related to MDI frame windows) This is what causes all apps (including non-theme-aware ones) to get themed non-client areas (window borders etc) 3.Apps that are theme aware have a manifest, load comctl32.dll 6.0 and probobly have to call InitCommonControlsEx (although I think some of the code in the dllmain for comctl32.dll 6.0 may also end up calling InitCommonControlsEx). This causes new versions of the stock classes (button, list box, edit, combo box etc etc etc) to be created and registered. A cursory examination of some of these classes shows that they dont seem to "pull code" from the stock implementation in user32.dll (i.e. anything they dont themselves handle goes back to DefWindowProc). In particular, it doesnt appear as though they have any knowledge of the classes or window procedures contained in user32.dll. then 4.Apps that need to do something extra call into functions exported by uxtheme.dll to do whatever they need to do. user32.dll seems to have no knowledge whatsoever about themeing and uxtheme. All that user32 has is RegisterUserApiHooks (and the matching UnregisterUserApiHooks) that uxtheme uses to hook into user32.dll and do stuff. Exactly how the theme service and theme engine works "under the hood" doesnt matter. But for ReactOS and WINE purposes, I suggest we implement the following: 1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks (either reverse engineer the MS function or write our own). This will allow uxtheme to hook into the global drawing for things like window borders without user32 needing to care about uxtheme and what uxtheme does (just like how MS hooks into user32 that way) 2.Whatver code is necessary to get the hooks installed right so that all apps get the "global" theming like on real windows 3.Support to read the manifest and load a new comctl32.dll that would be like the version 6 from microsoft (and would contain complete theme-aware implementations of the stock controls just like MS comctl32.dll 6.0 does) and 4.All the needed uxtheme exports to make stuff run This would be the same way Microsoft does things. User32.dll would have no idea whatsoever about uxtheme and theming All apps would get non-client-area themeing like on windows. And only theme aware apps would get themed controls etc (the rest would get "stock" windows controls) Oh and btw, if this "reverse engineering" is not "clean room" enough for WINE and ReactOS, let me know and I will stop posting it :)

20 years, 3 months

ping Alex regarding log2() for scheduler

by Royce Mitchell III

Alex, I managed to shave off another comparison in favor of a shift: int highest_bit ( int i ) { int ret = 0; if ( i > 0xffff ) i >>= 16, ret = 16; if ( i > 0xff ) i >>= 8, ret += 8; if ( i > 0xf ) i >>= 4, ret += 4; if ( i > 0x3 ) i >>= 2, ret += 2; return ret + (i>>1); } FWIW, rdtsc reports that compile for speed is 2x as fast as compile for size. I've thought about ways to possibly optimize pipeline throughput for this, but too many of the calculations depend on results of immediately previous calculations to get any real advantage. Here's updated micro-code for BSR, if you really think AMD & Intel will actually do it... IF r/m = 0 THEN ZF := 1; register := UNDEFINED; ELSE ZF := 0; register := 0; temp := r/m; IF OperandSize = 32 THEN IF (temp & 0xFFFF0000) != 0 THEN temp >>= 16; register |= 16; FI; FI; IF (temp & 0xFF00) != 0 THEN temp >>= 8; register |= 8; FI; IF (temp & 0xF0) != 0 THEN temp >>= 4; register |= 4; FI; IF (temp & 0xC) != 0 THEN temp >>= 2; register |= 2; FI; register |= (temp>>1); FI;

20 years, 3 months

New proposed frontpage for reactos.com

by Jason Filby

Hi all A new proposed frontpage for reactos.com can be found here: http://reactos.com/newsite/reactos_index.html None of the links go anywhere yet. ezPublish will be phased out and most of the content hosted in a wiki (editable only by people trusted in the project). The wiki/forums/blogs would require a bit of a face-lift so as to look similar. Comments? Cheers Jason

20 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev