Ros-dev

ros-dev@reactos.org

5790 discussions

proper nt-style authentication (reactos, wine, samba tng)
by Luke Kenneth Casson Leighton 02 Sep '05

02 Sep '05

[please note: due to its cross-discipline and cross-project nature, this message is going out to SEVERAL related project mailing lists. when replying, please take EXTRA caution not least because some of these lists are subscriber-only. also, please note: i _would_ post this also to the samba mailing lists but due to the fascist censorship in place since the 15th dec 2004, i am unable to do so. this is their decision and it is their loss. i am not asking you to respect that decision i am simply making you aware of it.] hi, out the woodwork i pop - not necessarily ready to chew anything because i know just how much work's involved, but what i did want to do was say "hi, i'm still here" and do a brain-dump of how authentication ideally needs to be implemented in reactos. at 2,600 words and 16k, this message is quite long and so i have placed a copy at http://lkcl.net/software/reports/reactos-auth.txt, just in case it doesn't make it past various mailing-list limits (i'll find out in a couple of minutes... :) it breaks down into a number of sections: 1) i describe the timescales and ways to cut them, along with some warnings and stuff. 2) amonst other stuff i outline some background as to why i am posting this to so many lists. 3) i outline a project plan and the dependencies and "optional" steps, 4) i describe a recommended implementation roadmap starting with the "minimum" requirements, and expand on some technical info and references i found, which would help with some of the "nice-to-have" steps. so. first. please do not be scared by how much work is involved, and how much code there is. it all hinges one ONE function and that one function... you are _not_ going to believe how much code that one function drags in, kicking and screaming, behind it. please also please i beg you DO NOT consider going "bleedin 'ellfire, that's so much frakkin work we can't POSSIBLY do it the way you describe, we MUST do it our own way, starting with what we know, love and have already started tackling, and can't possibly back out of what we've already done". should you choose to exercise the "NIH" option, i frakkin guarantee you that you will waste about five to eight years of your (collective) lives reinventing the wheel. "The Plan" outlined here will shave that down to about 12 to 18 months, utilising some SIX HUNDRED THOUSAND lines of pre-existing code, and later in this message i also outline a prioritisation of the necessary work to "cut down" the time to maybe about ... mmm... three or so months, by leaving out some of the "nice-to-have" stuff. actually... _all_ of the nice-to-have stuff :) that will at least "GetItWorking(tm)" and the rest of the bits can be considered at leisure once people go "god that's awful, we can't possibly leave it like that" and hopefully hopefully things will actually progress from there. remember - please: this stuff is sufficiently complicated such that you really can't afford the niceties such as "It Must Be Perfect (tm)" before it can be accepted. i've seen that shit before, and it's a baad mxxxxxxxer path to go down, especially with such complex and heavily interdependant reverse-engineering projects as reactos, wine, samba and freedce. anyway. fyi - before i begin, i should mention a couple of things: 1) this message also goes out the the apache devel mailing list (specifically the APR one) because the NT style authentication thing is the sort of thing that really _should_ be in a (special?) APR util library, along with "NT Named Pipes" - see http://en.wikipedia.org/wiki/NamedPipes one of the reasons why NT-style NamedPipes is _not_ in an APR util is because it is believed that NT-style NamedPipes do not fit the "least common denominator". by having the infrastructure outlined below, it is possible to move things "up one level" to the point where unix _has_ that denominononmination. also, if APR still has support for that god-awful program-running program called Win95, it would, with not much extra effort, be possible to port some reactos components to Win95 (!) such that ThePlan outlined here would make Win95 have proper NT-style authentication (!) now there's a horrible thought that will give MS and free software people nightmares both: upgrading Win95 by installing free software components at it. muhahahahah ahem. 2) i have filled in a number of pages on wikipedia.org. see http://en.wikipedia.org/wiki/User:lkcl. please take the time to review these pages, PLEASE help me with my totally biased "POV" (point-of-view) comments, by either editing the pages direct or by adding comments on the "talk" pages as appropriate. or alternatively dumping me in the nearest pond if ever you meet me. wikipedia is supposed to be encyclopedia-ic and some of my comments are anything but that. help!!! 3) please due to the quite broad distribution of this message across multiple mailing lists, please do NOT ask stupid questions like "what the hell do we need to use samba tng for, why can't we use samba in reactos"? and "why is this guy bothering us with this insane stuff?" and "how do i use killfiles?" or terry pratchett's - more specifically the librarian's favourite - "where has all the pie and custard gone?" please do your research: see if nothing else http://en.wikipedia.org/wiki/Samba_TNG_software and then start googling. anyway. onward. roughly in order of dependence, with "nice-to-have" status added as well: 1) port FreeDCE to Win32 - more specifically add in autoconf support for an alternative threading model - the one in reactos. no, this is not a joke: MSRPC is a critical part of NT infrastructure it's just that very few people are actually aware of this (including the US DoJ and the EU commission...) see http://www.google.co.uk/search?q=lkcl+wine+freedce for discussion links as to why - it's a long story and it took me several dozen messages spanning over many days to outline it in sufficient detail for it to be understood (mostly me getting things straight in my head...) status: "nice to have" but you will soon wish that you _did_ have it!!! there is also an opportunity to support Wine, here: essentially it's the same job, for DCOM, for proper "authentication" purposes in Wine just like in ReactOS... it's a long story. 2) remove dependence on "unix" security model from Samba TNG's services starting with samrd (perhaps by finishing off samrtdbd?) status: "essential". sub-projects: a) in Samba TNG, rework winbindd such that it is a REQUIRED service, and it has "modes" that, instead of "inventing" links between unix uids and nt sids, it reads smbpasswd and correlates unix uids with nt sids _just_ like is done now - but hard-coded through the awful code that has had to dieee since... about two weeks after i wrote it, back in 1999. this one's a long story but it's not actually required for reactos but _might_ be required for wine... status: "pretty much essential" but not for reactos but for making life easy to share tng development between reactos and unix. b) in Samba TNG, make the authentication code (smb-side and rpc server back-end-wise) contact winbindd BUT ONLY for resolving unix uids and unix gids - which is actually a VERY small task involving a few hundred lines of code. this goes back to the "SURS" stuff i wrote up in 1999 - but instead of a library it hands off the responsibility for sid<->uid+gid lookups to winbindd. it _may_ also be essential for Wine to operate correctly with authentication (which is a "stub" at the moment just like it is in reactos), to interoperate with other programs, to cache login credentials in order to do smb client-side operations, that sort of thing, under which circumstances, it will be necessary for Wine to have the same sort of thing. it's no big deal :) status: same as for 2a). c) in Samba TNG, abandon all use of hard-coded MSRPC stuff and utilise FreeDCE instead, and do a rewrite of all services, one by one (and because samba tng is modular, this _can_ be done one-by-one, checking MSRPC interoperability along the way between the "old" services, the "new" services, and also with NT itself). in and of itself, this critically depends on making DCEThreads reliable, though, or adding support (finally!) for POSIX threads. status: "non-essential" but you would soon end up wishing that you had :) 3) complete LsaLogonUser, add LsaLogonUserEx, in NTOSKRNL.DLL, and friends. my favourites. the LSASS stuff. these functions are quite simple: they are "redirectors" - a vector table of functions is required to be passed in, which includes things like "authenticate with my lovely service" and "free some memory". there are many LSASS sub-services: one of them is Netware, one of them is MSV1_0.DLL, one of them is Kerberos. there are others. LSASS is based on _exactly_ the same technique that dlopen does e.g in libdvdcss, and in freedce's ntlmsspauth.so, and in... mmm... the freedce transport module infrastructure and _many_ other projects ... except of course it's NT-based table of higher-order-functions not unix "dlopen()" ones. i'll stop trying to teach people to suck eggs, now *embarrassed* :) status: "essential". sub-projects: a) write an MSV1_0.DLL which registers with the LSASS service. this will utilise MSRPC functions that call into the Samba TNG "NETLOGON" service. there already exists "basic" functions inside Samba TNG that... well... it's a bit messy, but they work. the key function to be calling is cli_nt_login_interactive, and you will notice _very_ quickly from the arguments hey, some of those look... kinda... familiar!! see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/rpc_client/cli_… status: "essential." the "porting" bit of this code to FreeDCE i would classify as "non-essential" but again, you will soon wish that you _were_ using FreeDCE. that's basically it: there are other sub-projects such as turning the "Registry" code in ReactOS (or Wine) into an MSRPC service (yes, i did say pretty much everything that's anything critical in NT is an MSRPC service, didn't i? :) but they aren't "essential". i say basically it, but that ONE stupid function, cli_nt_login_interactive, drags in quite literally HALF A MILLION lines of code - 250,000 lines of it in FreeDCE, alone (which, like i said, could possibly be avoided but the hard-coded MSRPC stuff in samba tng is sufficiently awkward to make a rewrite utilising FreeDCE very attractive). what i would suggest is the following: 1) write an MSV1_0.DLL "test stub" in combination with completing the LSASS functions, which supports a username "test", domain of "test" and password of "test". code up a hard-coded "blob" - a NET_USER_INFO_3 structure - that contains the response / essential information of groups, gids, sids, user session key etc. see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_net… (note: i _did_ say it would be nice to utilise FreeDCE didn't i? well, the NET_USER_INFO_3 structure in that header file is a "messy" version that i recreated from off-the-wire back in about ... mmmm... 1997. there _do_ exist IDL-generated versions of this data structure, thanks to matthew chapman - NETLOGON.idl for example). once that works... 2) write a lovely insecure method of "outsourcing" the username, domain and password to an external server - Samba TNG - which performs the authentication on your behalf and gets back "real" data. this could be done simply with a TCP connection, throw the data in-the-clear over to a simple temporary shim service blah blah, bob's your uncle. 3) port samba tng's netlogond, samrd and lsarpcd to ReactOS. this is quite straightforward: about the only really essential "missing" bit is to tie the services in to "NT Named Pipes" rather than unix domain sockets. _but_ - they only need to be plugged in to a back-end transport which all services - any of samba tng's MSRPC services - would use. so there's a key bit of work needed - probably under 400 lines of code - and the rest should fall into place. this is where it would be SO much easier to be utilising FreeDCE. all that's needed would be to write a FreeDCE "transport" plugin for ReactOS - ncacn_np - and then you'd be DONE. it's a long story... hey, has someone implemented TransactNamedPipe() and CreateNamedPipe() in ReactOS? if not, it's quite straightforward to do, and it involves dropping opaque data blobs onto smbd (again, smbd ported to reactos...) i _did_ say it's a long story, didn't i? :) 4) finally: track down how "LsaLogonUserEx" works. LsaLogonUser utilises cleartext passwords. LsaLogonUserEx i BELIEVE utilises NT and LM password hashes, or some brain-dead encrypted variant thereof. once 1) is completed, then TA-DAAAAA!!! lib/secur/lsa.c's "LsaLogonUser" function actually gets REAL DATA! okay. notes: 1) regarding FreeDCE. see http://en.wikipedia.org/wiki/FreeDCE freedce is an interoperable version of MSRPC that is derived from EXACTLY the same source code (DCE 1.0 reference implementation) that is present in Windows NT. DCE/RPC was co-opted / adopted / borg-ified by microsoft to form the basis of NT domains because paul leach, a co-founder of apollo computers and originator of NCS which became DCE/RPC, ended up working for microsoft back at the time when dave cutler was doing the original NT 3.1. using FreeDCE is non-essential for small projects of less than about 8,000 lines of code. Samba TNG's MSRPC code comprises OVER ONE HUNDRED THOUSAND lines of code. that i carried on hand-crafting MSRPC packets for three years simply demonstrates quite how bloody stupid i am. that you - the wine team - continue to reinvent an non-interoperable version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY, demonstrates quite how just as bloody stupid you are being. that _can_ be taken as a compliment, as i genuinely i mean it with the greatest of respect. 2) regarding a strategy to "minimise" the amount of time needed to "Get Things Working". a) utilise samba tng as-it-is, porting it as-is to ReactOS (mingw32) b) utilise cli_nt_login_interactive() as-it-is. c) complete MSV1_0.DLL. this will be SUFFICIENT and would only take a few months. enhancements come later, roughly in this order: a) complete a port of FreeDCE to ReactOS, by beating DCEthreads to death and replacing it with Win32 (NT) threads - #ifdef style, autoconf style. b) locate NETLOGON.idl, samr.idl and lsarpc.idl from matthew chapman's stuff, or from "todd sabin's" http://razor.bindview.com, or from the samba web site. actually... see: http://www.bindview.com/services/razor/utilities/ compile up CLIENT-SIDE ONLY, using dceidl, and create a library for use inside MSV1_0.DLL. i know todd developed interoperable versions of these idl files, because he was using them, compiled with MIDL.EXE, to do security tests against NT 4.0. remember: these IDL files are what microsoft DOESN'T want anyone to have, and there are very good _legitimate_ reasons for it: they are "behind-the-scenes" APIs which, if some idiot inside microsoft went and wrote a tool which became publicly used and relied on, they would be stuffed: they have ENOUGH apis which date back 15 years and they don't need any more. that having been said, i hate the fact that they are forcing people to pay $50k up-front and then $100 per-client for frakkin _information_. bastards. c) replace cli_nt_login_interactive() with a function that utilises the above library that utilises netlogon, samr and lsarpc client-side stuff from b) above. basically, what it boils down to is that the functions inside cli_nt_login_interactive i wrote BY HAND after examining MSRPC traffic. those functions neeeed too dieeee and they can easily be replaced one-by-one with the "proper" versions from doing "dceidl -client lsarpc.idl". it takes a couple of seconds and you get a header file lsarpc.h and a lsarpc.o and you're DONE. question. why did i spend so long doing hand-marshalling of the nt domains code. perhaps because i would not be able to give microsoft absolute hell for three frakkin years? d) consider porting, one-by-one, the Samba TNG services lsarpcd, netlogond and samrd (or better samrtdbd) to FreeDCE runtime infrastructure. this is NOT essential but it is very worthwhile. every project needs to do at least two throw-aways and with the samba tng code, there has been approximately one and a half throwaways so far... time for a major one, ESPECIALLY in light of the reactos project. FINALLY: e) consider writing that winregd service but actually picking up REAL registry hive files. someone did write a "reader" of registry files, i do not recall who it was. [note: YESSSS!!! yeeeeeehawww, todd i could KISS you!!] http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/ntreg_readme.cfm todd wrote a registry-hive-reader as a linux filesystem driver!!!!! todd, you are bloody mad. *smooch*. f) consider writing a samr service with the FreeDCE runtime that utilises "registry" functions RegXXXX - _properly_. anyway, if you got this far: congratulations and welcome to a brief nightmare history of the development behind NT Domains Authentication. all of the infrastructure above _already_ exists - in Samba TNG. it's just... it works. it's a bit creaky at the edges, but it works. how about it? l. p.s. it almost goes without saying, but i will hint at it once again: you will not find the samba team's goals and strategic direction to be compatible with reactos. as a team, they lack the insight, vision and project management skills to be able to cope with such inter-dependant insane gibberish. this i say with much sadness because they are highly respected individuals in the free software community, and yet they are taking the samba project in very different - and ultimately time-consuming - directions from what is really really needed. due to pride they cannot admit this in public but they have been known to admit it in private. much much disappointment and sadness and there's absolutely nothing i can do about it. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

ReactOS 'Support Database' for the new ReactOS Homepage (ideas, goals, questions)
by Klemens Friedl 01 Sep '05

01 Sep '05

ReactOS 'Support Database' for the new ReactOS Homepage I wrote down a lot of ideas, questions, soulutions, goals, etc. for the upcoming Support Database! We need more ideas, suggestions, comments, etc! Please read the whole text and then write an email to the mailing list! This text should start discussion about that topic !!! Thanks! Note: * some of the ideas are not completely new, i copy&paste the from winehq's newsletter archive (i quoted the winehq's ideas and add the original post date)! * I have added some useful links at the of the text! Please try out the links and explore the compatibility databases from other projects! You will need it if you want to join the discussion. And I *hope* a lot of persons join the discussion! So please visite the links and write down what could be better or what's key features our database also should *clone*! The 'Support Database' will contain the following 'databases': * Compatibility Database (application, driver and hardware) * Package Database (a list of download-able applications/driver; principal for the ReactOS Package Manager) (* Media Database (like the ReactOS Fansite Media Database; maybe we can implement this later)) The 'Support Database' (project codename 'RosDB') will base on the package manager alpha page that i have created april 2005. Note: the package database will be combined with the compatibility datbase. Both 'databases' will share the same 'application tree'! So it will be easy e.g. you browse the compatibility db, you found a working app and think, "i also want to download this app", then you will be able to click on a link (on a central position) and you will be redirected to the package database. In near future it should be possible (if you run ReactOS or Win32 with installed and runing ReactOS Package Manager), that you can select your favorite apps/driver you want to install (navigation like amazone/ebay/compatibility db) and then click install (a normal link on the package manager page) and your running (maybe as a service) ReactOS Package Manager check/capture every clipboard item and if it is a valid 'package style link' then it will connect to the online database and download all the selected apps/driver and download it from mirror server (from their developers/sourceforge/etc.) and then install all items (without or with minimum of user interaction). In my (frik85) opinion, that would be one of the 'hottest' feature someone can imagine (in connection with a homepage, package manager, etc.). This feature will became a main feature and everyone will use that *hope* for ReactOs and also possible for Win32 (from MS). :) -- frik85 "ReactOS Compatibility Database ReactOS has an Compatibility Database where Windows application/driver/hardware compatibility is recorded. Registered users can submit new items, and comment on existing ones. Screen shots are also available for many apps. Users can also vote on their favorite apps." -- a possible description Design goals User wants to know following things: * Does my application/driver/hardware work? * How can I make it work? * Does it work in the new ReactOS/application/driver/hardware version? * Where can i download the application (maybe with the ReactOS Package Manager)? * list all working and non working application/driver/hardware Management Issues/Goals: We need a high 'input data quality', then the administration work will be a minimum. To reach this high data quality, i want to code a simple to use wizard for the 'submit item' page. You can view the sample wizard on the package manager alpha page (see link). Have some form of a moderation system to let end users know the quality of a given persons entry. Maybe like the appDB from winehq? Where a registered user can ask for a kind of moderator right for one specific item (e.g. application), so he can manage the comments, add new info, etc. -> taking ownership of an item (e.g. application): monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description. NO redundant entries for the same product! We need moderators who review all new entries. The moderators should be able to read as many comments as possible and help the normal users, report bugs to the bugzilla system, etc. Reviews (aka user comments) should expire. (expire time 1 year?) Track hit counts on each item (auto magic way of knowing which apps are most desired) and maybe voting like in appDB (WineHQ) or in C4 (CodeWeaver). Some ideas i found in old winehq's neewsletters: (maybe useful for our project!) "Idea: Tie the apps database to the api database. The idea is that we know from the apps database which apps are the most popular. We know from the api database which DLLs/entry points are used by those apps. We can then create a report out of the api database of the list of the DLLs most needed by the top ten apps, and then people writing test scripts (something Alexandre and John Sturtz are working on), have a prioritized todo list. Again, this helps us find useful things for the many volunteers to do." -- winehq newsletter from 18 Oct 2000 Note: maybe a good idea to create such a api database; -> a simalar api status output is currently generated from the svn server (with a small console based application, see build tools). You can view the api status on the svn server. A great chance to import the data to the database and make the idea above possible! The only question, is it usefull for someone? -- frik85 "Idea: Tie the apps database to bugzilla. If users have a problem with an app, it's a bug, and should be in bugzilla. If we can get to a point where we can easily get a report that says 'here are all the bugs that Quicken depends on'. Or, here are the five bugs, the fixing of which will make 50 apps suddenly work. This would be wicked cool." -- winehq newsletter from 18 Oct 2000 Note: the bugzilla will be a subsystem of the RosCMS, so it will be (maybe) possible to implement the idea above. Is something like this usefull for someone? -- frik85 "if we add some 'relay statistics' in Wine code (of course, there will be problems with COM objects where relaying does not work for now) and incorporate these statistics in the database, we could have a list of the most frequently used Windows calls. (feel free to add new ideas for improvements :-) )" -- winehq newsletter from 28 Dec 2000 "He [who take ownership of an item] definitely should have the application installed and, very preferably, he should also be using it regularly (or testing it regularly if it is not yet in the usable state). You are right in pointing out that he cannot test all possible but I contend he does not have to. His role would be to: read the comments entered in the application's comment section. engage into a discussion with the users who post interesting tricks, information, report a sub-version as not working, report problems with a specific Wine/Windows combination extract and summarize the above in his application status report. This section would come first in the application's page and only the application maintainer would be allowed to modify it (whether it's strictly enforced or not is another issue) test the application regularly and update the information on the application's page help users having problems with that application " -- winehq newsletter from 28 Dec 2000 "Jeremy White proposed some scheme to help keeping the database usable: I think the biggest problem with the app database is that we get garbage in, it produces garbage out. I think we should not report or even use any user scores until a trusted app db maintainer has validated that user experience (and possibly users can become trusted reporters). Too many people say 'Hey! The main screen came up! That's a 5! Witness the Slashdot post about MS Office 2k. (anyone actually try to use Office 2K in Wine to author a sizable document?)." -- winehq newsletter from 28 Dec 2000 The information we will gain from the support database * the progress of ReactOS (for devs and normal user) * the most wanted applications (when we implement a voting / hit counts feature) * a reference for application/driver/hardware that doesn't work without tweaking, to get them working * people may be able taking 'ownership' of an application and do regular bug reports / regression testings). Several questions, where we need a answer: "How to 'classify' applications ?: the main point was how an application should be identified (think of Word 5 vs. WinWord 5 cs. Word 7.0, and lots of other quirks (limited versions, demo version, patched versions...) What information should we have about an application ?: this would help in knowing the correct context of execution of such an application (target Windows version, used DLLs, used APIs...)" -- winehq newsletter from 28 Dec 2000 * And about a ReactOS releases ? * How about scoring ? * What additional information should one application/driver/hardware have? We need as much ideas, (feedback after the relaunch/while the testing phase), comments, (and flames) as possible the next weeks. After the website relaunch We need volunteers to take responsibility for updating Apps in the Compatibility Database. We need to discuss this! Then after the discussions ... only remains the hours of coding and debugging to put it in place :) Compatibility Databases from other projects: http://appdb.winehq.org/ http://www.codeweavers.com/compatibility/ http://www.linuxcompatible.org/compatibility.html http://www.ntcompatible.com/compatibility.html http://www.microsoft.com/whdc/hcl/default.mspx ttp://www.realtimesoft.com/multimon/search.asp http://hardwaredb.suse.de/index.php?LANG=en_UK http://www.testingstandards.co.uk/compatibility_-_database.htm http://www.yellowtab.com/support/hardware/ http://www.iyonix.com/software/ http://www.ardi.com/compat_search.php?name=ALL&category=ALL&status=ALL A kind of Package Database: http://rpmseek.com/index.html?hl=en If you know other websites that should be listed here, please write an email to the mailing list! Best regards, Klemens Friedl <frik85> PS: if you write a comment, do NOT quote whole passages or do NOT quote the whole text! The reason, emails should be readable ... -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

4 4

Re: [ros-dev] New Webserver System
by reactos 01 Sep '05

01 Sep '05

This makes it totally perfect for embedded applications like Set-top-boxes or Routers or why not game consoles right? /Jaix ----Ursprungligt meddelande----- From: Emanuele Aliberti ea(a)iol.it Date: Thu, 1 Sep 2005 06:37:19 +0200 To: ReactOS Development List ros-dev(a)reactos.com Subject: Re: [ros-dev] New Webserver System > Richard Campbell wrote: > > > Well, i don't know about other devs around here, but i don't WANT > > ReactOS to become another XP. > > > > Windows XP typically consumes over a GB of space. > > > > Remember NT4? It took between 30 and 100 mb of space depending on > > features. Windows 95? About 15 MB. If users want additional apps, > > they can either download them, or use a custom ROS distro that will > > include such things. The source tree is cluttered enough as it is. > > ReactOS should only include the basic software that earlier versions > > shipped with...a notepad clone, possibly a wordpad clone, basic net > > utils, etc. > > Also the Win32 subsystem is not technically necessary. All Win32 pieces > could be moved off the main reactos tree and included as optional > linking them from modules. I proposed it years ago. It is not an easy > task, though, because setup should know that, if the user asks for no > personalty at all, it should install none (now win32 is by default in). > Personalities (win, posix, os2, vms, ...) should come on the cd-rom as > separate cab files and post install procedures add registry entries, > create directoryes etc. A no-personality ReactOS will be a really light > OS, perfect for custom text/graphics boxes (you just need writing an > entry in the registry for the session manager to start your native > program, which will be the only user program in the box (excluding the > sm itself). > > -- > :Emanuele Aliberti > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev Yours sincerely, Jaix Bly

2 1

Ros VGA driver not working - To be confirmed
by Gge 31 Aug '05

31 Aug '05

Hello, Ros VGA driver does not work anymore in my real hardware configuration. I'd like to know if the problem is confirmed by somebody else. To reproduce it , disable the VBE drives in Hiveinst.inf file , make registry and reboot. The green Reactos logo displayed at boot is not displayed correctly ( color is red/yellow etc , the logo is not clearly displayed ) Here are the debug messages (DBG=1) --------------------------- (ntoskrnl\ldr\loader.c:252) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys (drivers\input\i8042prt\registry.c:218) Can't read registry: c0000034 (drivers\input\i8042prt\registry.c:224) Manually set defaults (ntoskrnl\ldr\loader.c:252) Could not open module file: \SystemRoot\system32\drivers\xboxvmp.sys (ntoskrnl\ob\wait.c:246) Returning: 0 (subsys\win32k\ntuser\desktop.c:769) Trying to open desktop (\Windows\WindowStations\WinSta0\Default) (subsys\win32k\ntuser\desktop.c:580) IntShellHookNotify: No desktop! (subsys\win32k\ntuser\desktop.c:769) Trying to open desktop (\Windows\WindowStations\WinSta0\Winlogon) (subsys\win32k\ntuser\desktop.c:580) IntShellHookNotify: No desktop! (subsys\win32k\ntuser\desktop.c:769) Trying to open desktop (\Windows\WindowStations\WinSta0\Screen-Saver) (subsys\win32k\ntuser\desktop.c:580) IntShellHookNotify: No desktop! (lib\ntdll\ldr\utils.c:2072) Relocating (77a90000 -> 431000) C:\ReactOS\System32\version.dll FIXME: CopyImage doesn't support IMAGE_ICON correctly! (lib\ntdll\ldr\utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib\ntdll\ldr\utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib\ntdll\ldr\utils.c:2015) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (SAMLIB:lib\samlib\samlib.c:399) User already exists! (lib\setupapi\devinst.c:2513) not fully implemented (lib\setupapi\devinst.c:2513) not fully implemented (lib\setupapi\devinst.c:2513) not fully implemented (lib\setupapi\devinst.c:2513) not fully implemented (lib\setupapi\devinst.c:2513) not fully implemented (lib\setupapi\devinst.c:2513) not fully implemented Thanks Gge

2 1

Baby Steps
by Rick Langschultz 30 Aug '05

30 Aug '05

This is a suggestion: Can ReactOS implement an OpenLDAP backend to the ReactOS website. There are many benefits to implementing OpenLDAP into the reactos.com website. First, reactos.com can use this software to authenticate users in certain modules of the website such as future forums, wikis (via publishing), and possible later implementation into a mass- mailing system like squirrelmail or mailman, suggestions, hint hint, or perhaps in the future an instant messenger engine. Also OpenLDAP would be able to provide back-end website developers to verify status of community members. How is that for a baby step to implementing someone's ideas... Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

5 7

bootsect.ros
by dalfa the enlightenedone 30 Aug '05

30 Aug '05

hi i installed reactos on my hd but the installer doesnt give the option to install de loader to the mbr only on the floppy so i didnt installed because i dont have a floppy :p then i create: freeldr.ini ant copy the freeldr.ini but i didnt know what the bootsect.ros is i didnt find info about it in the wiky ¿how can i create one? -- [dalfa@MDK dalfa]$ cat .firma [UsuarioGnu/Linux326018] <Ymessenger> dalfa_id <WebPage> http://dalfa.tk <WebPage> http://dalfa.no-ip.org <Jabber> dalfa(a)jabber.org <skype> theenligthenedone <aMSN> dalfa.theenlightenedone(en)gmail.com <Blog> http://drakedalfa.blogspot.com/ <aim> drakedalfa -> Y la verdad os hara libres... - Hechos 4: 12 - Romanos 10: 9-13

2 2

Shouldn't errors be explained a bit better?
by Reuben Perelman 29 Aug '05

29 Aug '05

I was looking through the installer, and noticed that it generated an error for partitions created by linux fdisk. Shouldn't the user be informed about this, so they know why. This type of information will help a user solve the problem that caused the error. Below is the code for the error I'm talking about. if (WarnLinuxPartitions == TRUE && CheckForLinuxFdiskPartitions (PartitionList) == TRUE) { PopupError ("Setup found that at least one harddisk contains an incompatible\n" "partition table that can not be handled properly!\n" "\n" "Creating or deleting partitions can destroy the partiton table.\n" "\n" " \x07 Press F3 to quit Setup." " \x07 Press ENTER to continue.", "F3= Quit ENTER = Continue"); while (TRUE) { ConInKey (Ir); if ((Ir->Event.KeyEvent.uChar.AsciiChar == 0x00) && (Ir->Event.KeyEvent.wVirtualKeyCode == VK_F3)) /* F3 */ { return QUIT_PAGE; } else if (Ir->Event.KeyEvent.wVirtualKeyCode == VK_RETURN) /* ENTER */ { WarnLinuxPartitions = FALSE; return SELECT_PARTITION_PAGE; } } }

1 0

Nevermind
by Rick Langschultz 29 Aug '05

29 Aug '05

Since I heard of reactos, i have always considered it one day replacing my Windows 2000 and XP boxes. Because ReactOS was going to be an open-source alternative to the Windows NT API I felt that it had and has serious potential to hinder or greatly replace Microsoft Windows. I have suggested several ideas both through IRC (freenode) and email messages how the computing world does things. I understand that ReactOS is still in pre-production, and planning for the next release is greatly important to the community development and testing of the operating system, however I fail to grasp the concept behind the hindrance of ideas being passed the the development community. Some development plans I have talked about were: 1 - A 64 bit journaling file system with a SQL-like back-end. Lookout WinFS; there that plan went down the drain. 2 - Implementing an instant messenger server for developers and users to talk on, realtime, without IRC. Maybe not quite MSN Messenger, but why not? iChat even uses .mac. 3 - Implementing an OpenLDAP back-end to the website. Active Directory has nothing on you... Plan knocked out again. i would rather stick with something close minded like closed source software than having no ideas be recognized at all. I only suggest things like this because Microsoft will always be releasing newer software that will leave reactos in the dust if they not heed the advice of all, not just me, their developers, testers, and users. Why not; right? why envision something and it fail to be realized, waste of time if i ever knew it... Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

6 5

Installation procedure
by drake dalfa 28 Aug '05

28 Aug '05

|>hi, |> |>i have a problem with the installation from |>setup to a real hd the setup dies with this |>message: |> |>allowconsolo() failed (status = 0x0000001) |> |That one seems a well known bug: |http://www.reactos.com/wiki/index.php/ChangeLog-0.2.7 |http://reactos.com/bugzilla/show_bug.cgi?id=688 thanks that show me the way ;) the problem is my keyboard is usb one so i plug an ps2 one and now all work :) maybe a little more debug on the setup will help to others to figure this :) more easy thanks :) |>the installation procedure is only the copy |>of the reactos directory to the hd? |> |It also prepares the SYSTEM registry hive with values depending on the |operator choices and (little) hardware probing and installs the boot sector. thanks, now i can install the system and now i configure the grub but i have another question the file bootsect.ros, wath has to say? i made my freeldr.ini like this: [ReactOS] BootType=ReactOS SystemPath=multi(0)disk(0)rdisk(0)partition(7)\reactos Options=/DEBUGPORT=SCREEN but the bootsect.ros i didnt find a example :) thanks for the help

1 0

Re: [ros-bugs] [Bug 729] ftp.exe exit at start
by Gge 28 Aug '05

28 Aug '05

ReactOS.Bugzilla(a)reactos.com wrote: > http://reactos.com/bugzilla/show_bug.cgi?id=729 > > > > > > ------- Additional Comments From waxdragon(a)gmail.com 2005-27-08 18:14 ------- > Hartmut's 17563 commit fixed this. Thank you! There are still issues with ftp, > and I will file another bug. > Ftp.exe still fails for me as per debug messages below WARNING: WSHGetSockaddrType at drivers\net\wshtcpip\wshtcpip.c:103 is UNIMPLEMENTED! WARNING: WSHGetSockaddrType at drivers\net\wshtcpip\wshtcpip.c:103 is UNIMPLEMENTED! 8ce8fc10: 00 31 66 00 00 00 00 00 00 00 00 00 01 00 00 00 8ce8fc20: 0e 00 02 00 00 15 d4 1b 28 fc 00 00 00 00 00 00 8ce8fc30: 00 00 TCPConnect: Called Connecting to address fc281bd4:1500 so->so_state 102 so->so_state 102 so->so_state 102 so->so_state 102 (ntoskrnl\mm\mm.c:300) Address: ffffffff Unhandled exception Address: 7c815b1f C:\ReactOS\system32\KERNEL32.dll CS:EIP 1b:7c815b1f DS 23 ES 23 FS 3b GS 0 EAX: 00000001 EBX: 780263f0 ECX: 00000000 EDX: 0065fbf4 EBP: 00000000 ESI: 00020000 ESP: 0065fb30 EDI: 7c843cfc EFLAGS: 00010202 Frames: <error dumping stack trace: 0xc0000005> so->so_state 13b (lib\rtl\env.c:574) Return STATUS_VARIABLE_NOT_FOUND: PROMPT Regards

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev