Ros-dev

ros-dev@reactos.org

5790 discussions

State of the Repository September 2nd 2005

by WaxDragon

First, some stats: In August there were: * 676 Commits * 49 bugs opened * 139 bugs touched * 44 bugs closed Looking over the logs, here are some of the big and/or highly visible changes: *sedwards bought in some winetests (in regtests/winetests) This resulted in some immediate fixes *navaraf replaced the pesum tool with pefixup *sedwards brought dosfsck in late July, and enabled writing in August. Still needs testing, but seems to work. *brandonturner implemented windows style tab completion, replacing the bash style we had before. I believe this can be toggled. Also, cmd has really been getting attention from brandonturner and greatlord, may little bugs have been fixed. Thanks guys! *ion removed the third-party driver info from the hives and placed them in the wiki. I felt this was a good move, since it will motivate people to fix/implement driver installation. The interim solution was going to be creating .reg files to import or just re-add the info to your local hives. This had the side affect of breaking our vmware video driver installer. After some bugfixes, vmwinst now loads the driver, but ReactOS seems unable to set the resolution. *navaraf fixed the i8042prt detection, partially fixing the AllocConsole bug. This was merged to 0.2.7 and we shipped it as a known bug. We have received just a few reports of the AllocConsole bug on IRC, so it seems to work for most. *navaraf fixed the translation of extended keys, fixing my bug hilighting text with Shift+Arrow keys. Merged to 0.2.7, thanks Filip! *ion twiddled the priority code, fixing some winetests * ea returned to work on subsystem code * gdalsnes fixed ftol, progressing Abiword 2.0.3 * ion corrected the LPC Message Structures * amunger fixed the freeldr.ini Timeout ;0) * hbirr fixed several bugs that were blocking selfhosting (ros-on-ros compilation) I am able to compile ros on ros with the patch from the selfhosting bug. Thanks Hartmut! * We found that release builds of msi.dll allow the VMWare Tools installer to run, several bugs were fixes in relation to this. Thanks everyone! *fireball got USB keyboards working on the XBOX, along with various USB fixes * ion cleaned up the NDK headers * gvg added the autogenerated DIB code for 32 and 8 bpp * navaraf reimplemented the HAL DMA routines * There was some work on the MSVC backend, thanks to sedwards and royce * navaraf fixed some bugs in NDIS * navaraf tweaked the explorer taskbar, fixing the misaligned buttons under windows This exposes a bug in ReactOS, so the taskbar looks a little off now. 17604 seems like a good way to start September: * shutdown bug fixed * Default Abiword 2.2.9 install works * Abiword 2.2.9 runs and opens documents. * 7-Zip 4.23 Installer works * 7-Zip GUI has several issues * 7za.exe (cli) works * OO installer unpacks, but bombs a few pages in * notepad opens and saves files properly * winemine doesn't work * solitare works * ps works * mc seems like it has issues (I'm not a user per se.) * format still doesn't work * calc doesn't even start * cat works * regedit can set values * wallpaper stays if set in registry, not if using desk.cpl Networking: * qemu networking fixed * ftp fixed * ping works * ipconfig has issues * finger works * "route print" works * netstat doesn't work * ncftp has issues * hostname works * arp doesn't work * mIRC installer works, fails creating icons (or start menu I don't remember) * mIRC has several issues, can't get it to connect and the usual implementing new functions, syncing to wine, and bugfixes. Overall 17604 "feels" good and stable. I was able to use the command line without too much trouble, installed many packages, and only saw a few BSODs, mainly in the network code. I think that is a pretty good summary, and since it's been the day of long emails, I won't go any further. Please reply to this email if there is something I forgot, overlooked, got wrong, etc.. WD -- #irc.freenode.net #reactos 01:03PM <filip2307> i don't know about any bug 01:04PM <filip2307> none exist 01:04PM <filip2307> ReactOS is prefect

20 years

ReactOS Revision ISOs

by Sylvain Petreolle

Hi all, After doing some regression tests with SVN ISOs, it appears some are missing/badly numbered. Here is the updated list. ReactOS-trunk-rxxxxx.iso -> real revision ReactOS-trunk-r17465.iso -> r17560 ReactOS-trunk-r17466.iso -> r17539 ReactOS-trunk-r17468.iso -> r17559 ReactOS-trunk-r17471.iso -> r17567 ReactOS-trunk-r17472.iso -> r17553 ReactOS-trunk-r17473.iso -> r17565 ReactOS-trunk-r17478.iso -> r17552 ReactOS-trunk-r17479.iso -> r17569 ReactOS-trunk-r17490.iso -> r17572 ReactOS-trunk-r17495.iso -> r17553 These files did show the same version (md5sum proved they are different) ReactOS-trunk-r17480.iso -> r17564 ReactOS-trunk-r17482.iso -> r17564 ReactOS-trunk-r17476.iso -> r17566 ReactOS-trunk-r17483.iso -> r17566 ReactOS-trunk-r17489.iso -> r17566 Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

20 years

SMSS & LSASS: Service Status

by Rick Langschultz

Hey all, I am thinking about starting, or helping write the SMSS and/or LSASS implementation on ReactOS. I was wondering what I can help with, or help someone to do the work... Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

20 years

Re: [ros-diffs] [navaraf] 17604: Check for Request == NULL.

by Hartmut Birr

navaraf(a)svn.reactos.com wrote: >Check for Request == NULL. > >Modified: trunk/reactos/ntoskrnl/lpc/reply.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/lpc/reply.c* > >--- trunk/reactos/ntoskrnl/lpc/reply.c 2005-09-02 11:29:40 UTC (rev 17603) >+++ trunk/reactos/ntoskrnl/lpc/reply.c 2005-09-02 13:12:44 UTC (rev 17604) >@@ -263,6 +263,12 @@ > > Request = EiDequeueMessagePort(Port); > KeReleaseSpinLock(&Port->Lock, oldIrql); > > > >+ if (Request == NULL) >+ { >+ ObDereferenceObject(Port); >+ return STATUS_UNSUCCESSFUL; >+ } >+ > > > if (Request->Message.u2.s2.Type == LPC_CONNECTION_REQUEST) > { > PORT_MESSAGE Header; > > Hi, I think that this fix doesn't solve the real problem. The caller waits on a semaphore and the semaphore is only signaled if a message is in the queue. This means, the caller can't get a NULL pointer from EiDequeueMessagePort(). The real problem is anywhere in KeWaitForSingleObject, which does return STATUS_USER_APC for a non alertable wait. That is wrong. - Hartmut

20 years

New Webserver System

by Rick Langschultz

I was kicking around the idea of installing a jabber server on my companies server to allow instant messaging on the local area network. Would reactos.com be willing to do something like that or is that too far out of the scope of the project. I was going to use OpenLDAP for authentication and save all of the conversations in XML files in both senders and recipients home folders. I also was going to write an XSL to display those messages. I think this would help out both developers and users of reactos. Including future RosMessenger or something like that... Just a though... Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

20 years

Re: proper nt-style authentication (reactos, wine, samba tng)

by Luke Kenneth Casson Leighton

andrew bartlett, your sarcasm is totally inappropriate, and you are completely out of line, and you damn well know it. get a grip, and if you cannot do so, do not embarrass yourself or the reputation of the samba team, which you represent by utilising a "samba.org" email address, by replying at all. i also cannot reply and tell you this because of a decision made on the 15th december 2004 by the samba team to block all email sent by me to samba.org and to treat any such attempts as "net abuse". if you pick up this message on the mailing lists i hope that you will, should you wish to make useful contributions to this discussion, provide a suitable email address to which i can reply. anyway: in order to move discussions _forward_ rather than put it on an actively hostile footing, i will rewrite your message in a more appropriate manner and i trust that this meets with your approval. i will then reply to it. "dear luke, thank you for raising this issue. your message is a bit long, so i will skip most of it and mention just one thing. i trust that you are aware that NTLM authentication has been provided for quite some time to external services, in a number of ways. as you helped design one of those methods (the winbind_auth_crap :) and guided tim in its implementation, i am puzzled by the fact that it was not mentioned in your message. there is also an additional method which has been developed in samba 3, called ntlm_auth, which has even been utilised by a SOC Google student. both these methods avoid reimplementation of NTLMSSP: what therefore are you proposing that is, if at all, different from this? i don't understand: perhaps you could explain? anyway, it is good to hear from you and your design input even if it is a little bit mad is always welcome. best regards, andrew bartlett." now, pretending that you have written the above paragraphs instead of the ones below, i will proceed. without sarcasm and without endeavouring to be totally and blatantly and unnecessarily cruel. dear andrew, thanks for replying, okay. i re-read my message several times and i _knew_ i had missed something out - explicitly mentioning winbind. sorry! and no, i wasn't aware of ntlm_auth: it's good to hear of that because yes it might prove useful. no, of course i am not advocating that NTLMSSP be reimplemented: i will clarify this later in this reply. i should be clear (and this will help rob as well) that the specific focus of my message was directed towards _reactos_ not towards wine (per se). the requirements are therefore quite different. yes, for _wine_ - you (and rob) are absolutely correct: ntlm_auth and winbindd are perfectly adequate. the reason why? samba can be run ON THE SAME MACHINE. samba is a unix service: wine is a win32 emulation layer running _on unix_. the reason why that is inappropriate for reactos? samba cannot run on a win32 platform. therefore any attempt to contact a unix service will require implementation of a POSIX subsystem in reactos as a primary requirement!!! ... oops :) it's that straightforward. there is also a second difference (which isn't anything to do with what you mention - use of winbind or ntlm_auth) which is to do with the implementation: in reactos, things have to be done "properly" in this area (authentication) - and that means implementing an LSASS (lsa security service) MSV1_0.DLL and registering it with the LSASS running in NTOSKRNL. i do not know what has been picked / decided upon for Wine, but for reactos MSV1_0.DLL is definitely the way forward. what else is relevant that i may have missed... oh, yes: samba tng's winbindd. i added an extra "method" to winbindd, which was required for freedce's "ntlmsspauth.so". winbindd pre-modifications (and therefore also the version in samba afaik) does not contain a means to utilise NT+LM hashes plus domain name in unicode plus username in unicode, and it most certainly doesn't return a NET_USER_INFO_3 structure. this is an absolute critical requirement for "authorisation" purposes - not least because the NET_USER_INFO_3 structure, as you are undoubtedly aware (but others might not be so i mention it for completeness), contains the 16-bit "session key". it also contains the group SIDs etc. which are again essential to be returned to the LsaLogonUser (and LsaLogonUserEx) functions - see lsa.c in ReactOS code. so, anyway, this is what i added to samba tng's winbindd and also to a client-side function which freedce's ntlmsspauth.so module could then use. i do not know what nltm_auth does so i could not advise you as to whether it would be appropriate: perhaps you could help out by pointing people to some appropriate documentation on the ntlm_auth API, in order to evaluate whether it would be suitable (possibly even for reactos: i won't know until i see the API) okay. what else. oh, yes. the use of ntlm_auth and/or winbindd to "outsource" authentication is, i believe, a "temporary" measure, that allows the parallel development and maturisation of Wine / ReactOS specific code (in the case of ReactOS, that's MSV1_0.DLL) _without_ having to pull in a shed-load of code. the API is basically this: send (in unicode) a plaintext password, a domain name and a username, and receive a yes/no answer along with a NET_USER_INFO_3 structure, from which the session key and group sids can be "pulled". there's also the second function LsaLogonUserEx which is i believe "send NT+LM hashes, plus unicode domain name, unicode username, and receive..." but it would take a little reverse-engineering to double-check. so yes, in conclusion, i believe that the use of ntlm_auth and/or winbind _may_ be appropriate for Wine, is temporarily appropriate for proof-of-concept in ReactOS, but for final code in ReactOS, definitely not. that's the gist: hope this helps clarify things. l. On Fri, Sep 02, 2005 at 11:25:36PM +1000, Andrew Bartlett wrote: > On Fri, 2005-09-02 at 01:39 +0100, Luke Kenneth Casson Leighton wrote: > > I will leave the rest of this mail well aside, but I just wanted to > clarify exactly how long we have been providing NTLM authentication > services to external projects: > > > 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. > > Like, say the winbind_auth_crap (thank Mr Potter for the name) function > in Samba's winbindd client interface, used successfully by external > projects (Squid in particular) since Samba 2.2? > > Or better still (avoiding reimplementing NTLMSSP) by calling ntlm_auth > (shipped with Samba 3.0 since release)? Oh wait, we hooked up a Google > SOC student to do just that, and it's working well! :-) > > Andrew Bartlett > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Samba Developer, SuSE Labs, Novell Inc. http://suse.de > Authentication Developer, Samba Team http://samba.org > Student Network Administrator, Hawker College http://hawkerc.net -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

20 years

Re: [ros-diffs] [gdalsnes] 17607: mostly naming changes

by Alex Ionescu

Hi, Somewhere in these 14000+ lines, these: - PUSER_OBJECT_HDR hdr; + PUSER_OBJECT_HDR* ppHdr; "naming" changes are going to turn into bugs. I can only see 1000 lines of your patch, and I can already see it's more then just "naming changes". You changed a "pointer" to a "pointer of a pointer". From experience, I can tell you that somewhere in those 14000 lines, there's a place where you forgot to change the dereference to match the new definition. But how can I ever check? The diff isn't posted here, and doing it manually would waste my time. And it also shows me that this patch probably has a lot more then "naming" changes. This is as of now, I think the 4th or 5th gigantic patch in this branch with 1) Dubious changes 2) Changes stuck together (naming changes with code changes, etc) 3) Still no changelog. I am voicing my public disagreement/outcry with the way this branch is being handled. gdalsnes(a)svn.reactos.com wrote: >mostly naming changes > > typedef struct _USER_REFERENCE_ENTRY > { > SINGLE_LIST_ENTRY Entry; > > >- PUSER_OBJECT_HDR hdr; > > >+ PUSER_OBJECT_HDR* ppHdr; > > > } USER_REFERENCE_ENTRY, *PUSER_REFERENCE_ENTRY; > > > > > *[truncated at 1000 lines; 13185 more skipped]* Best regards, Alex Ionescu

20 years

Cash for Trademark - reallocate Donation to huricane efforts?

by Steven Edwards

Hello, We still have the cash in the foundation account for the trademark paperwork. ($525) plus about a hundred in paypal donations not sent to the bank yet. Our lawyer and I have not compleated the paperwork (his slackness and mine) and I have not cut him a check. Some of us would like to put the trademark filing on hold and donate the funds to the RedCross. I would like to have a vote on it among anyone that is a user, tester, developer, or random fan that has donated to the project in the past. If there is a unanimous vote then I will transfer the funds that are in our bank account and whatever is in paypal to the RedCross. If there is a single objection then I will not. I know this project did not get behind the tsunami relief effort (Which we should have) so even if there is a not a unanimous vote for reallocating the foundation funds then I ask that each of you personally donate if you can to the RedCross. The United States Government has really fucked it up and the truth is not being reported on. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

20 years

Re: [ros-dev] Cash for Trademark - reallocate Donation to huricane efforts?

by PM

why are you even posting this? if big floods come to .cz as it came few years ago, you'll send the foundation money to .cz? you should probably realize that there is also live outside USA. anyway, this is ridiculous ... please cut it. -- Best regards Petr Matousek ... when you stare at the sun, what do you see ...

20 years

Re: proper nt-style authentication (reactos, wine, samba tng)

by Luke Kenneth Casson Leighton

hi, rob, thanks for responding. On Fri, Sep 02, 2005 at 12:05:24AM -0500, Robert Shearman wrote: > Luke Kenneth Casson Leighton wrote: > >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. > > > > > > Ok, I want to condense your huge message into a numbered list of things > you say we need: wheeeeee :) > 1. Type marshaling. > 2. IDL compiler. > 3. RPC Server. more specifically, rpc server "infrastructure" from which to develop, create, compile run and support RPC servic_es_. this you gain in the quickest possible way from FreeDCE and in the grungiest possible way from either samba or samba tng. > 4. Authentication. > 5. Services (lsa, netlogon, samr, etc). yep. > Ok, so we are we at with Wine and ReactOS? > 1: We need to implement this anyway because, like you crudely put it, we > are in the crazy business of getting real code like InstallShield and > Office 2003 to work. muhahahahah. hey, Security-Enhanced ReactOS, anyone? :) > 2. We can either use MIDL and accept the problems that go with it (like > not generating code that will compile with gcc 4.0) or we can finish > implementing proxy support in widl. okay. the amount of effort required to modify dceidl to support binary-interoperability with MIDL i do not believe to be very large, but the key bit which _will_ take some expertise (i.e. there are better people than myself to do the job) is the adding of Win32 threading model support to FreeDCE. going down THIS path will GET you code that will compile with gcc 4.0 (and mingw32) AND it would be binary interoperable with MIDL. AND it would actually work, without having to reimplement type marshalling, which if you look at FreeDCE's marshalling/unmarshalling code is SEVENTY THOUSAND LINES of immensely complex code. > 3. We have support for named pipes in the RPC server, what is the "RPC server"? i do not know of such a beast :) > but Wine doesn't > support remote named pipes and AFAIK ReactOS doesn't either. This is not > a problem that should be solved by the RPC runtime. no. it has nothing to do with the RPC runtime. you write a plugin that implements thirty or so functions (which have names like open, write, close etc. funnily enough :) and then register it with the RPC subsystem (yeh, okay, probably the rpc runtime :) e.g. the named pipe transport is called ncacn_np - network computing architecture CoNnection-based named pipes. and then MSRPC clients and MSRPC services can simply utilise that transport automatically or by name. > 4. Kai and Juan are working on delegating NTLM authentication to Samba. ah. brilliant. that's exactly what i outlined as "stage 1" and it should be done by implementing MSV1_0.DLL, for use by LSASS, see LsaLogonUser in the ntoskrnl code, it's a stub at the moment, in the reactos code. > We still need to tie this in to the RPC server though. i do not know what you mean by the "RPC server". no such entity actually exists afaik. > That should be a trivial task in comparison. yes, which is why it is mentioned about 2/3 of the way through my document, as "stage 1". > Not sure how this will fit in on ReactOS. in NTOSKRNL the LSASS implementation, which then has MSV1_0.DLL register with it. i mentioned it in my document. see the two occurrences of LsaLogonUser in reactos code. > 5. Wine isn't really interested in having those types of servers, tough luck for them. nt domain services are a necessary and integral part of supporting win32, even in a stand-alone environment. wine has _bypassed_ the MSRPC bits by instead of utilising MSRPC to split client from server they have "linked" the client-side code with its server-side code, cutting out the MSRPC runtime altogether. due to the incredible way that MSRPC (actually DCE/RPC) is designed, it is perfectly feasible to do this sort of thing, and actually have your code work (just with no networking and no distributed capability) anyway. if the wine team cannot be convinced of the necessity of adding MSRPC into the mix then wine will pretty much remain in the dark ages of interoperability along the lines of "win95 with networking removed". > but it > would be nice for the client code for those to work. I'm not sure that > porting them from Samba would be fruitful as they would fundamentally > need to tie into the registry. yes? :) and? :) i have no problem with that. i'd _love_ to see a registry service implemented in samba tng and then utilised in a samrd to access an NT SAM hive :) it's the way that reactos has gotta go, basically. > So, what you are suggesting is that we instead port FreeDCE and use it > for 1-3 (and 4?). basically and ultimately - yep! BUT, butbutbut - remember, i did say that it is _not_ strictly necessary at the moment. there are ways - and it appears that you are already considering them - to cut down the amount of work required to "GetThingsWorking(tm)", as i described. > This while still having to implement (1) anyway > because of the applications I mentioned that need it. no, you don't have to. you hack FreeDCE into interoperability because it IS the rpc runtime. remember, microsoft adopts code wholesale if they can get away with it. they started from DCE 1.1 reference implementation and ported it to NT. FreeDCE _is_ the DCE 1.1 reference implementation - autoconf'd and modularised. > Then we get to > test two different MSRPC infrastructures and get to fix bugs in one > without it fixing any bugs in the other. Just porting FreeDCE seems like > a lot of work; okay, the reason why it seems that way is because i actually know what's involved and have described to you what's involved. if you described to me what you are endeavouring to do in reimplementing the rpc runtime, i can give you some time estimates on how long it will actually take, and i guarantee you it will make the amount of time i've outlined for porting FreeDCE look like a walk in the park by comparison. that's all. remember, i did EXACTLY the same thing. i looked at the OpenGroup's DCE/RPC documentation, and went "christ almighty i can't possibly be doing with all this" and ignored it. THREE YEARS LATER i was wishing in some ways that i hadn't. the learning curve however of doing on-wire interoperability gave me enough understanding to appreciate just how good dce/rpc really is, and quite how much work is involved. you would do well to LISTEN to that advice of someone who wasted three years of their life NOT listening to advice, who followed the same path as you are following (the not-invented-here path). it will save you a lot of time. you would do well to bite the bullet and utilise your wealth of experience and knowledge learned to-date as a means to "tie in" to the freedce code. you _have_ enough knowledge and expertise now to be able to do that. you alone rob have been dealing with rpc type libraries for, what, two years now? a function-by-function comparison of freedce and wine's rpc runtime will show EXACTLY the same functions, EXACTLY the same arguments, and i started to show you that some six months ago, remember? now there is the reactos project to take into account, too. > perhaps more work than implementing the remaining > features in our own MSRPC infrastructure, even when including the task > of finishing the IDL compiler. Maybe I am being blind, but it seems to > make sense just to carry on in the direction we are going with having > our own MSRPC implementation and being able to "dogfood" our > implementation (i.e. use it for our own proxies/stubs at the same time > as letting applications use it). there is an opportunity to save _everybody_ time, right across the project board. i have said this in 2000 on the samba mailing lists. i have said it on that mailing list discussion six months ago on the wine-devel lists. i am saying it now. freedce is the key to interoperability for samba, wine, reactos, because it is the same code that microsoft hacked into submission to make the services which samba, wine and reactos are independently implementing, without proper reference to each other. samba is implementing "on-the-wire" interoperability without the type-libary interoperability and without the IDL-level and runtime-level interoperability. wine and reactos are implementing "binary-level" interoperability and are avoiding IDL-level and on-wire-level interoperability (by suggesting to developers that they utilise MIDL.EXE) this is complete madness. wine will end up with 100,000 lines of hacked-together and incomplete code. samba has two hacked-together projects of about 100,000 lines of code each. samba tng has its own hacked-together and equally but differently incomplete implementation. whereas FreeDCE is 250,000 lines of code that provides IDL-level interoperability, on-wire level interoperability, and the things that it is missing - win32 threading support, modern (posix) threading support and exact byte-for-byte type library interoperability are TRIVIAL trivial TRIVIAL computer-science first and second year university projects by comparison. each time i mention this, the people implementing their own non-interoperable projects in their own little worlds get deeper and deeper into the shit. if i can't convince people that this is the way forward then i will simply have to give up and come back in five years and see how people are getting on. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

20 years

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