Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] Package Manager
by Steven Edwards 01 Apr '05

01 Apr '05

Hi, --- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Why not? > Its perfectly possible to include a CPL program on the same CD or zip file > as a GPL program as long as they dont directly mix code (IANAL but this is > what I understand). Linux distributions mix and match code of all different > licences and get away with it. Because we have developed this project like Debian or FreeBSD though we have a "Unspoken Social Contract" GPL incompatible software will not be mixed in the same package or on the same medium as GPL compatible software. I am perfectly happy to have WiX or any other OSS package shipped with ReactOS on a Non-Free CD. It does not mean that I view the CPL as Non-Free, far from it, but in the GPLs current incarnation it has been deamed GPL-incompatible. Maybe the GPL v3 will address these issues and we can even ship WiX in the same package/cd as ReactOS but I still would rather not have ReactOS become dependant on code developed by Microsoft as it may make them rethink the idea of Freeing other packages in the future. I would rather link, provide downloads to (apart from the main ReactOS package), and ship it on a "extras" CD. Thanks Steven __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest

3 2

Re: [ros-dev] Package Manager
by Steven Edwards 01 Apr '05

01 Apr '05

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

2 1

Idea for NTFS replacement
by Mike Swanson 31 Mar '05

31 Mar '05

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

5 9

Package Manager
by Maarten Bosma 31 Mar '05

31 Mar '05

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

1 0

Xen port of ReactOS
by Ge van Geldorp 31 Mar '05

31 Mar '05

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.

3 2

confusing smss routine (ea)
by Gunnar Dalsnes 31 Mar '05

31 Mar '05

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

4 3

Network connection config dialog prototype
by Andrew "Silver Blade" Greenwood 31 Mar '05

31 Mar '05

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

9 19

Re: [ros-dev] Idea for NTFS replacement
by Steven Edwards 31 Mar '05

31 Mar '05

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

1 0

I think I know how uxtheme works...
by Jonathan Wilson 30 Mar '05

30 Mar '05

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

3 6

ping Alex regarding log2() for scheduler
by Royce Mitchell III 30 Mar '05

30 Mar '05

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;

6 14

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