Re: [ros-dev] Greetings from GSoC student!
Congratulations! -Minas On Mon, Apr 25, 2016 at 6:27 PM, mvardan wrote: > Hello ReactOS community! > > My name is Vardan. > > First of all I want to say thank you to all the members of this community > who helped me to figure out status of works and make a proposal for GSoC. > Also I want to express my gratitude to those who makes decision to accept my > proposal. It is very responsible for me to be accepted for this project. You > can be sure that I'll do my best to be able to meet your expectations. > > For all other members of ReactOS community, I want to introduce myself. I am > 1st year master student from Armenia. I have about 2 years of Linux Driver > development experience. My GSoC project title is "Improve ReactOS USB stack" > and I will be very grateful for any help from anyone of you. I can easily > communicate on Russian and English. > > During this month after submission and before acceptance I have done some > investigation of ReactOS and it's built environment. Related to RosBE I want > to express separate thanks to them who created such environment where > newbies like me are able to easily build and test ReactOS and it's drivers > (even with MSVS!). ReactOS wiki page is also very helpful! > > I have started Investigation of NT driver concepts with "Microsoft Windows > Internals" book and some online articles. Any recommendations related > sources of information are strongly appreciated by me. > > I hope that this GSoC project will be a good starting point for me, to join > to "very small and exclusive ranks of people who know how to do NT systems > development" :) > > Best regards, > Vardan. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GSoC 2016: USB 3.0 Support
Hi Vardan, great to see Armenian surname on the list :) I was in development of ReactOS some time ago so I could probably help/give advices in Real Life if case you step in to this GSoC project. (BTW I have a couple of patches that would be great somebody merge/incorporate into the trunk, since I personally wouldn't do that...) You'd better provide link to your requested task: https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas#USB_3.0_Support Hope somebody from Core team will answer to your questions. Regards, Minas Abrahamyan On Sat, Mar 12, 2016 at 5:53 PM, Vardan Mikayelyan wrote: > Hi, > > My name is Vardan, I am from National Polytechnic University of Armenia, > and this is my 5th year here. I'm student of 1st course of master > program. In parallel to studying I am contributing Linux USB stack and have > community accepted commits which are presented in Linux 4.5-rc4. > > I saw ReactOS in GSoC organizations list, and it interested me as great > place to learn and grow as professional developer. I am interested in > driver development and especially I like USB stack. Because USB supports > many kinds of transfers and USB protocols are interesting by themselves. > I have investigated dwc2 driver in Linux Kernel. As you may know it is > driver for dual-role HS USB controller, so I am familiar with USB HCD and > gadget stacks. > > I have looked into ReactOS's git repo and saw that there is completely > missing XHCI driver. In case of OHCI, UHCI and EHCI I saw Michael > Martin's and Johannes Anderwald's drivers. As I understand one of them or > someone from this community will be the mentor for the XHCI project in > terms of GSoC 2016. For me is very interesting to work on NT platform, > because till now I had only Linux Kernel development practice. > > I have few questions as probable applicant, > > 1. Should the deliverable XHCI driver support all kind of transfers? > 2. How it will be tested and should it pass any kind of certification with > any XHCI host controller? > 3. Should it have support for non transfer related features? I mean for > example LPM or Hibernation. > 4. Will whole project entrusted to the one student or he'll be team member? > > From your reply I want to understand what are you expecting form applicant > and how can I fit to your expectations. > > Thanks in advance, > Vardan. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Setup on an extended partition
Thanks for uploading the patch; I got the answer relating the kernel part. As far as I can see your two patches are here integrated in one bigger. On Fri, May 1, 2015 at 10:56 PM, stack exchange wrote: > Am 30.04.2015 um 20:06 schrieb David Quintana (gigaherz): > >> Upload the patch to JIRA, create a new issue entry if none exists for >> this. It's the preferred way to contribute to the project. People only >> get write access after they have proved themselves with writing >> patches, and the team trusts them to have some minimal quality and >> behaviour standards. ;P >> >> We have few knowledgeable developers so the process sometimes takes a >> bit of time. If we missed a patch, feel free to join IRC and slap some >> of us there. >> > > I uploaded the patch now: https://jira.reactos.org/browse/CORE-9641 > > The other patch I created a month ago, which is also for the setup, is > this one: https://jira.reactos.org/browse/CORE-9453 > > I also documented the known issues in the report. I hope the patch will be > applied soon, because I'd hate to have to many local changes without > syncing to the TRUNK. > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Setup on an extended partition
Hi, Thanks for working on that, it was long time anybody is touching here (in spite of it is very important part, as I described); Please share your work in form of patch in Jira, as attachment, and I will look at it; You are right in that there is a problem with ROS organizing the patch reception and/ or adoption. And a question: Does your code only install on the extended partition? Haven't you looked at that kernel part (ntoskrnl) that loads the OS, or maybe did something there? Regards, -M On Thu, Apr 30, 2015 at 9:51 PM, stack exchange wrote: > Am 05.04.2015 um 10:36 schrieb Minas Abrahamyan: > >> 2 This feature is extreamely useful for any Windows user-- especially for >> ones with busy all primary partitions: 2 backup partitions, one C: and one >> just anything other, Linux or OsX - and you very need extended partition to >> keep Reactos >> >> 3 This feature is extreamely needed for just any real-life (==real >> hardware) Reactos tester and developer: see p.2 Plus starting from extended >> partition will allow to have multiple copies of reactos installations, >> which is bread and water for testers. >> The fact this feature is absent just shows where real-life usage by >> testers of Ros is: just nowhere. >> > > I implemented this functionallity, so the installer can now create one or > more logical partitions and can also install it there. There are two issues > though: > > 1. When multiple logical drives exist and they are deleted the installer > crashes. This is IMO just a minor problem, because you can still install, > yu just have to think ahead of what you want. I will look into this later. > 2. This is IMO the more important issue. I verified with a GParted ISO the > partitions and they are corrupted. At first I thought I did something > wrong, but after working on this for several weeks now I'm not so convinced > anymore. When I dump the partition table with my code, it looks exactly as > the dump that it would generate when I create the same layout with gparted, > so it should work. So my assumption is that the implementation in > NtDeviceIoControlFile(IOCTL_DISK_SET_DRIVE_LAYOUT) may be the cause. On the > other hand, when I create only primary partitions (which the existing code > can do) then gparted doesn't report any errors, so it may only be the case > when dealing with logical partitions. > > The question is now, should I upload the current code as a patch as it is > right now, with these known issues, or should I try to fix it completely > before I upload it? > > If I should upload it, I wonder how long it usually takes until it is > commited to the repository, because I submitted a patch in this areay a > month ago, which still has not made it to SVN. Or when/how do you get write > access to SVN? > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Setup on an extended partition
Hi, This misfunctionality has 2 pieces: Reactos unable to start kernel from extended partition, and the installer inability to handle extended partitions 1 MS NT+ supports installing onto the extended partition for ages, including, yes, Windows 7 So this is requirement if only speaking from formal point of view 2 This feature is extreamely useful for any Windows user-- especially for ones with busy all primary partitions: 2 backup partitions, one C: and one just anything other, Linux or OsX - and you very need extended partition to keep Reactos 3 This feature is extreamely needed for just any real-life (==real hardware) Reactos tester and developer: see p.2 Plus starting from extended partition will allow to have multiple copies of reactos installations, which is bread and water for testers. The fact this feature is absent just shows where real-life usage by testers of Ros is: just nowhere. Regards, M. On Sun, Apr 5, 2015 at 12:47 AM, Pavel Pisa wrote: > Hello All, > > I am not sure, but I have feeling, that if you have none > system on some of promary partitions and then place > another copy on extended then it can work and may it be, > that at the time where I have installed my latest > (Windows NT or 2k) I have used such setup. > I have feeling, that NTLDR recognizes partinion numbers > above 4, but there is some difference in the way > how partition numbers are counted when compared to Linux. > Probably that does not work with installer but when > another system partition specification is manually added > to boot.ini on primary partition then it can work. > But I am not sure what is compatibility between NTLDR > versions and Windows versions for last 15 years > of Windows evolution. I remember that I had to correct > machine code of WinNT FAT boot sector code at that days > to overcome overflow for larger sector number > which caused overflow exception in NTLDR load/ > > Anyway, if are you speaking about installing /ReactOS > to extended partition then I suggest to allow such > option at least in expert mode and even installation > of freeldr.sys and FAT bootsector into extended partition > is reasonable because even if Microsoft loader cannot > be used to load foreign system from extended partition. > Any modern boot loader can chain to every FAT partition > which is on any media. Artificial blocking of installation > of ReactOS to extended partition can mean problems with > its coexistence with other primary system when there > is not free primary partition available. > > Best wishes, > > > Pavel > > On Saturday 04 of April 2015 15:23:06 Timo Kreuzer wrote: > > An extended partition is a container for any number of actual > > partitions. Since the normal BIOS boot process uses the master partition > > table, which only contains an entry for the extended partition, not for > > the subpartitions, it cannot handle it. This can in theory be overcome, > > but MS has never bothered, so it's not worth it. > > > > Am 04.04.2015 um 13:25 schrieb stack exchange: > > > OK. So I will put en error message, that it can not be installed on an > > > extended partition. Which is, at least in theory, the same as in > > > Windows 7, then. I guess with a hack you can still do it, but > > > apparently it's not the usuall way. > > > > > > Am 02.04.2015 um 01:39 schrieb João Jerónimo: > > >> On 01-04-2015 08:12, stack exchange wrote: > > >>> If this should be possible though, I would look into it, why it > > >>> fails and try to fix it. Not sure if XP or others allow > > >>> installations on extended partitions, I have to check this (been a > > >>> long time since I last installed an XP > > >> > > >> Window$ generally needs to be launched by means of loading the > > >> partition boot sector at 0x:0x7C00, the old fashioned and DOSy > > >> way. As far as a know, there is no hard limitation preventing one > > >> from doing so with a logical (i.e. inside an extended) partition, but > > >> for some reason, most (if not all) windows versions don't allow that. > > >> When you select a logical partition in windows xp setup, what in > > >> reallity happens is that NTLDR, the boot sector, and stuff are put in > > >> a primiry partition (that must exist and be the active partition), > > >> while all the rest of the OS is put in the partition you select. > > >> > > >> IMHO, ReactOS should not try to clone this "feature"... :-) > > >> > > >> JJ > > >> > > >> > > >> ___ > > >> Ros-dev mailing list > > >> Ros-dev@reactos.org > > >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > ___ > > > Ros-dev mailing list > > > Ros-dev@reactos.org > > > http://www.reactos.org/mailman/listinfo/ros-dev > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@react
Re: [ros-dev] GSoC :: application rejected
And let's finally notice that this year GSoC get cut budget on third or more and didn't include this year even Firefox & Mozilla, so I personally was not been surprised. Regards, -Minas On Wed, Mar 4, 2015 at 1:13 AM, Aleksey Bragin wrote: > Let's be honest to ourselves: that's a typical,very polite, frustration > preventing way to say that they did not choose us for participation for > whatever reasons they had. > > It's their right, it's their wish to actually make Google Summer of Code > happen, so I just want to thank them for helping other open source projects. > > To be fair, there are many interesting, prominent projects which were > selected: > Wine, Mono, Google Kubernetes, LibreOffice, MariaDB, to name just a few. > BSDs got support too: FreeBSD, OpenBSD, but not NetBSD. > > Regards, > Aleksey Bragin > > > On 03.03.2015 22:45, Hermès BÉLUSCA - MAÏTO wrote: > >> I'm wondering what the want to mean by that. >> H. >> >> -Message d'origine- >> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre >> Schweitzer >> Envoyé : mardi 3 mars 2015 14:48 >> À : ReactOS Development List >> Objet : Re: [ros-dev] GSoC :: application rejected >> >> The ReactOS Foundation application got officially rejected "because of >> the numbers of slots available and the high # of terrific applications." >> >> On 03/03/2015 02:08 PM, Hermès BÉLUSCA - MAÏTO wrote: >> >>> We've been yet again rejected for the same "reasons" as before (i.e. no >>> apparent reasons)? >>> >>> Cheers, >>> Hermès. >>> >>> -Message d'origine- >>> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre >>> Schweitzer Envoyé : lundi 2 mars 2015 22:23 À : ReactOS Development >>> List Objet : [ros-dev] GSoC :: application rejected >>> >>> Dear all, >>> >>> The ReactOS Foundation application to GSoC has been rejected this year >>> again. Statistics are not reliable after all. >>> >>> In any case, keep up the good work. We don't need Google to be the bests >>> at what we do. >>> >>> Cheers, >>> -- >>> Pierre Schweitzer System & Network >>> Administrator Senior Kernel Developer ReactOS Deutschland e.V. >>> >>> > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Installing ReactOS to a folder
Hi, Just by copying files with folders wouldn't make it normal ReactOS installation, you also need create boot sector(s) OK by filling it, the problem is we do not have proper tools for it. I.e. tool just like sys.exe/sys.com utility was in DOS/Windows 9x or fixmbr.exe utility is for Windows 2000+ or "bootrec /fixmbr" for WinVista+. More on this could be read here: http://en.wikipedia.org/wiki/Master_boot_record#Editing.2Freplacing_MBR_contents More on ReactOS startup steps described can be found by links here: https://www.reactos.org/wiki/User:Mna.#ReactOS_startup_procedure_described_.28partly.29 Regards, Minas On Wed, Dec 17, 2014 at 7:02 AM, João Jerónimo wrote: > On 09-12-2014 15:52, Aleksey Bragin wrote: > >> I think it's possible to find my rants about that here in ros-dev, and >> there were some replies too which tried to explain why using make install >> such a bad idea. >> > Thanks for the insight... I'll search it. > > As far as I have concluded from looking into the result of the "make > bootcd" command, a simple python script can replace the "make install" > command, by extracting the files in the .CAB into the correct folder (they > are discrimined in another in-CD text file which name I don't remember). > That can be an alternative. > > JJ > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Short announce: My Serial port-on-MMIO implementation works - allowing debug logging on laptops
Aleksey> that's just great! I am convinced in that!) > Do you mind including that to trunk? Surely. For that I was doing it. Now yet some work is needed to be done on it, and then I will submit a patch On Mon, Apr 7, 2014 at 3:45 AM, Hermès BÉLUSCA - MAÏTO < hermes.belu...@sfr.fr> wrote: > Maybe it can go along cportlib :) > It fact the code is already in there, ..I mean in my local directory :) -Minas > > > Hermès. > > > > *De :* Ros-dev [mailto:ros-dev-boun...@reactos.org] *De la part de*Aleksey > Bragin > *Envoyé :* dimanche 6 avril 2014 22:16 > *À :* ReactOS Development List > *Objet :* Re: [ros-dev] Short announce: My Serial port-on-MMIO > implementation works - allowing debug logging on laptops > > > > Minas, > that's just great! > > Do you mind including that to trunk? > > > Regards, > Aleksey Bragin > > On 06.04.2014 22:37, Minas Abrahamyan wrote: > > Hi all, > > With this few words I would like to share the joyous event of MMIO-based > serial port implementation > > has finally worked for me. > > > This is the equivalent of earlycon serial port implementation in Linux > with some extension > > (so now it is even better then Linux one) > > Some work yet is needed to be done to transform the work into the normal > patch, but the good news is > > it is working, and still doesn't require PNPmanager for work, i.e. it > starts very early in kernel and writes kernel log messages. > > I use ExpressCard 34 extension board Serial RS232 port, on laptop, > but think it will work fro PC Cards too (former name PCMCIA). > > > ==Importance: Touching the hardware== > > For the more developers we need more working PC models ( Real Hardware) > > Almost all modern PCs are laptops with PCIe bus (the rest are desktops) > > (but few of them able to boot the ReactOS) > > Modern serial ports are recommended to use /often use MMIO-based data > transfer instead of former I/O ports. > > > So now possibility appears to debug these new computers and force the > ReactOS to work on this important part of new PCs. > > > Thanks for attention > > > -Minas Abrahamyan > > > PS Curious note: for catching the debug logs I use the (small and cheap) > soap box-sized microcontroller board with LCD (ready-unit), and I call it > "ReactOS debug logger" appliance. It doesn't take space and doesn't produce > any noise > > > > > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Short announce: My Serial port-on-MMIO implementation works - allowing debug logging on laptops
Hi all, With this few words I would like to share the joyous event of MMIO-based serial port implementation has finally worked for me. This is the equivalent of earlycon serial port implementation in Linux with some extension (so now it is even better then Linux one) Some work yet is needed to be done to transform the work into the normal patch, but the good news is it is working, and still doesn't require PNPmanager for work, i.e. it starts very early in kernel and writes kernel log messages. I use ExpressCard 34 extension board Serial RS232 port, on laptop, but think it will work fro PC Cards too (former name PCMCIA). ==Importance: Touching the hardware== For the more developers we need more working PC models ( Real Hardware) Almost all modern PCs are laptops with PCIe bus (the rest are desktops) (but few of them able to boot the ReactOS) Modern serial ports are recommended to use /often use MMIO-based data transfer instead of former I/O ports. So now possibility appears to debug these new computers and force the ReactOS to work on this important part of new PCs. Thanks for attention -Minas Abrahamyan PS Curious note: for catching the debug logs I use the (small and cheap) soap box-sized microcontroller board with LCD (ready-unit), and I call it "ReactOS debug logger" appliance. It doesn't take space and doesn't produce any noise ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ndis netvmini adapter
> The userland tool given with the code works > When I run the userland tools, it fails with EnumDevices. So does the userland tool work or not? Do you have .inf file with it? did you try to load the mentioned driver with Add Hardware Wizard? Few words on general process are here: https://www.reactos.org/wiki/How_the_system_Finds_and_Loads_Drivers On Tue, Mar 25, 2014 at 3:25 PM, Maxime Daniel wrote: > Hi, > > I'm trying to compile and test the netvmini ndis 5 adapter code from WDK, > at first to understand how it works, then to modify it for another purpose. > > At this time I: > - put the code on driver/network/dd/netvmini and adapted CMakeLists > - put the inf on media/inf and adapted CMakeLists > - fixed the code, it builds > - add an entry to hivesys.inf to load the driver at boot > > The driver is well displayed during boot, debug message appears (the > DriverEntry), on NtObj, the driver is visible and it appears on "Non Plug > and Play" on device manager. > > Now, I don't know exactly what to do with it. How can I call the driver > and add an adapter ? > The userland tool given with the code works (I needed to comment some > functions and add _DEV_BROADCAST_HANDLE struct by hand, it seems to not be > implemented on dbt.h). > When I run the userland tools, it fails with EnumDevices. > > Some help ? > > Thanks > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] [CORE-7969] A week later
Hi developers, Passed a week after I provided a ready for review and apply patch, a simplest solution for simplest bug. Could anyone review, test, and apply it? https://jira.reactos.org/browse/CORE-7969 Thanks ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] bootcd logfiles
You could try to use my dmesg command for KDBG in DEBUG mode of ROS LiveCD/BootCD: It allows to read,browse the log while nothing works and nothing is available, except the kernel. It works only in DEBUG build of ROS HTH, -M.A. On Thu, Dec 27, 2012 at 6:31 PM, Bernd Blaauw wrote: > Op 26-12-2012 20:07, Bernd Blaauw schreef: > >> Is there any documentation available for where ReactOS stores its >> logfiles? For a phase 2/3 installation to harddisk, obviously it gets >> stores on drive C: somewhere. For phase 1, screen and debugport >> (com/rs232) seem to be the only options. Same goes for the BootCD and >> LiveCD. > > > Nevermind, got ReactOS LiveCD working on real HW by the following: > 1) remove all USB devices (keyb, mouse, drive storage, optical storage) > 2) disable legacy availability of USB devices in BIOS. > > Keyboard is on PS/2, mouse can be attached and works once desktop is > visible. > > Bochs doc: http://bochs.sourceforge.net/doc/docbook/user/bochsrc.html > (section 4.2.30..32) shows the USB config part. > > QEMU doc: http://www.kraxel.org/cgit/qemu/tree/docs/usb2.txt > > I'll try to make myself usefull by experimenting with ROS in above emulators > with USB on, see if I can get logs exposing same issues as real HW. > > Bernd > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 57141: [FREELDR] Improve readability of sector calculation
Hi,
Sector size of disks starting with very old diskettes are 512 byte
until now. Exceptions have arisen nearly recently (2010) when some HDD
manufacturers (I know about WD) introduced hard drives with 4096 byte
physical sectors. But the change has made only on internals of HD
drive, logically no changes required to programs to work, although
working with ordinary "small" 512 sectors aligned on these "big"
sector boundaries makes the disk work much faster. HDD manufacturers
provide special utilities for aligning the partition start sectors, by
moving these partitions to nearest boundary
More details are here: http://en.wikipedia.org/wiki/Advanced_Format
The summary is that practically, treating size sectors as 512 bytes
will work yet for very long time, and for near future it would be
enough to align partitions.
That said, in long run, naturally, it would be better to encounter
real sectors' size.
Regards,
M.A.
On Thu, Aug 23, 2012 at 9:48 PM, Timo Kreuzer wrote:
> Btw, we are using a lot of hardcoded 512 values here for sector size even
> though there is a field in the Volume structure for that.
> Is that correct?
>
>
> Am 23.08.2012 14:02, schrieb tkreu...@svn.reactos.org:
>
>> Author: tkreuzer
>> Date: Thu Aug 23 12:02:30 2012
>> New Revision: 57141
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=57141&view=rev
>> Log:
>> [FREELDR]
>> Improve readability of sector calculation
>>
>> Modified:
>> trunk/reactos/boot/freeldr/freeldr/fs/fat.c
>>
>> Modified: trunk/reactos/boot/freeldr/freeldr/fs/fat.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fat.c?rev=57141&r1=57140&r2=57141&view=diff
>>
>> ==
>> --- trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] (original)
>> +++ trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] Thu Aug 23
>> 12:02:30 2012
>> @@ -1338,8 +1338,7 @@
>> //
>> // Seek to right position
>> //
>> - Position.HighPart = SectorNumber >> 23;
>> - Position.LowPart = SectorNumber << 9;
>> + Position.QuadPart = (ULONGLONG)SectorNumber * 512;
>> ret = ArcSeek(Volume->DeviceId, &Position, SeekAbsolute);
>> if (ret != ESUCCESS)
>> {
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 54136: [CMD] * Reduce the scope of some variables.
Because The Rule of:
Program Code Should be _Locally_Understandable_.
And this PoV changes a lot of things.
What does produce Software Engineer (AKA computer programmer)? Does he
produce software code?
No. He only do achieve high level of *understanding* of preexisting
code or newly generated idea, and from this position forth now
produces new implementations and/or *new levels of understanding*,
written occasionally as program code.
Since followers always doomed to read the code to get required level
of understanding, making code more readable is good.
Regarding to standards, I don't believe ROS coding style guide forbids
such kinds of code as being more understandable.
This is not inherent to ROS standard.
WBR,
M.A.
On Sat, Oct 15, 2011 at 1:54 AM, Alex Ionescu wrote:
> Why?
> It doesn't change anything...and...
>
> This is not our coding standard.
> Best regards,
> Alex Ionescu
>
>
> On Fri, Oct 14, 2011 at 1:50 PM, wrote:
>>
>> Author: akhaldi
>> Date: Fri Oct 14 17:50:16 2011
>> New Revision: 54136
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=54136&view=rev
>> Log:
>> [CMD]
>> * Reduce the scope of some variables.
>>
>> Modified:
>> trunk/reactos/base/shell/cmd/assoc.c
>> trunk/reactos/base/shell/cmd/dir.c
>> trunk/reactos/base/shell/cmd/filecomp.c
>> trunk/reactos/base/shell/cmd/start.c
>> trunk/reactos/base/shell/cmd/ver.c
>>
>> Modified: trunk/reactos/base/shell/cmd/assoc.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/assoc.c?rev=54136&r1=54135&r2=54136&view=diff
>>
>> ==
>> --- trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] (original)
>> +++ trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] Fri Oct 14 17:50:16
>> 2011
>> @@ -206,8 +206,6 @@
>> INT CommandAssoc (LPTSTR param)
>> {
>>
>> - LPTSTR lpEqualSign = NULL;
>> -
>> /* print help */
>> if (!_tcsncmp (param, _T("/?"), 2))
>> {
>> @@ -221,7 +219,7 @@
>> PrintAllAssociations();
>> else
>> {
>> - lpEqualSign = _tcschr(param, _T('='));
>> + LPTSTR lpEqualSign = _tcschr(param, _T('='));
>> if(lpEqualSign != NULL)
>> {
>> LPTSTR fileType = lpEqualSign + 1;
>>
>> Modified: trunk/reactos/base/shell/cmd/dir.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/dir.c?rev=54136&r1=54135&r2=54136&view=diff
>>
>> ==
>> --- trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] (original)
>> +++ trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] Fri Oct 14 17:50:16
>> 2011
>> @@ -1260,13 +1260,11 @@
>> LPDIRSWITCHFLAGS lpFlags) /* [IN] The flags that
>> we will use to sort */
>> {
>> LPWIN32_FIND_DATA lpTemp; /* A temporary pointer */
>> - int First, Last, Temp;
>> BOOL Way;
>>
>> if (i < j)
>> {
>> - First = i;
>> - Last = j;
>> + int First = i, Last = j, Temp;
>> Way = TRUE;
>> while (i != j)
>> {
>>
>> Modified: trunk/reactos/base/shell/cmd/filecomp.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/filecomp.c?rev=54136&r1=54135&r2=54136&view=diff
>>
>> ==
>> --- trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] (original)
>> +++ trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] Fri Oct 14
>> 17:50:16 2011
>> @@ -209,7 +209,6 @@
>> TCHAR path[MAX_PATH];
>> TCHAR fname[MAX_PATH];
>> TCHAR directory[MAX_PATH];
>> - UINT longestfname = 0;
>> SHORT screenwidth;
>>
>> /* expand current file name */
>> @@ -277,6 +276,7 @@
>> hFile = FindFirstFile (path, &file);
>> if (hFile != INVALID_HANDLE_VALUE)
>> {
>> + UINT longestfname = 0;
>> /* Get the size of longest filename first. */
>> do
>> {
>>
>> Modified: trunk/reactos/base/shell/cmd/start.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/start.c?rev=54136&r1=54135&r2=54136&view=diff
>>
>> ==
>> --- trunk/reactos/base/shell/cmd/start.c [iso-8859-1] (original)
>> +++ trunk/reactos/base/shell/cmd/start.c [iso-8859-1] Fri Oct 14 17:50:16
>> 2011
>> @@ -48,7 +48,6 @@
>> TCHAR szFullCmdLine [CMDLINE_LENGTH];
>> PROCESS_INFORMATION prci;
>> STARTUPINFO stui;
>> - INT i = 0;
>> #ifdef UNICODE
>> DWORD dwCreationFlags = CREATE_NEW_CONSOLE |
>> CREATE_UNICODE_ENVIRONMENT;
>> #else
>> @@ -213,7 +212,7 @@
>> /* Parsing the command that gets called by start, and
Re: [ros-dev] freeldr.ini now is overwritten by newly generated (livecd)
So well, I found solution, just informing if somebody interested. The file to change to get freeldr.ini involved unchanged in LiveCD, is this one: \boot\bootdata\livecd.ini It won't be regenerated. Correspondingly for BootCD probably will be this one: \boot\bootdata\bootcd.ini Sometimes I thing this kind of info should go into somewhere in wiki Regards, M.A. On Wed, Oct 5, 2011 at 12:54 PM, Minas Abrahamyan wrote: > Hi all, > > Previously I used edited version of freeldr.ini to build livecd ISOs, > it is in \output-i386\livecd\ > > Now freeldr.ini is becoming overwritten in make process by newly > generated "standard" one, and it is overwriting my manually edited > version. > > So > 1) what is now the correct way is to have custom freeldr.ini in iso image? > > 2) For what are these new automagical erase-and-newly-generate scripts? > > Although I can now manually edit (in iso image) what has been done > earlier automatically, replace the file, but, at my PoV something goes > wrong. > > -- > Best Regards, > M.A. > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] freeldr.ini now is overwritten by newly generated (livecd)
Hi all, Previously I used edited version of freeldr.ini to build livecd ISOs, it is in \output-i386\livecd\ Now freeldr.ini is becoming overwritten in make process by newly generated "standard" one, and it is overwriting my manually edited version. So 1) what is now the correct way is to have custom freeldr.ini in iso image? 2) For what are these new automagical erase-and-newly-generate scripts? Although I can now manually edit (in iso image) what has been done earlier automatically, replace the file, but, at my PoV something goes wrong. -- Best Regards, M.A. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] trunk is broken Re: [ros-diffs] [tkreuzer] 53896: [FREELDR] - Move some disk related stuff that is unrelated to the registry data into a new file, hwdisk.c - Don't get the disk count fro
On Fri, Sep 30, 2011 at 3:47 PM, Timo Kreuzer wrote: > Am 30.09.2011 12:17, schrieb Minas Abrahamyan: >> >> Hi there, >> >> This patch is to blame (seems to, just this) or another... >> But trunk is broken: build stops with these messages: >> >> > You need to clean freeldr_arch and freeldr_base. > Or use cmake :) Initially I cleaned these directories, then cleaned all, by make clean. ...same result. Maybe all of you use cmake? :) BTW is switching to cmake already performed? Regards, Minas > > Regards, > Timo > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] trunk is broken Re: [ros-diffs] [tkreuzer] 53896: [FREELDR] - Move some disk related stuff that is unrelated to the registry data into a new file, hwdisk.c - Don't get the disk count from th
Hi there,
This patch is to blame (seems to, just this) or another...
But trunk is broken: build stops with these messages:
[COPY] output-i386\livecd\reactos\system32\ntoskrnl.exe
[CC] dll\win32\shell32\shellole.cpp
[RSP] obj-i386\dll\win32\shell32\shell32_objs.rsp
[LD] output-i386\dll\win32\shell32\shell32.dll
[PEFIXUP] output-i386\dll\win32\shell32\shell32.dll
[RSYM] output-i386\dll\win32\shell32\shell32.dll
[COPY] output-i386\livecd\reactos\system32\shell32.dll
[LD] output-i386\boot\freeldr\freeldr\freeldr.sys
obj-i386\boot\freeldr\freeldr\arch\i386\hardware_freeldr_arch.o: In
function `PcHwDetect':
D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:1710:
undefined reference to `HwInitializeBiosDisks'
D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:606:
undefined reference to `PcBiosDiskCount'
D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:694:
undefined reference to `GetHarddiskIdentifier'
D:/ProgBin/ros/reactos/boot/freeldr/freeldr/arch/i386/hardware.c:685:
undefined reference to `PcBiosDiskCount'
make.exe: *** [output-i386\boot\freeldr\freeldr\freeldr.sys] Error 1
Total Build Time: 00:01:07
D:\ProgBin\ros\reactos>
Best regards,
M.A.
On Fri, Sep 30, 2011 at 2:12 AM, wrote:
> Author: tkreuzer
> Date: Thu Sep 29 21:12:40 2011
> New Revision: 53896
>
> URL: http://svn.reactos.org/svn/reactos?rev=53896&view=rev
> Log:
> [FREELDR]
> - Move some disk related stuff that is unrelated to the registry data into a
> new file, hwdisk.c
> - Don't get the disk count from the size value of a structure that was
> previously calculated from the disk count, but instead save it in a global
> variable.
> - Initialize certain data in a better place
>
> Added:
> trunk/reactos/boot/freeldr/freeldr/arch/i386/hwdisk.c (with props)
> Modified:
> trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
> trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
> trunk/reactos/boot/freeldr/freeldr/debug.c
> trunk/reactos/boot/freeldr/freeldr/freeldr_arch.rbuild
> trunk/reactos/boot/freeldr/freeldr/inifile/ini_init.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt?rev=53896&r1=53895&r2=53896&view=diff
> ==
> --- trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt [iso-8859-1] Thu Sep 29
> 21:12:40 2011
> @@ -83,6 +83,7 @@
> arch/i386/hardware.c
> arch/i386/hwacpi.c
> arch/i386/hwapm.c
> + arch/i386/hwdisk.c
> arch/i386/hwpci.c
> arch/i386/i386bug.c
> arch/i386/i386disk.c
>
> Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c?rev=53896&r1=53895&r2=53896&view=diff
> ==
> --- trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c [iso-8859-1]
> (original)
> +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c [iso-8859-1] Thu
> Sep 29 21:12:40 2011
> @@ -82,12 +82,16 @@
>
> DBG_DEFAULT_CHANNEL(HWDETECT);
>
> -static CHAR Hex[] = "0123456789abcdef";
> static unsigned int delay_count = 1;
>
> -extern ULONG reactos_disk_count;
> -extern ARC_DISK_SIGNATURE reactos_arc_disk_info[];
> -extern char reactos_arc_strings[32][256];
> +extern UCHAR PcBiosDiskCount;
> +
> +PCHAR
> +GetHarddiskIdentifier(
> + UCHAR DriveNumber);
> +
> +VOID
> +HwInitializeBiosDisks(VOID);
>
> /* FUNCTIONS
> /
>
> @@ -402,218 +406,6 @@
> return PartialResourceList;
> }
>
> -typedef struct tagDISKCONTEXT
> -{
> - UCHAR DriveNumber;
> - ULONG SectorSize;
> - ULONGLONG SectorOffset;
> - ULONGLONG SectorCount;
> - ULONGLONG SectorNumber;
> -} DISKCONTEXT;
> -
> -static LONG DiskClose(ULONG FileId)
> -{
> - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId);
> -
> - MmHeapFree(Context);
> - return ESUCCESS;
> -}
> -
> -static LONG DiskGetFileInformation(ULONG FileId, FILEINFORMATION*
> Information)
> -{
> - DISKCONTEXT* Context = FsGetDeviceSpecific(FileId);
> -
> - RtlZeroMemory(Information, sizeof(FILEINFORMATION));
> - Information->EndingAddress.QuadPart = (Context->SectorOffset +
> Context->SectorCount) * Context->SectorSize;
> - Information->CurrentAddress.QuadPart = (Context->SectorOffset +
> Context->SectorNumber) * Context->SectorSize;
> -
> - return ESUCCESS;
> -}
> -
> -static LONG DiskOpen(CHAR* Path, OPENMODE OpenMode, ULONG* FileId)
> -{
> - DISKCONTEXT* Context;
> - UCHAR DriveNumber;
> - ULONG DrivePartition, SectorSize;
> - ULONGLONG SectorOffset = 0;
> - ULONGLONG SectorCount = 0;
> - PARTITION_TABLE_E
[ros-dev] PVS-Studio analysis of ReactOS code: error explanations in English
Hi all, Andrey Karpov of "SiProVer" Ltd (www.viva64.com/ ), the authors of PVS-Studio, a statical source code analyzer/checker wrote (in Russian, this translation is conducted by me): "Have checked source code of ReactOS with PVS-Studio, I fulfilled three wishes of mine at once: Firstly, for a long time I wanted to write an article about ordinary project. It is not so interesting to check source code of such projects as Chromium, It is of too high quality and resources are spending for keeping this level of quality, resources which are unavailable to ordinary projects. Secondly, ReactOS appears to be a good example of project, for which high need of statical analysis of source code can be shown, especially as project being developed with distributed team of developers with diversely different experience. Thirdly, I got confirmation of PVS-Studio getting better and better and more useful all along the way..." Full text of original Russian article is here: http://habrahabr.ru/blogs/os/127493/ titled on Russian as "PVS-Studio: analysing ReactOS operating system source code". Evgeniy Ryzhkov of "SiProVer" adds: "Soon we will translate and publish article on English. But if you have questions now - we are ready for discussion. If some of English-speaking comrades of ReactOS would like to work with errors list, generated with PVS-Studio we have prepared for them translation of errors explanations, here it is: http://www.viva64.com/external-pictures/txt/PVS-Studio-vs-ReactOS-en-unicode.txt ". Original article refers to long list of generated errors with manually added explanations for errors found by their static checker, so this is translated version of that list. --- Looking backward to few applied patches, it turns out that not all of them were absolutely useful, some patches were reversed, etc. But nevertheless, I think it makes sense to use this tool. They promised to donate some version of PVS-Studio to project, and it is to ROS developers to decide is it worth of taking. What I would suggest: anybody working with some module or part of code can take corresponding part of messages (or in future, possibly check with tool only these parts of interest) and work with them. Also Karpov gave good advise to check newly written code, since it is still of interest to developer: write and time for time test with it. P.S. Disclaimer: I am not in any connection with "SiProVer" Regards, M.A. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] dmesg of #6018 Re: [ros-diffs] [rharabien] 52409: [BOOTVID] - Revert part of r52239: Fix support for \r and do not handle backspace - Simplify it a bit [NTOSKRNL] - Add backspace support to
Dear Rafal,
Since you are touching the code of /ntoskrnl/kd/kdio.c, wouldn't you
be kind enough to
review and possibly apply my "dmesg command patch"?
Issue in bugzilla: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018
patch itself: http://www.reactos.org/bugzilla/attachment.cgi?id=6055
It contains much of code of KdbpPrint() function, in function KdbpPager(), etc.
The is explanations about it in issue description.
***
To all: This patch is suspended in bugzilla from March, although I
noticed some weak attempts to do something with it,
say reassign to somebody, but yet without any advance.
Hope something will be changed with this.
Thanks for attention
-Minas Abrahamyan
On Wed, Jun 22, 2011 at 12:47 AM, wrote:
> Author: rharabien
> Date: Tue Jun 21 19:47:13 2011
> New Revision: 52409
>
> URL: http://svn.reactos.org/svn/reactos?rev=52409&view=rev
> Log:
> [BOOTVID]
> - Revert part of r52239: Fix support for \r and do not handle backspace
> - Simplify it a bit
>
> [NTOSKRNL]
> - Add backspace support to KdpScreenPrint
> - Do not draw boot text bitmap if InbvDisplayString is called with "" or "."
> (matches NT behavior)
>
> Modified:
> trunk/reactos/drivers/base/bootvid/i386/vga.c
> trunk/reactos/ntoskrnl/inbv/inbv.c
> trunk/reactos/ntoskrnl/kd/kdio.c
>
> Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/vga.c?rev=52409&r1=52408&r2=52409&view=diff
> ==
> --- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Tue Jun 21
> 19:47:13 2011
> @@ -66,6 +66,7 @@
> ULONG TextColor = 0xF;
> ULONG curr_x = 0;
> ULONG curr_y = 0;
> +BOOLEAN CarriageReturn = FALSE;
> ULONG_PTR VgaRegisterBase = 0;
> ULONG_PTR VgaBase = 0;
>
> @@ -279,14 +280,8 @@
> NTAPI
> VgaScroll(ULONG Scroll)
> {
> - ULONG Top;
> - ULONG SourceOffset, DestOffset;
> - ULONG Offset;
> - ULONG i, j;
> -
> - /* Set memory positions of the scroll */
> - SourceOffset = VgaBase + (ScrollRegion[1] * 80) + (ScrollRegion[0] >> 3);
> - DestOffset = SourceOffset + (Scroll * 80);
> + ULONG Top, RowSize, i;
> + PUCHAR OldPosition, NewPosition;
>
> /* Clear the 4 planes */
> __outpw(0x3C4, 0xF02);
> @@ -296,56 +291,27 @@
>
> /* Set Mode 1 */
> ReadWriteMode(1);
> -
> - /* Save top and check if it's above the bottom */
> - Top = ScrollRegion[1];
> - if (Top > ScrollRegion[3]) return;
> +
> + RowSize = (ScrollRegion[2] - ScrollRegion[0] + 1) / 8;
>
> /* Start loop */
> - do
> - {
> - /* Set number of bytes to loop and start offset */
> - Offset = ScrollRegion[0] >> 3;
> - j = SourceOffset;
> -
> - /* Check if this is part of the scroll region */
> - if (Offset <= (ScrollRegion[2] >> 3))
> - {
> - /* Update position */
> - i = DestOffset - SourceOffset;
> -
> - /* Loop the X axis */
> - do
> - {
> - /* Write value in the new position so that we can do the
> scroll */
> - WRITE_REGISTER_UCHAR(UlongToPtr(j),
> - READ_REGISTER_UCHAR(UlongToPtr(j + i)));
> -
> - /* Move to the next memory location to write to */
> - j++;
> -
> - /* Move to the next byte in the region */
> - Offset++;
> -
> - /* Make sure we don't go past the scroll region */
> - } while (Offset <= (ScrollRegion[2] >> 3));
> - }
> -
> - /* Move to the next line */
> - SourceOffset += 80;
> - DestOffset += 80;
> -
> - /* Increase top */
> - Top++;
> -
> - /* Make sure we don't go past the scroll region */
> - } while (Top <= ScrollRegion[3]);
> + for(Top = ScrollRegion[1]; Top <= ScrollRegion[3]; ++Top)
> + {
> + /* Calculate the position in memory for the row */
> + OldPosition = (PUCHAR)VgaBase + (Top + Scroll) * 80 +
> ScrollRegion[0] / 8;
> + NewPosition = (PUCHAR)VgaBase + Top * 80 + ScrollRegion[0] / 8;
> +
> + /* Scroll the row */
> + for(i = 0; i < RowSize; ++i)
> + WRITE_REGISTER_UCHAR(NewPosition + i,
> READ_REGISTER_UCHAR(OldPosition + i));
> + }
> }
>
> VOID
> NTAPI
> PreserveRow(IN ULONG CurrentTop,
> - IN ULONG To
Re: [ros-dev] Could opensource GPL USB driver for NT4 be help for implementing USB in ReactOS?
I'm not against full USB stack, but if it could work for block
devices, it would be great, especially for debugging on standalone
machines.
And what I've read about was just about them: "Supports USB Storage
devices only (e.g. Flash, HDD)"
from here (Alter's site): http://alter.org.ua/en/docs/win/nt4_usb/
So now after adoption it supports sometimes keyboards and mice, but
doesn't support storage devices? what a metamorphose :)
On Sat, Apr 16, 2011 at 3:31 AM, Zachary Gorden
wrote:
> USB keyboards and mice can work if you're lucky, but that driver does not
> implement the entire USB standard. Therefore for anything more complicated
> we need a genuine USB stack, not just a driver.
>
> On Fri, Apr 15, 2011 at 5:18 PM, Minas Abrahamyan
> wrote:
>>
>> But I've read that this one was working on NT4, does it here in ROS
>> assimilated and adopted such way it here works too?
>> Am I missing something and we have working USB driver?
>>
>> Regards,
>> M.A.
>>
>> On Fri, Apr 15, 2011 at 6:21 AM, James Tabor
>> wrote:
>> > Don't worry, we have assimilated it years ago!
>> >
>> >
>> > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/nt4compat/usbdriver/
>> >
>> > On Thu, Apr 14, 2011 at 6:44 PM, Minas Abrahamyan
>> > wrote:
>> >> Hi all,
>> >>
>> >> The subj.
>> >>
>> >> I'm talking about Woodhead's GPL USB driver:
>> >> * Original page (and site) is dead ("Woodhead--NT4--USB"
>> >> http://www.geocities.com/mypublic99/index.html )
>> >>
>> >> * But files are backed up, for example, here:
>> >> [ftp://piekraste.daba.lv/pub/Service_Pack/NT_4/NT4_USB/HS/]
>> >> (or look into internet wayback machine)
>> >>
>> >> Regards,
>> >> M.A.
>> >>
>> >
>> > ___
>> > Ros-dev mailing list
>> > Ros-dev@reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Could opensource GPL USB driver for NT4 be help for implementing USB in ReactOS?
But I've read that this one was working on NT4, does it here in ROS
assimilated and adopted such way it here works too?
Am I missing something and we have working USB driver?
Regards,
M.A.
On Fri, Apr 15, 2011 at 6:21 AM, James Tabor wrote:
> Don't worry, we have assimilated it years ago!
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/nt4compat/usbdriver/
>
> On Thu, Apr 14, 2011 at 6:44 PM, Minas Abrahamyan
> wrote:
>> Hi all,
>>
>> The subj.
>>
>> I'm talking about Woodhead's GPL USB driver:
>> * Original page (and site) is dead ("Woodhead--NT4--USB"
>> http://www.geocities.com/mypublic99/index.html )
>>
>> * But files are backed up, for example, here:
>> [ftp://piekraste.daba.lv/pub/Service_Pack/NT_4/NT4_USB/HS/]
>> (or look into internet wayback machine)
>>
>> Regards,
>> M.A.
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
To All: What is needed is reverse thing for DebugService ( as described here: http://alter.org.ua/docs/nt_kernel/kdprint/) : KdpTrap is called to print (store?) debug message somewhere, what is needed, is something that will extract back stored messages. dmesg patch successfully stores debug messages in buffer, some kernel code should give them back. Roughly speaking needed the piece of DeviceIOControl that copies memory from kernel mode to back to user mode. Any help is welcomed! *** Returning to discussion with dmex: What I'm speaking is totally different. > it can write to the bootlog file and ETW for the Event Log. > user-mode tools like Winbdg, dbgview, Event Viewer, notepad. All these things require stable working user-mode code, perfectly booted up kernel, etc. To get there is is needed to debug the kernel. If you haven't serial cable, or have, but your machine hasn't COM-port, as in my case, then you have no other choice to use my dmesg command in kdbg - ROS kernel debugger. After corrections your machine is booted up. Now you'd just want to look on these debug messages stored in DmesgBuffer: to review it, to review found bugs, quirks, at last to mail it somewhere, say into bugzilla. Or compare working installation with not working one - the effective way! This trick has helped me many times. After that it could use whatever whistles you want: Winbdg, dbgview, Event Viewer, notepad, notepad++, notepad+=10 etc. But! At start, working system is needed. It could even have 'OutputDebugString' interface. I didn't ever say this should be the only one implementation. I just want tools to help booting up the ROS. not more. _but not less_. But you are looking only of perspective of fully functional Windows. That is not the case with ROS. > DebugPrint uses OutputDebugString. No, no! just the opposite, look at calls hierarchy tables at http://alter.org.ua/docs/nt_kernel/kdprint/ OutputDebugString is user-mode code. If you have user-mode perfectly working - you use dbgviews and you need nothing more. All is working already at that moment. *** Best regards, M.A. On Tue, Apr 12, 2011 at 9:49 PM, dmex wrote: >>Please point me the same thing. Two or three implementations. > > Windows uses the screen, COM1, DBWIN_BUFFER, WMI and ETW to write trace > output during/after boot to various locations. Starting with Windows Vista, > WMI creates an active trace channel during the boot process which is allot > more effective than dmesg so I would look at evntrace.h. Only errors are > logged. Windows later writes to COM1 once the driver loads, WMI is > implemented in the kernel and (should be loaded) very early into the boot > process. > > At points before these services are available (I.E. NTLDR) Windows writes > output to the console or does a KeBugCheck, then later to WMI/ETW, COM1, > then DBWIN_BUFFER in that order. I would prefer output to the screen as much > as possible until these services are up and it can write to the bootlog file > and ETW for the Event Log. > >>What compartability did you mean? > > How do you propose someone obtain these messages during and after boot > without writing new tools? Since the goal of ROS is more or less > compatibility, not all devs coming from Windows would expect something like > that to be holding trace/debug output. I can use windbg, dbgview, event > viewer and ETW log files to view this stuff on Windows so why implement > something else completely different for ROS? The goal should be increased > compatibility with Windows, not less. > >>Any bugs, errors occurred during that process of printing into that > MappedView associated with "DBWIN_BUFFER" FileMapping are reported to kernel > with DbgPrint. >>Where should these errors be stored? > > DebugPrint uses OutputDebugString. > >>Linux in past has such shared memory object, but practically, now, it is > overridden by the system call. >>So my question remains >> Subject: Advice required on User-mode to Kernel mode call for >> syslog(2) analog in ROS > > From user-mode to kernel, My advice would be anything that lets me use > existing user-mode tools like Winbdg, dbgview, Event Viewer, notepad. > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Could opensource GPL USB driver for NT4 be help for implementing USB in ReactOS?
Hi all,
The subj.
I'm talking about Woodhead's GPL USB driver:
* Original page (and site) is dead ("Woodhead--NT4--USB"
http://www.geocities.com/mypublic99/index.html )
* But files are backed up, for example, here:
[ftp://piekraste.daba.lv/pub/Service_Pack/NT_4/NT4_USB/HS/]
(or look into internet wayback machine)
Regards,
M.A.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
On Thu, Apr 7, 2011 at 12:26 AM, dmex wrote: > What's wrong with current method of using the memory mapped 'DBWIN_BUFFER' > file for outputting kernel messages? Nothing wrong: it just doesn't exist. > Two or three different kernel implementations No any implementation to store kernel debug messages, the only one I know is the dmesg kernel patch I talked about (issue 6018) > for the same thing Please point me the same thing. Two or three implementations. > breaks compatibility with existing applications like Dbgview. What compartability did you mean? The *only* mention about "DBWIN_BUFFER" was in \dll\win32\kernel32\debug\output.c:266, the line: == hDBMonBuffer = OpenFileMappingW(SECTION_MAP_WRITE, FALSE, L"DBWIN_BUFFER"); == So, as far as I see, Opening FileMapping without Creating it first, could not work. -- But even that is not such important. Any bugs, errors occurred during that process of printing into that MappedView associated with "DBWIN_BUFFER" FileMapping are reported to kernel with DbgPrint. Where should these errors be stored? === Why specific service is needed. Well, here: [http://alter.org.ua/docs/nt_kernel/kdprint/ KdPrint/DbgPrint and OutputDebugString behavior] at Alter's site, and here: [http://www.codeproject.com/KB/winsdk/OutputDebugString.aspx?display=Print Mechanism of OutputDebugString - CodeProject] the ready code sample, they discuss internals and mechanism of OutputDebugString. So definitely Windows too uses system call to read data from kernel debug buffer. As unices do so too. And there is no other way. Linux in past has such shared memory object, but practically, now, it is overridden by the system call. So my question remains > Subject: Advice required on User-mode to Kernel mode call for > syslog(2) analog in ROS Regards, M.A. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
Hi all,
I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg
buffer (debug messages in kernel buffer),
which is filled in by appropriate patch 6018
(here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW,
it's not yet reviewed and not applied!).
So I'm requesting advice on:
What would be the better way for user-mode code to get the contents of
kmsg buffer in kernel-space (kdbg)?
Shortly:
Linux has special system call "syslog" (man 2 syslog)
FreeBSD uses its special sysctl interface to kernel along with
'kern.msgbuf' parameter.
My questions:
Do we need special system call like Linux, or even more, the whole
family of them (sysctl('*')) as in BSD?
How to implement simple system call for it, now?
---
Now detailed info for unices:
Linux case:
* syslog(2) - read and/or clear kernel message ring buffer; set console_loglevel
int syslog(int type, char *bufp, int len);
* also /proc/kmsg virtual file, which when being read returns buffer contents
==excerpt from man proc ==
/proc/kmsg
This file can be used instead of the syslog(2) system
call to read kernel messages. A
process must have superuser privileges to read this
file, and only one process should read
this file. This file should not be read if a syslog
process is running which uses the sys‐
log(2) system call facility to log kernel messages.
Information in this file is retrieved with the dmesg(1) program.
==eo exerpt==
dmesg in FreeBSD:
Parameter 'kern.msgbuf' given to sysctl(3) returns contents of kernel
message buffer.
There is also 'kern.msgbuf_clear' to clean the buffer.
---
WBR,
Minas Abrahamyan
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [NTDLL/LDR] - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.
Hi Alexey, > I have a rewrite of all these functions, which would fix this issue, So one may hope that this problem will be eventually solved? Sounds great! :) Then if bug 6031 ( http://www.reactos.org/bugzilla/show_bug.cgi?id=6031 ) would be solved, I will try, then together this will eliminate very the root of the strange evil bug! :) Best Regards, -M.A. On Wed, Mar 30, 2011 at 1:29 AM, Aleksey Bragin wrote: > Hi Minas, > thanks for watching these commits! > > I have a rewrite of all these functions, which would fix this issue, however > I can't commit it before I fix other code first. > > WBR, > Aleksey Bragin. > > On Mar 29, 2011, at 5:26 PM, Minas Abrahamyan wrote: > >> Hi Alexey, >> >> Since you are still working on these LdrXXX functions then you maybe >> find possibility >> to add there some code to prevent them trapping into infinite cycle (bug >> 5881: >> http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 ) >> >> While booted up with RAM 25 or 24 MB ROS kernel falls into infinite >> cycle there, >> but being booted up with 15 Mbs ROS stalls and and hangs up. >> >> To test it is enough to run it on any VM with 24Mb of RAM. >> >> What occurs there is infinite recursive calls, in form of >> LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule -> >> LdrpLoadModule and so forth. >> (detailed bt is in bug 5881 description). >> Maybe ROS kernel doesn't check memory availability, something like >> XXXMalloc returning NULL or so. >> >> Thanks! >> -M.A. >> >> On Wed, Mar 23, 2011 at 4:25 PM, wrote: >>> >>> Author: fireball >>> Date: Wed Mar 23 12:25:53 2011 >>> New Revision: 51123 >>> >>> URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev >>> Log: >>> [NTDLL/LDR] >>> - Fix a few bugs (wrong variable usage, wrong variable initialization) >>> which led to incorrect snapping of import address table. >>> - Wrap LdrpSnapThunk() invocations into SEH. >>> >>> Modified: >>> trunk/reactos/dll/ntdll/ldr/ldrpe.c >>> >>> Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c >>> URL: >>> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=51123&r1=51122&r2=51123&view=diff >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [NTDLL/LDR] - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.
Hi Alexey, Since you are still working on these LdrXXX functions then you maybe find possibility to add there some code to prevent them trapping into infinite cycle (bug 5881: http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 ) While booted up with RAM 25 or 24 MB ROS kernel falls into infinite cycle there, but being booted up with 15 Mbs ROS stalls and and hangs up. To test it is enough to run it on any VM with 24Mb of RAM. What occurs there is infinite recursive calls, in form of LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule -> LdrpLoadModule and so forth. (detailed bt is in bug 5881 description). Maybe ROS kernel doesn't check memory availability, something like XXXMalloc returning NULL or so. Thanks! -M.A. On Wed, Mar 23, 2011 at 4:25 PM, wrote: > Author: fireball > Date: Wed Mar 23 12:25:53 2011 > New Revision: 51123 > > URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev > Log: > [NTDLL/LDR] > - Fix a few bugs (wrong variable usage, wrong variable initialization) which > led to incorrect snapping of import address table. > - Wrap LdrpSnapThunk() invocations into SEH. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrpe.c > > Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=51123&r1=51122&r2=51123&view=diff ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [rharabien] 51108: Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly
> So the old version was correct (except for the misleading comment maybe)
At the same time, with /FIRSTCHANCE key enabled
do we need ROS to popup kdbg at every start?
It's so bothering...
just annoying
On Tue, Mar 22, 2011 at 4:58 AM, Timo Kreuzer wrote:
>
> Windows doesn't do any access checks in ProbeForRead, it only checks the
> range and alignment. The MmUserProbeAddress access is used to raise an
> exception with the appropriate parameters. So the old version was correct
> (except for the misleading comment maybe)
>
>
> Am 21.03.2011 15:43, schrieb rharab...@svn.reactos.org:
>>
>> Author: rharabien
>> Date: Mon Mar 21 14:43:56 2011
>> New Revision: 51108
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=51108&view=rev
>> Log:
>> Fix ProbeForRead. It wasn't ever checking if memory can be accessed.
>> Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is
>> now nearly the same as in ProbeForWrite. It shouldn't break anything. If it
>> does, it's not bug in this code. :)
>>
>> Modified:
>> trunk/reactos/ntoskrnl/ex/exintrin.c
>>
>> Modified: trunk/reactos/ntoskrnl/ex/exintrin.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev=51108&r1=51107&r2=51108&view=diff
>>
>> ==
>> --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Mon Mar 21 14:43:56
>> 2011
>> @@ -103,6 +103,8 @@
>> IN SIZE_T Length,
>> IN ULONG Alignment)
>> {
>> + ULONG_PTR Last, Current = (ULONG_PTR)Address;
>> + CHAR Temp;
>> PAGED_CODE();
>>
>> /* Only probe if we have a valid length */
>> @@ -115,18 +117,31 @@
>> (Alignment == 8) ||
>> (Alignment == 16));
>>
>> - /* Check for correct alignment */
>> - if (((ULONG_PTR)Address& (Alignment - 1)) != 0)
>> + /* Check the alignment */
>> + if ((Current& (Alignment - 1)) != 0)
>> {
>> /* Incorrect alignment */
>> ExRaiseDatatypeMisalignment();
>> }
>> - else if (((ULONG_PTR)Address + Length)< (ULONG_PTR)Address ||
>> - ((ULONG_PTR)Address + Length)>
>> (ULONG_PTR)MmUserProbeAddress)
>> +
>> + /* Get the end address */
>> + Last = Current + Length - 1;
>> + if ((Last< Current) || (Last>= (ULONG_PTR)MmUserProbeAddress))
>> + {
>> + /* Raise an access violation */
>> + ExRaiseAccessViolation();
>> + }
>> +
>> + /* Round down to the last page */
>> + Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE;
>> + do
>> {
>> /* Attempt a read */
>> - *(volatile CHAR* const)MmUserProbeAddress = 0;
>> - }
>> + Temp = *(volatile CHAR*)Current;
>> +
>> + /* Go to the next address */
>> + Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE;
>> + } while (Current != Last);
>> }
>> }
>>
>>
>>
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
