- Ros-dev - ReactOS.org

crash in win32k with the cirrus driver
by Hartmut Birr 13 Jun '05

13 Jun '05

Hi, if I use the cirrus driver in qemu, I get always wrong colors. After the first double click to the cmd icon, ros crashs in DIB_16BPP_BitBltSrcCopy. I've add the following code: Index: subsys/win32k/dib/dib16bpp.c =================================================================== --- subsys/win32k/dib/dib16bpp.c (Revision 15885) +++ subsys/win32k/dib/dib16bpp.c (Arbeitskopie) @@ -228,6 +228,8 @@ } else { + DPRINT1("%d %d %d\n", BltInfo->SourceSurface->lDelta, BltInfo->SourcePoint.x, BltInfo->SourcePoint.y); + DPRINT1("%d %d %d %d %d\n", BltInfo->DestSurface->lDelta, BltInfo->DestRect.left, BltInfo->DestRect.top, BltInfo->DestRect.right, BltInfo->DestRect.bottom); I see often negative values for the source surface: ... (subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69 (subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0 (subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69 (subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0 (subsys\win32k\dib\dib16bpp.c:231) -1120 0 13 (subsys\win32k\dib\dib16bpp.c:232) 1600 69 69 629 87 KeBugCheckWithTf at ntoskrnl\ke\catch.c:222 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. ... I seems that win32k doesn't handle the negative values. I doesn't know what they mean. - Hartmut

3 4

RE: [ros-dev] Visual IDE for ROS
by Murphy, Ged (Bolton) 13 Jun '05

13 Jun '05

Joseph Miller wrote: > So I am currently working on making my Visual GWin++ > project work under ReactOS. If it works under windows, it should work under ROS. If it doesn't, it's likely there is some missing functionality or bugs in ROS at the moment. You shouldn't modify your program to work under ROS if it breaks Windows functionality, as it's likely to be fixed in the future. If it works under Windows but not ROS, try to establish why and report it. This would be a more productive way for both projects. Regards, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

3 2

RE: [greatlrd] 15881: revert back to 15869 for current changebreak 32 / 8 bpp for vbe drv, and vmware drv the mouse did not redaw some dialog box was wrong. andalot more
by Ge van Geldorp 13 Jun '05

13 Jun '05

> revert back to 15869 for current change break 32 / 8 bpp for > vbe drv, and vmware drv the mouse did not redaw some dialog > box was wrong. and alot more Can you show me how to reproduce the problems. It seems to work fine for me in VMware with 8/16/32 bpp and in Qemu with 8/16/24 bpp (all with VBE driver). Gé van Geldorp.

1 0

[Fwd: Re: [ros-diffs] [greatlrd] 15879: fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code.]
by Hartmut Birr 13 Jun '05

13 Jun '05

-------- Original Message -------- Subject: Re: [ros-diffs] [greatlrd] 15879: fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code. Date: Sun, 12 Jun 2005 22:44:48 +0200 From: Hartmut Birr <hartmut.birr(a)gmx.de> Reply-To: ReactOS Diffs List <ros-diffs(a)reactos.com> To: ReactOS Diffs List <ros-diffs(a)reactos.com> References: <000001c56f84$4a6757a0$6b01a8c0@PENELOPE> greatlrd(a)svn.reactos.com wrote: >fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code. > >Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c* > >--- trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:06:38 UTC (rev 15878) >+++ trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:23:40 UTC (rev 15879) > >@@ -454,31 +436,34 @@ > > > ULONG delta = DestSurface->lDelta; > ULONG width = (DestRect->right - DestRect->left) ; > PULONG pos = (PULONG) (DestSurface->pvScan0 + DestRect->top * delta + (DestRect->left<<1)); > > >- color = (color<<16)|(color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */ > > >+ color = (color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */ >+ color += (color<<16); > > > > for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++) > > >- { >- int d0, d1, d2; > > >+ { > > > __asm__ __volatile__ ( > " cld\n" > > >+ " mov %0,%%eax\n" >+ " mov %1,%%ebx\n" > > > " test $0x03, %%edi\n" /* Align to fullword boundary */ > " jz .FL1\n" > " stosw\n" > > >- " dec %4\n" > > >+ " dec %%ebx\n" > > > " jz .FL2\n" > ".FL1:\n" > > >- " mov %4,%%ecx\n" /* Setup count of fullwords to fill */ > > >+ " mov %%ebx,%%ecx\n" /* Setup count of fullwords to fill */ > > > " shr $1,%%ecx\n" > " rep stosl\n" /* The actual fill */ > > >- " test $0x01, %4\n" /* One left to do at the right side? */ > > >+ " test $0x01, %%ebx\n" /* One left to do at the right side? */ > > > " jz .FL2\n" > " stosw\n" > ".FL2:\n" > > >- : "=&A" (d0), "=&r" (d1), "=&D" (d2) >- : "0"(color), "1"(width), "2"(pos) >- : "%ecx"); > > >+ : >+ : "r" (color), "r" (width), "D" (pos) >+ : "%eax", "%ecx","%ebx"); > > > pos =(PULONG)((ULONG_PTR)pos + delta); > } > > >+ > > > #else /* _M_IX86 */ > > for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++) > > What was wrong with the inline code from rev 15869? Previous my changes (rev 15858), the width value was only load in the first loop. This has crashed the vbe driver on real hardware. I've no problems with the current and the last revision, and with normal and optimized builds. The only difference is, that your changes needs two registers more on optimized builds and gcc uses the stack to store some values. There exist one problem in your changes, gcc doesn't know that edi is changed. On other optimisation as the current one, it is possible that gcc uses edi to recalculate the pos value. With optimized build, I mean the optimisation, if DBG is 0. - Hartmut

1 0

Visual IDE for ROS
by Joseph Miller 12 Jun '05

12 Jun '05

Hello list, I am new to ReactOS, but very interested in Win32 programming. I am also very new to Win32 and C++, but I began a project about a year ago to develop and open source Visual C++ IDE for Win32 because I had not found an open source one yet. Well, it was one of my first attempts at Win32 and at C++, but I managed to create a very basic IDE and I have successfully created several programs for both work and other projects. Everything is based on a class called GWin. I feel like the GWin code is very stable, even at this point, but much of the API will probably still change as I learn about Win32. Unfortunately, the IDE code is pretty dang crappy because I did not understand some very basic programming concepts. To make a long story short, the IDE has been developed to a usable point, and the code in the GWin class is worth continuing. The IDE itself is undergoing a major rewrite for better functionality and structure. Yesterday I installed ReactOS for the very first time on my computer. I was impressed with the number of programs that actually work at this stage of development. Even Scite (an excellent, code-highlighting editor) works! So I am currently working on making my Visual GWin++ project work under ReactOS. I have managed to get it running and compile a test program under ReactOS, so with a little more testing, I will release a version just for ROS. I will also be working on a tutorial for how to get started with it. Visual GWin++ currently has support for windows, edit controls, static controls, listbox controls, MDI clients (limited), tabcontrols, and scrollbars (limited). The program can load and save projects in an XML file format using libxml. The current version is v0.02-pre-alpha. You can see the Windows version at http://www.calcmaster.net/visual-c++/ . When the ROS version is ready, I will release it. I would like some feedback on what you guys think about this project and whether or not you think it will be a benefit to ROS. BTW, I came across some message handling bugs in ROS and I guess this is the mailing list to report it? I will try to download the source and look it over, but I wanted to let you guys know first. I had a handler set up for EN_KILLFOCUS on one of my edit controls. The function was supposed to modify another window and then return. I'm assuming what happened was that as my function was modifying the other window, ROS kept assuming that it needed to send more EN_KILLFOCUS messages to me to let me know my control had lost focus. I had to add a hack to make sure that after the handler is called the first time, it is not called again until it has completed what it needs to do. I had a similar problem with LBN_SELCHANGE when I tried to kill the control's parent window. ROS assumed that this meant it needed to tell me that the selection had changed and sent LBN_SELCHANGE. This caused the same type of loop that I described above. Where do I look to correct this? -Joseph

1 0

winfile czech translation
by Martin Fuchs 12 Jun '05

12 Jun '05

Hello, is there some native czech speaker? I have attached two different czech resource files of winefile: one from WINE, and the other from ReactOS. Perhaps some one can compare the two files and search the better alternatives where the strings differ. Thanks, Martin

4 4

Re: [ros-svn] [hbirr] 15877: Print more informations on a BSOD by enabling the debug prints to the screen.
by Alex Ionescu 12 Jun '05

12 Jun '05

hbirr(a)svn.reactos.com wrote: >Print more informations on a BSOD by enabling the debug prints to the screen. > > > >Updated files: >trunk/reactos/ntoskrnl/ke/bug.c > > > Hi... Erm...I don't understand this change. BSOD data is already printed on screen during a crash. The only thing that's not printed is ROS-Specific Debug Data, because that's part of "debug output" and not of an official BSOD. At least that's how it's fundamentaly defined... I really don't like this hack, although I know you'll probably say you want the debug data on screen, but my question is why don't you use /DEBUGPORT=SCREEN for this? You're hacking the kernel to display debug data when debugging is off... And I hate the #if 0 #else #endif stuff you've added, it makes this hack even nastier! If you *really* want to bypass the debuging design and force debug-data to be printed when it shouldn't, at least make a nicer hack please (ie, modify KeDumpStackFrames to use InbvDisplayString). I'm sorry but this patch is unacceptable to me...it makes the code look like shit. Best regards, Alex Ionescu

2 1

make module_depends
by Casper Hornstrup 12 Jun '05

12 Jun '05

I've implemented the module_depends targets as a substitute for make module_clean && make module. This is much faster than the depends target since it only checks the dependencies for a single module. Casper

1 0

N/T: Cirrus Binary: http://www.relsoft.net/cirrus.rar
by Alex Ionescu 11 Jun '05

11 Jun '05

1 0

ROS Performance Numbers
by Alex Ionescu 11 Jun '05

11 Jun '05

3 4

Re: New OS built on ReactOS and WinuxOS technology!
by Hartmut Birr 11 Jun '05

11 Jun '05

Hi, it seems, that the Hostilix's people doesn't like their own past. The WinuxOS project on SourceForge was deleted. - Hartmut

2 1

Re: [ros-svn] [ion] 15854: Support QEMU Hardware Acceleration
by Alex Ionescu 10 Jun '05

10 Jun '05

ion(a)svn.reactos.com wrote: >Support QEMU Hardware Acceleration > > >Updated files: >trunk/reactos/bootdata/hivesys.inf > > I will provide a working binary soon. It hits some bugs in our BitBlt code, maybe due to the recent optimizations. However a rosperf gives me 1600 fills/sec vs 232 fills/sec on the same machine with the same testing setup. That's a 8x improvement! Best regards, Alex Ionescu

1 0

New OS built on ReactOS and WinuxOS technology!
by Rafal Kupiec 10 Jun '05

10 Jun '05

Hi... I'm from BetaComp Team and I with all team members are making new operating system that will be compatible with Windows NT. It will also have Posix and its own sybsystems. It's based on knowed for most people project named ReactOS and our previously project named WinuxOS. More about HostiliX you can read on www.betacomp.info web page in Our projects sections. Actually we're working on v0.1. When we done do it we will publish binary version and all source code. Currently we're looking for people who knows C/C++ or Assembler and wants to help us. If you have a free time, please help us and join to our team! Contact: rafkup(a)gmail.com

15 42

Re: [ros-dev] PowerPC arcitecture?
by Quandary 10 Jun '05

10 Jun '05

On Sat, Jun 04, 2005 at 12:03:48PM -0500, Rick Langschultz wrote: > > I use Outlook XP to compose mail to my boss and to a support team. I > have to use HTML formatting in my mail messages. Sorry for the > inconvenience I have caused. If people want to get picky about the mail > format and not the content of the message, they should re-evaluate their > purposes involved in developing code, and material for computers. > If you've ever tried to read an XML/HTML message in a plain-text reader (such as mutt, which is my client of choice), you would understand why folks complain. To draw an analogy as to how silly your claim is (that the formatting should be ignored completely), consider the following scenarios: 1. A huge C program that works, but has no comments and obfuscated code. "If you can't understand it without comments, you should re-evaluate your programming ability." 2. A patch that has thousands of formatting changes intermixed with bugfixes. "If you can't appreciate the functionality of a freely offered patch that seems to fix a bug, you should re-evaluate your stance as a community-based project." 3. Documentation provided in rendered PS (or another opaque format). "If you can't appreciate the accuracy and user-friendliness of the documentation, you should re-evaluate your position on having a well-documented system." See, these are all silly. It's easy for one side to just ignore the other -- yes, you may need whatever formatting HTML provides you for work correspondence; it's easy for you to forget that it's even there. Likewise, it's easy for those of us who edit and send raw text to ignore how engrained HTML can be in some mail front-ends. But at the end of the day, the lowest common denominator is plain-text -- and that's something folks will expect you to conform to. Just like a patch with a thousand formatting changes, now matter how many bugs it fixes, it will be rejected. So to with your mails -- no matter how good the merit is, if we have to mind-parse the gibberish, it's just going to be outright rejected. Thanks for understanding, -- Travis > Rick Langschultz > > -----Original Message----- > From: ros-dev-bounces(a)reactos.com [mailto:ros-dev-bounces@reactos.com] > On Behalf Of Mike Nordell > Sent: Saturday, June 04, 2005 9:19 AM > To: ReactOS Development List > Subject: Re: [ros-dev] PowerPC arcitecture? > > Rick Langschultz wrote: > > > <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > [lots and lots of useless XML tags mixed in an unholy cesspool with HTTP > snipped] > > Could you please trim that crap? I am, as I hope the majority of list > subscribers are too, not especially interested in that you wrote an > e-mail > in MSWord and that your "SpellingState" is "Clean". > > Please use plain-text only. > > Thank you for your cooperation. > > /Mike > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev > __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

3 2

ros crashs
by Hartmut Birr 09 Jun '05

09 Jun '05

Hi, a double click on the cmd icon does crash reactos. - Hartmut Using shell hooks for notification of shell events. (subsys\win32k\ntuser\hook.c:554) Not implemented: HookId 3 Global TRUE (lib\shell32\shlexec.c:1026:ShellExecuteExW32) flags ignored: 0x0000000c KeBugCheckWithTf at ntoskrnl\ke\catch.c:222 Page Fault Exception: 14(2) Processor: 0 CS:EIP 8:9d886596 <win32k.sys:6596 (subsys/win32k/dib/dib16bpp.c:50 (DIB_16BPP_HLine))> cr2 9e9dc000 cr3 1f455000 Proc: 80f1cc48 Pid: 74 <csrss.exe> Thrd: 81727530 Tid: 114 DS 10 ES 10 FS 30 GS 23 EAX: ffffffff EBX: 0000ffff ECX: 7ff8a52e EDX: ffffffff EBP: 9df0bc60 ESI: 0000025d ESP: 9df0b818 EDI: 9e9dc000 EFLAGS: 00010a17 kESP 9df0b818 kernel stack base 9df09000 Frames: <win32k.sys:110ab (subsys/win32k/eng/lineto.c:539 (IntEngLineTo))> <win32k.sys:3ca9d (subsys/win32k/objects/fillshap.c:119 (IntGdiPolygon))> <win32k.sys:3d53a (subsys/win32k/objects/fillshap.c:874 (NtGdiPolygon))> <ntoskrnl.exe:603f2 ({standard input}:180 (KiSystemService))> <user32.dll:24f14 (lib/user32/windows/draw.c:1064 (UITOOLS95_DrawFrameCaption))>

2 4

Re: [ros-dev] Re: [ros-svn] [navaraf] 15830: - Unlock GDI objects by pointer, not by handle.
by Filip Navara 09 Jun '05

09 Jun '05

2 2

Re: [ros-dev] Re: New OS built on ReactOS and WinuxOS technology!
by Quandary 09 Jun '05

09 Jun '05

On Thu, Jun 09, 2005 at 11:11:54AM -0400, Michael B. Trausch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Quandary wrote: > > > > I call BS. The Lotus 1-2-3 fiasco and the Apple vs. > > MS suit are the two things that come immediately to > > mind as legal precedence. You can't copyright a > > "layout" (read: look and feel, menu structure, > > screen order, etc.). If you are referring to > > directory layout on the disk itself, I think you > > will have a VERY hard time trying to argue that > > it's copyrightable -- since layout is effectively > > the command-line look-and-feel for a given disk. > > You don't have to look far for proof on that, > > either; moving between various *ix distros, it's > > easy to get lost when one distro stores its files > > in a different place from where you're expecting. > > > There was no direct layout issues there. Yes, you are correct. My argument is that layout is a subset of look and feel. Because menu structuring *is* included in the l&f deal, and file hierarchies are analagous to menu hierarchies, I argue that the ruling applies. > If you'd like to see an example such as what I've > described, you may take a look at OpenBSD's use of > this: > > http://www.openbsd.org/faq/faq3.html#ISO > > This is something that the OpenBSD people > (specifically, Theo de Raadt) have held for years to > help use the law to provide a means of securing > their distribution and making it official. Has it held up in court? Thousands of bad patents are filed every year, and if/when they go to court for enforcement, they are discarded. That's patent law, but the same concept holds for -everything-: just because you -say- something is valid under the law does not make it so. > It is protected by Copyright because it is subject > to Title 17, Chapter 1, Section 102, Paragraph (a): > > (a) Copyright protection subsists, in accordance > with this title, in original works of authorship > fixed in any tangible medium of expression, > now known or later developed, from which they can be > perceived, reproduced, or otherwise communicated, > either directly or with the aid of a machine or > device. (b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. I can copyright the following: My filesystem layout. Copyright 2005, me. All rights reserved. /boot/ /dev/hda /dev/hda1 /dev/hda2 /dev/hdb /dev/hdb1 /etc/rc No one is allowed to copy that text, but anyone is allowed to implement the idea behind it -- i.e., a heirarchal filesystem with the specified directories and files. Well, directories and filenames are just lists of strings like that on the disk, right? Thus, are they not subject to copyright like my above example? Well, using mkdir and touch (well, mknod ;), I can come up with exactly that file layout, and dump the exact same text (sans the copyright crap) using find or ls. So... is it really the filesystem layout that's copyrighted? No, it can't be, because I just demonstrated how it could be duplicated by using the implied procedure that was very clearly described by the file listing. It is (as you put later), if anything, that instance of the filesystem that he created which is copyrighted. > The file-system layout of the ISO image that the > OpenBSD project has is not a "look and feel" of > anything, It is when I'm in a bash session, ls-ing and trying to find my way around. Note that the lotus 1-2-3 issue was about navigation -- key bindings. Having the same file format layout is equivalent to having the same key bindings or navigation. > it is a particular layout of a filesystem image. > Saying that they cannot copyright an image of a > filesystem is like saying that you cannot copyright > an image taken with a [digital] > camera: You cannot copyright the concept of ISO or > JPG, for example, but you can copyright one > particular incarnation of an ISO or JPG, in a > particular pattern of bits, as a compliation. Actually, this is an excellent example as to why copyright both doesn't really work and is a bit silly in the digital age: You're claiming copyright to a big number. If I went to court and said, "I own 42 when it's interpreted like so..." I'd be laughed out. Even really important numbers (like mersenne primes, that take a -lot- of work to find) can't be copyrighted. We're drawing a line, therefore, that is totally arbitrary. But I digress... Making a digital copy of his ISO *might* be copyright infringement (though I still doubt it). However, even in the case that it is, I can make a layout that exactly duplicates his (with mkdir & mv), make an ISO that is completely identical, and NOT be infringing his copyright by distributing it (according to my prior arguments). > Walnut Creek and other CD-compilations have done this > for years. The CD Compilation gets the copyright, > not the general system. I am not too familiar with Walnut Creek (I just googled for it), but in a nutshell (groan), it sounds like they trawl mailing lists, etc., put them on CD and sell them. Now, the reason this -isn't- legal is because they are making copies without the consent of the author. It's the offline equivalent to file sharing -- it's no more legal for me to go out and trawl the web for MP3's, put them on a disk and sell that as a compilation. The fact is, I'm making copies of music that I may or may not have the authorization to copy (depending on the license, which is really where the whole meat of this particular issue is). "Freely accessible archives" give the -person requesting access to the page- the right to download and view the contents; it does NOT give that end-user the right to turn around and redistribute it (UNLESS you download it, burn it, and sell it under your Fair Use Right of First Sale, repeating the process for each disk; this is a loophole). Caching proxies may also be illegal, but that's a can of worms I don't want to get into... Now, they may not have been taken to court, but that doesn't mean that it's legal, nor that a judge wouldn't find them guilty of copyright infringement. > > > > Again, I'm going to call BS. You don't get > > copyright on an aggregation of work. If I went and > > copied all the articles (and ONLY the articles) > > out of a newspaper that ran only syndicated > > stories, the real copyright owners would have to > > come after me -- the newspaper could not. The only > > way the paper could come after me is if I > > accidentally copied content that (1) one of their > > writers wrote as a "work for hire," and that the > > paper holds the copyright to, or (2) I > > inadvertently copied one of their trade/service > > marks, implying their endorsement of the copied > > content when no such endorsement exists. > > > > Copyright on an "aggregation of work," as you have > called it falls under Title 17, Chapter 1, Section > 103, Paragraphs (a) and (b): Subject matter of > copyright: Compilations and Derivative Works. See > text: > > (a) The subject matter of copyright as specified by > section 102 includes compilations and derivative > works, but protection for a work employing > preexisting material in which copyright subsists > does not extend to any part of the work in which > such material has been used unlawfully. > > (b) The copyright in a compilation or derivative > work extends *** EMPHASIS *** > only to the material contributed by the author of > such work, > as distinguished from the preexisting material > employed in the work, and does not imply any > exclusive right in the preexisting material. The > copyright in such work is independent of, and does > not affect or enlarge the scope, duration, > ownership, or subsistence of, any copyright > protection in the preexisting material. > Which means that my newspaper example is spot on. Since the look and feel of the paper cannot be copyrighted (ordering of articles, number of columns, etc.), and the articles are syndicated (i.e., the paper gets a license to publish them, and doesn't hold the copyright), the paper cannot come after me. Well, they possibly could under some circumstances (like if they edited an article), but this is again assuming that they have done *nothing but aggregate*. Translate articles to files, ordering of articles to ordering of files, and paper to BSD, and the metaphor is complete. > > > > I'm not a lawyer. If you can show me something in > > copyright law (and, to be clean, I'm talking US > > copyright law) that proves me wrong, I'll be happy > > to either adjust my argument or, if I'm outright > > wrong, eat my words. However, I have spent some > > quality time with title 17 (looking for > > loopholes), and I'm pretty confident that I'm on- > > target. > > > > Nor am I an attorney; however, it is a matter which > I've conferred on in the past. The protections are > there in the most basic of Copyright Law, also > enforced internationally. If I understand correctly, what is enforced internationally is the Berne Convention, which I have not read up on. I also believe that trade agreements allowing for extradition are one of the other key tools that the US uses to enforce copyright abroad, though that statement's coming off the cuff and should be subject to verification ;). Excellent points; if you have any further refinements or counterclaims, again, feel free to make them. -- Travis __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/

1 0

Uhci Driver Hacks
by James Tabor 09 Jun '05

09 Jun '05

Hi all, This is the latest hacks I have for now. I will be out for a week so have fun. hpoussin is a major help with the pnp code. I'm using it as a guide. Thanks to hpoussin for making the ioctl code work. You will see some of my hacks, just ignore them. hpoussin found a bug in setupapi. I think we do not have cfgmgr32.dll so our setupapi doesn't forward to it as it should. (drivers/usb/cromwell/uhci/create.c:30) UHCI: IRP_MJ_CREATE (drivers/usb/cromwell/uhci/create.c:41) UHCI: open HCDx successfull (drivers/usb/cromwell/uhci/devctrl.c:65) USB: IRP_MJ_DEVICE_CONTROL dispatch (drivers/usb/cromwell/uhci/devctrl.c:78) USB: IOCTL_GET_HCD_DRIVERKEY_NAME (ntoskrnl/io/pnpmgr.c:66) IoGetDeviceProperty(80c37000 1) (ntoskrnl/io/pnpmgr.c:164) KeyNameBuffer: 8cf9abd8, value HardwareID (KERNEL32:lib/kernel32/mem/global.c:76) GlobalAlloc( 0x40, 0xAC ) (drivers/usb/cromwell/uhci/devctrl.c:65) USB: IRP_MJ_DEVICE_CONTROL dispatch (drivers/usb/cromwell/uhci/devctrl.c:78) USB: IOCTL_GET_HCD_DRIVERKEY_NAME (ntoskrnl/io/pnpmgr.c:66) IoGetDeviceProperty(80c37000 1) (ntoskrnl/io/pnpmgr.c:164) KeyNameBuffer: 8ce28808, value HardwareID (drivers/usb/cromwell/uhci/devctrl.c:98) USB: IOCTL_GET_HCD_DRIVERKEY_NAME retur ns 'PCI\VEN_1106&DEV_3104&SUBSYS_73401462&REV_82' (KERNEL32:lib/kernel32/mem/global.c:76) GlobalAlloc( 0x40, 0x2D ) (lib/setupapi/cfgmgr.c:327:CM_Locate_DevNodeA) 0055fab0 00000000 0 Unhandled exception Address: 76670ff4 C:\ReactOS\system32\setupapi.dll CS:EIP 1b:76670b93 DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 EBP: 0055fa5c ESI: 00000000 ESP: 0055fa64 EDI: 00000000 EFLAGS: 00000202 Frames: 76660000+10ff4 C:\ReactOS\system32\setupapi.dll 400000+3f73 C:\ReactOS\usbview.EXE 400000+1ddc C:\ReactOS\usbview.EXE 400000+1ba1 C:\ReactOS\usbview.EXE 400000+188e C:\ReactOS\usbview.EXE 400000+16d0 C:\ReactOS\usbview.EXE 77e50000+5196c C:\ReactOS\system32\USER32.dll 77e50000+51b38 C:\ReactOS\system32\USER32.dll 77e50000+3915f C:\ReactOS\system32\USER32.dll 77e50000+5196c C:\ReactOS\system32\USER32.dll 77e50000+5261a C:\ReactOS\system32\USER32.dll 77e50000+374df C:\ReactOS\system32\USER32.dll 77e50000+38c9f C:\ReactOS\system32\USER32.dll 77e50000+38dc5 C:\ReactOS\system32\USER32.dll 400000+14a7 C:\ReactOS\usbview.EXE 400000+1417 C:\ReactOS\usbview.EXE 400000+457f C:\ReactOS\usbview.EXE 7c800000+2eb83 C:\ReactOS\system32\KERNEL32.dll (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (subsys/win32k/ntuser/class.c:114) Failed to lookup class atom! (drivers/usb/cromwell/uhci/uhci.c:479) UHCI: IRP_MJ_CLEANUP (drivers/usb/cromwell/uhci/close.c:30) UHCI: IRP_MJ_CLOSE Thanks, James ps hpoussin, go for it dont stop on my account! 8^D

2 1

Re: [ros-dev] Re: New OS built on ReactOS and WinuxOS technology!
by Quandary 09 Jun '05

09 Jun '05

On Thu, Jun 09, 2005 at 08:20:24AM -0400, Michael B. Trausch wrote: <snip> > (Another aside: The Foundation can, at its > discretion, create an official "layout" for the > installer CD and then Copyright that layout, such > that nobody else can use it. While it's possible, > it can effectively "cramp" the software and > innovation surrounding it, and it's not advisable. > Others then must choose different "layouts" for > their installers of their derived works, and this > would require heavy modifications to installers and > the like to find files in new locations.) I call BS. The Lotus 1-2-3 fiasco and the Apple vs. MS suit are the two things that come immediately to mind as legal precedence. You can't copyright a "layout" (read: look and feel, menu structure, screen order, etc.). If you are referring to directory layout on the disk itself, I think you will have a VERY hard time trying to argue that it's copyrightable -- since layout is effectively the command-line look-and-feel for a given disk. You don't have to look far for proof on that, either; moving between various *ix distros, it's easy to get lost when one distro stores its files in a different place from where you're expecting. If you can show me legal precedence for your statements, I'll be happy to reconsider my stance. I assume if you're making these claims, you have something to back them up, and I'm interested in hearing what your support is. <snip> > A little bit about Copyright Law, now. A developer > holds copyright to the portions of the code that > (s)he contributed to the project, and that is all. > The group that is responsible for putting it > together, then owns the copyright on the layout, and > so forth. So, if releases are the Foundation's job, > then whether they claim their Copyright or not, it > is, in fact, their Copyright. If someone other then > the Foundation packages it for the ReactOS web site, > then *THEY* hold the Copyright, and they can > therefore claim that they are "the" Copyright holder > for the Official Distribution of the ReactOS > project. Again, I'm going to call BS. You don't get copyright on an aggregation of work. If I went and copied all the articles (and ONLY the articles) out of a newspaper that ran only syndicated stories, the real copyright owners would have to come after me -- the newspaper could not. The only way the paper could come after me is if I accidentally copied content that (1) one of their writers wrote as a "work for hire," and that the paper holds the copyright to, or (2) I inadvertently copied one of their trade/service marks, implying their endorsement of the copied content when no such endorsement exists. <snip> I'm not a lawyer. If you can show me something in copyright law (and, to be clean, I'm talking US copyright law) that proves me wrong, I'll be happy to either adjust my argument or, if I'm outright wrong, eat my words. However, I have spent some quality time with title 17 (looking for loopholes), and I'm pretty confident that I'm on-target. Cheers, -- Travis Legal precedence (1-2-3, Apple vs. MS): http://www.swiss.ai.mit.edu/6805/articles/int-prop/software-copyright.html Title 17 US Copyright Law http://www.copyright.gov/title17/ __________________________________ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html

4 3

Trademark update and other stuff
by Steven Edwards 09 Jun '05

09 Jun '05

Hi All, We have now reached our goal of $500 to file the paperwork to register the Trademark name and logo of ReactOS in the state of South Carolina. The next step will be filing for the entire US which I have to go to another lawyer on. I expect to do the federal paperwork, it will cost us about the same but I don't know when that will happen so if you were just going to make a donation for the Trademark stuff you can hold off. If anyone in the user community would like to make donations to support general development causes let me know and I can start allocating funds for bounties. On another note I have opened up a bank account for the foundation so if you don't want to use paypal but you want to make a donation contact me and I can provide routing information. Thanks to everyone that has helped with this! Even if you are not able to write code, your donations, testing, translation, promotion and artwork for ReactOS help the project! -Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

Re: [ros-svn] [hbirr] 15821: - Changed the calculation of the base address of an image section.
by Alex Ionescu 08 Jun '05

08 Jun '05

hbirr(a)svn.reactos.com wrote: >- Changed the calculation of the base address of an image section. >- Removed some unnecessary members from section object. >- Changed the allocation of a section object back to paged pool. > > > >Updated files: >trunk/reactos/ntoskrnl/include/internal/mm.h >trunk/reactos/ntoskrnl/mm/section.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Thanks Hartmut. If you're up for it, here are the public NT structures used...maybe it won't be a bad idea if we use them if it's not too much code change: lkd> dt _SECTION_OBJECT -b +0x000 StartingVa : Ptr32 +0x004 EndingVa : Ptr32 +0x008 Parent : Ptr32 +0x00c LeftChild : Ptr32 +0x010 RightChild : Ptr32 +0x014 Segment : Ptr32 lkd> dt _SEGMENT_OBJECT +0x000 BaseAddress : Ptr32 Void +0x004 TotalNumberOfPtes : Uint4B +0x008 SizeOfSegment : _LARGE_INTEGER +0x010 NonExtendedPtes : Uint4B +0x014 ImageCommitment : Uint4B +0x018 ControlArea : Ptr32 _CONTROL_AREA +0x01c Subsection : Ptr32 _SUBSECTION +0x020 LargeControlArea : Ptr32 _LARGE_CONTROL_AREA +0x024 MmSectionFlags : Ptr32 _MMSECTION_FLAGS +0x028 MmSubSectionFlags : Ptr32 _MMSUBSECTION_FLAGS lkd> DT _CONTROL_AREA +0x000 Segment : Ptr32 _SEGMENT +0x004 DereferenceList : _LIST_ENTRY +0x00c NumberOfSectionReferences : Uint4B +0x010 NumberOfPfnReferences : Uint4B +0x014 NumberOfMappedViews : Uint4B +0x018 NumberOfSubsections : Uint2B +0x01a FlushInProgressCount : Uint2B +0x01c NumberOfUserReferences : Uint4B +0x020 u : __unnamed +0x024 FilePointer : Ptr32 _FILE_OBJECT +0x028 WaitingForDeletion : Ptr32 _EVENT_COUNTER +0x02c ModifiedWriteCount : Uint2B +0x02e NumberOfSystemCacheViews : Uint2B lkd> dt _SEGMENT +0x000 ControlArea : Ptr32 _CONTROL_AREA +0x004 TotalNumberOfPtes : Uint4B +0x008 NonExtendedPtes : Uint4B +0x00c WritableUserReferences : Uint4B +0x010 SizeOfSegment : Uint8B +0x018 SegmentPteTemplate : _MMPTE +0x01c NumberOfCommittedPages : Uint4B +0x020 ExtendInfo : Ptr32 _MMEXTEND_INFO +0x024 SystemImageBase : Ptr32 Void +0x028 BasedAddress : Ptr32 Void +0x02c u1 : __unnamed +0x030 u2 : __unnamed +0x034 PrototypePte : Ptr32 _MMPTE +0x038 ThePtes : [1] _MMPTE lkd> dt _SUBSECTION +0x000 ControlArea : Ptr32 _CONTROL_AREA +0x004 u : __unnamed +0x008 StartingSector : Uint4B +0x00c NumberOfFullSectors : Uint4B +0x010 SubsectionBase : Ptr32 _MMPTE +0x014 UnusedPtes : Uint4B +0x018 PtesInSubsection : Uint4B +0x01c NextSubsection : Ptr32 _SUBSECTION I think it's important because many of the Section implementation details are documented in books (including driver-related books) and known to driver developers who might be using the structures in their code... I can name NT Insider, Windows Internals 4th Edition and Windows NT File System Internals as some examples...but anyways it's just an idea. There's even a nice diagram in one of the books: As a sidenote, do we have a PFN Database? It seems so much of our Mm is messy and old code that was written in a hurry to get ReactOS to work. I dislike the abusive use of macros and the difficult to understand code (imo). Best regards, Alex Ionescu

3 3

Re: [ros-svn] [hbirr] 15836: Changed back to the GPL.
by Alex Ionescu 08 Jun '05

08 Jun '05

hbirr(a)svn.reactos.com wrote: >Changed back to the GPL. > > > >Updated files: >trunk/reactos/ntoskrnl/include/internal/mm.h >trunk/reactos/ntoskrnl/mm/anonmem.c >trunk/reactos/ntoskrnl/mm/marea.c >trunk/reactos/ntoskrnl/mm/section.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Hi Hartmut, I had someone spend a week to update all our comment module headers and make them the same and remove the old copyright headers. It was decided that there would be one COPYING file in the root which is referred to by the header, and that all the kernel files will follow the format which is already in the files. Please don't start messing up the headers... if you want to update the license/add one, the proper place is the COPYING directory. Or else you're just undoing all the work that was done to standardize the headers. Best regards, Alex Ionescu

4 8

[Fwd: Re: [ros-dev] ReactOS Large Disk support]
by James Tabor 08 Jun '05

08 Jun '05

From: David Eckert <davy2002a(a)gmail.com> I use IDE Controllers ======== Standard floppy disk controller Intel(r) 82371AB/EB PCI Bus Master IDE Controller Primary IDE Channel [Controller] Secondary IDE Channel [Controller] Drives ==== QUANTUM FIREBALLlct08 06 [Hard drive] (6.45 GB) -- drive 0, s/n 392974120588, rev A05.0X00, SMART Status: Healthy There was another drive installed but it stopped registering for some reason (will fix this soon) and it is a 3.2gb drive. On 6/6/05, James Tabor > David Eckert wrote: > > I have 2 harddrives hooked up but when I boot ReactOS on Live CD, > > nothing works, only when i disconnect them does it boot properly... > > > > On 6/6/05, James Tabor > > <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > > > >>David Eckert wrote: > >> > >>>I think the lack of large disk support is a real problem here, people > >>>who download and burn the Live CD for example, MUST disconnect there > >>>large hard drives (2GB or higher), I would STRONGLY urge the > >>>development of large disk support to fix this problem, plus it would > >>>also get to the issue of actually installing on new machines which > >>>have no smaller hard drives on them. > >>> > >>>Best regards, > >>> > >>>David W. Eckert > >>> > >> > >>Please need more info. I tested Ros with 120G, it did not have a problem. > >>Even the ultra test, build Ros on Ros with a 120G. > >>James > >> > > > > > > > > -- -David W. Eckert

1 0

Re: [ros-dev] Re: [ros-svn] [hbirr] 15836: Changed back to the GPL.
by Quandary 08 Jun '05

08 Jun '05

On Wed, Jun 08, 2005 at 06:50:18PM +0200, Hartmut Birr wrote: > Alex Ionescu wrote: > > > False... referring to the COPYING file is enough. > > > I think, we should change the header a little bit: > > /* > * COPYRIGHT: ReactOS Team > * LICENSE: GPL, see LICENCE in the top level > directory > * PROJECT: ReactOS kernel > * FILE: ntoskrnl/ke/apc.c > * PURPOSE: NT Implementation of APCs > * > * PROGRAMMERS: Alex Ionescu (alex(a)relsoft.net) > * Phillip Susi > * ... > */ > > because copyright and license are different things. > Lawyers do like it to find such things. You're missing the first year of publication. __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

1 0

feature request for the new build system
by Hartmut Birr 08 Jun '05

08 Jun '05

Hi, it seems that it doesn't exist a dependency check for precompiled headers. - Hartmut

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev