- Ros-dev - ReactOS.org

by Colin Finck

Hi all! As the first flight to the Hackfest has been booked today, I have clarified the dates on https://reactos.org/wiki/ReactOS_Hackfest_2017 I will book the loft also for the night from Sunday to Monday (August 13 to 14), so you have the option to arrive earlier and the Hackfest can definitely begin on Monday. Please check your travelling options to see whether Sunday or Monday is the better option for you, and update https://reactos.org/wiki/ReactOS_Hackfest_2017/Lists Cheers, Colin

7 years, 10 months

1
0
0 0

AHK Bot down for the week end

by Sylvain Petreolle

Due to my family presence, I need to stop the Test KVM AHK bot during this week end."I'll be back." Kind regards, Sylvain Petreolle

7 years, 10 months

1
0
0 0

Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup

by Giannis Adamopoulos

I'd say that we should show: - Run or install ReactOS - Boot from hard disk - Advanced options Nothing more should be needed and the first option should be clear that can either lead to a live environment or a setup. David Quintana (gigaherz) <gigaherz(a)gmail.com> wrote on Tue, July 4th, 2017, 10:45 PM: > I feel like the boot menu is going to be far too busy for the end user. I'd > go with something closer to > > blah blah: > > - Install Now > - Try without installing > - Show advanced options... > > where: > > - Install now -- boots into the graphical installer (no desktop unless > you cancel or something) > - Try without installing -- boots into livecd desktop (backed by RAM, I > guess) > - Show advanced options... -- opens a second-level menu with > - Text-mode installer > - Live boot without Ramdisk > - etc. > > > > On 4 July 2017 at 21:45, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote: > > > Hello everyone, > > > > > > > > One of the long-term plan for ReactOS was to have a graphical user-mode > > interface for the 1st-stage setup, similar to e.g. what may be found in > > newer versions of Windows (Vista+), as an alternative to our current 1st-stage > > setup in text-mode > > > > (note that I say “alternative”, not “replacement”, because both of them > > can live together without fundamental changes to either ReactOS or our ISO > > images, both of them can share core functionality, and finally because some > > people may prefer the text-mode either for unattended installations or for > > low-memory conditions). > > > > > > > > You can find some information about the 1st-stage GUI setup here: > > https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it > > can be found in base/setup/reactos/ . Currently only most of the screens > > have been implemented, while the core functionality is not present. However > > this functionality can somehow be taken by reusing the source code of > > USETUP (see my branch https://svn.reactos.org/svn/reactos/branches/setup_ > > improvements/base/setup/ ). > > > > > > > > > > > > Abstract (aka. TL;DR): I explain below the needed changes introduced > > experimentally in the “setup-improvements” branch, revision 75273, to > > generate an all-in-one ReactOS bootcd, that includes both the 1st-stage > > text-mode setup + 1st-stage GUI setup alternative + live-demo > > functionality. This is meant to replace our currently separated “bootcd” / > > “livecd” ISOs, where the latter currently do not offer the possibility to > > install ReactOS. Some currently known potential problems are evoked. > > > > > > > > Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; > > Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png . > > > > > > > > > > > > Having a 1st-stage GUI setup also means that it’ll also use the > > already-existing functionality that we offer in our “Live-CD” ISOs. > > Currently, the “Live-CD” ISOs we provide only allow for demonstration > > purposes, while the ReactOS installation proper is found in our so-called > > “Boot-CD” ISOs (which currently only contain text-mode setup). Thus, the 1 > > st-stage GUI setup, as an alternative to the 1st-stage setup in > > text-mode, means that both ISOs can be merged all in one, and we won’t have > > to make a distinction between both: they will be able to offer both the 1 > > st-stage in text mode AND a graphical mode (à la “Live-CD”) where it is > > possible to choose whether to test ReactOS in demo mode, or to install it > > via the GUI setup. > > > > Such an all-in-one ISO capability was already present in the trunk under > > the name “hybridcd”, but was used only when we built ISO images for the > > public events where ReactOS participated (FOSDEM, CLT, …). But now, having > > the setup process both in text mode and in graphics mode, in addition to > > the Live-CD demonstration capability, really suggests just using the > > all-in-one ISO and stop doing the “Boot-CD” (aka. only setup) vs. “Live-CD” > > (aka. only demo) separation. We would just generate only one type of ISO > > that contains everything. > > > > > > > > With that in mind, I have committed in my branch “setup_improvements”, in > > revision 75273 : https://svn.reactos.org/svn/reactos?view=revision& > > revision=75273 such changes to be able to only build an ISO that contains > > everything. These changes are minimal, in the sense that I haven’t > > purposelessly changed the names of the build targets just to be fancy. Such > > changes may be done later, but not now. > > > > > > > > The needed changes are the following: First, the build target that will > > generate the all-in-one CD is called “bootcd”, because this also was the > > main build target for ISOs before the change. Second, I completely remove > > the “hybridcd” build target, because its functionality are now absorbed by > > “bootcd”. Third, the build target “livecd” is reduced to its strict > > minimum. For the sake of building a RAMDISK boot drive (see comments > > after), I continue to generate an ISO for “livecd”. But I’ve changed the > > generated name to “liveimage.iso”, to emphasize the point that it has to be > > understood as a (virtual) disk image for RAMDISK purposes, not just as a > > ISO image. Note that I haven’t renamed the build target “livecd” to, say, > > “liveimage” to reduce my commit changes (such a renaming may be done > > later). The “livecd” target builds a list of files that need to be present > > in the image. The generated liveimage.iso is no-more a bootable ISO, I’ve > > removed inclusion of freeloader + El-Torito boot-sector + the > > USB-ISO-Hybrid functionality for it. > > > > The “bootcd” target has been slightly changed in order to include the > > liveimage.iso as a file (for RAMDISK), and to also add the contents of this > > image in a flattened tree within the bootcd iso: the two directories > > “Profiles” and “reactos”. > > > > The 1st-stage text-mode setup is kept, as said before, but its > > corresponding files + the installation CAB source + the 1st-stage GUI > > setup application proper goes into a (renamed) directory called “i386”, > > corresponding to installation files for an i386 installation (technically, > > 1 per architecture when we’ll have a ReactOS ported to other archs). These > > files cannot be present in the same “reactos” directory as the ones from > > the flattened LiveImage, because some of the files are different (smss.exe, > > registry, etc…) Our FreeLdr knows from where to boot the 1st-stage > > text-mode (from i386), as well as the Live-demo in graphics mode (from > > reactos). > > > > I need to adjust the code of few setup components for them to stop relying > > on hardcoded “reactos/” path, and instead use a more “dynamic” (determined > > at runtime) path. > > > > > > > > NOTE FOR DEVS/SYSADMINS: The “bootcdregtest” build target, generating the > > special ISO that is fed to our test bots, remains exactly the same, and the > > files contained in the generated ISO have not changed. > > > > > > > > NOTE about the RAMDISK feature: I enabled it so that a user can remove the > > demo media (CD, …) and reuse the drive for other purposes, while still > > being able to use ReactOS. Of course this requires a large amount of RAM > > available. And that’s also why I include the flattened liveimage files so > > that one can use the demo without the RAMDISK (when few memory is > > available). > > > > As is currently implemented, this makes the ReactOS all-in-one bootcd > > large (it gains a good 100 MB) due to duplicated space (the flattened > > files, plus the same inside “liveimage.iso”). I cannot do better (unless > > ditching either the RAMDISK, or keeping it but not include the flattened > > files) because ReactOS currently doesn’t have a way to boot from disk > > images **that are not meant to be a RAMDISK**. The day when this > > difficulty is removed, a single disk image could be used either as the > > RAMDISK or the (non-removable) installation. > > > > A second remark is that I don’t plan to have the 1st-stage GUI setup > > available when booting ReactOS in RAMDISK mode because, as a consequence of > > its current implementation, I would otherwise need to duplicate the > > installation CAB source in the RAMDISK image too, making it again larger. > > > > > > > > NOTE about the FreeLdr Boot Menu: Since ReactOS is not that stable > > currently, we like to boot it in debug mode, and redirect the output to a > > serial port (usually COM1). However some people don’t have serial ports on > > real hardware, so we propose to boot with debug output redirected to > > screen. However this may slow ReactOS down, so we also like to boot ReactOS > > with debug mode disabled. That’s why I proposed the declination of these > > boot modes for each ReactOS installation contained in the BootCD > > (Live+Setup, with or without RAMDISK, and with debug enabled or not). The > > problem is that it clutters a lot the boot menu. A remedy would be to > > implement in FreeLdr the functionality of editing **existing** boot > > entries to change their associated boot options, so that one could add by > > hand the options to enable (or disable) debugging. This is currently > > unimplemented. The only implemented feature is to set up a new boot entry > > on the fly to boot ReactOS afterwards. > > > > > > > > NOTE for regress-testers: Possible remark that I may hear: “I only care > > about installing ReactOS (perhaps just in unattended mode) and I don’t care > > at all about the GUI setup nor about the Live-demo thingie, and your new > > BootCD is too large. I want to be able to download & use the good-old > > bootcd for regress-testing.” . So what to do? Since we currently build and > > store the “bootcdregtest” ISOs, but are not publicly available through our > > www.reactos.org/getbuilds interface, I would suggest here to make them > > available to people, so that those who want to quickly DL and/or > > install/regress-test ReactOS could use these ISOs instead (which are really > > just the good old BootCDs, but with unattended installation enabled **and** > > with our test-suite included). They are not that much large, just a bit > > more than the old regular bootcd. > > > > > > > > Please let me know whether you have other remarks/comments/questions/suggestions/etc… > > to make the new BootCDs better. > > > > > > > > > > > > Best, > > > > > > > > Hermès > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > >

7 years, 10 months

5
4
0 0

About the bootcd and livecd, and the 1st-stage GUI setup

by Hermès BÉLUSCA-MAÏTO

Hello everyone, One of the long-term plan for ReactOS was to have a graphical user-mode interface for the 1st-stage setup, similar to e.g. what may be found in newer versions of Windows (Vista+), as an alternative to our current 1st-stage setup in text-mode (note that I say alternative, not replacement, because both of them can live together without fundamental changes to either ReactOS or our ISO images, both of them can share core functionality, and finally because some people may prefer the text-mode either for unattended installations or for low-memory conditions). You can find some information about the 1st-stage GUI setup here: https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it can be found in base/setup/reactos/ . Currently only most of the screens have been implemented, while the core functionality is not present. However this functionality can somehow be taken by reusing the source code of USETUP (see my branch https://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/ ). Abstract (aka. TL;DR): I explain below the needed changes introduced experimentally in the setup-improvements branch, revision 75273, to generate an all-in-one ReactOS bootcd, that includes both the 1st-stage text-mode setup + 1st-stage GUI setup alternative + live-demo functionality. This is meant to replace our currently separated bootcd / livecd ISOs, where the latter currently do not offer the possibility to install ReactOS. Some currently known potential problems are evoked. Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png . Having a 1st-stage GUI setup also means that itll also use the already-existing functionality that we offer in our Live-CD ISOs. Currently, the Live-CD ISOs we provide only allow for demonstration purposes, while the ReactOS installation proper is found in our so-called Boot-CD ISOs (which currently only contain text-mode setup). Thus, the 1st-stage GUI setup, as an alternative to the 1st-stage setup in text-mode, means that both ISOs can be merged all in one, and we wont have to make a distinction between both: they will be able to offer both the 1st-stage in text mode AND a graphical mode (à la Live-CD) where it is possible to choose whether to test ReactOS in demo mode, or to install it via the GUI setup. Such an all-in-one ISO capability was already present in the trunk under the name hybridcd, but was used only when we built ISO images for the public events where ReactOS participated (FOSDEM, CLT, ). But now, having the setup process both in text mode and in graphics mode, in addition to the Live-CD demonstration capability, really suggests just using the all-in-one ISO and stop doing the Boot-CD (aka. only setup) vs. Live-CD (aka. only demo) separation. We would just generate only one type of ISO that contains everything. With that in mind, I have committed in my branch setup_improvements, in revision 75273 : https://svn.reactos.org/svn/reactos?view=revision <https://svn.reactos.org/svn/reactos?view=revision&revision=75273> &revision=75273 such changes to be able to only build an ISO that contains everything. These changes are minimal, in the sense that I havent purposelessly changed the names of the build targets just to be fancy. Such changes may be done later, but not now. The needed changes are the following: First, the build target that will generate the all-in-one CD is called bootcd, because this also was the main build target for ISOs before the change. Second, I completely remove the hybridcd build target, because its functionality are now absorbed by bootcd. Third, the build target livecd is reduced to its strict minimum. For the sake of building a RAMDISK boot drive (see comments after), I continue to generate an ISO for livecd. But Ive changed the generated name to liveimage.iso, to emphasize the point that it has to be understood as a (virtual) disk image for RAMDISK purposes, not just as a ISO image. Note that I havent renamed the build target livecd to, say, liveimage to reduce my commit changes (such a renaming may be done later). The livecd target builds a list of files that need to be present in the image. The generated liveimage.iso is no-more a bootable ISO, Ive removed inclusion of freeloader + El-Torito boot-sector + the USB-ISO-Hybrid functionality for it. The bootcd target has been slightly changed in order to include the liveimage.iso as a file (for RAMDISK), and to also add the contents of this image in a flattened tree within the bootcd iso: the two directories Profiles and reactos. The 1st-stage text-mode setup is kept, as said before, but its corresponding files + the installation CAB source + the 1st-stage GUI setup application proper goes into a (renamed) directory called i386, corresponding to installation files for an i386 installation (technically, 1 per architecture when well have a ReactOS ported to other archs). These files cannot be present in the same reactos directory as the ones from the flattened LiveImage, because some of the files are different (smss.exe, registry, etc) Our FreeLdr knows from where to boot the 1st-stage text-mode (from i386), as well as the Live-demo in graphics mode (from reactos). I need to adjust the code of few setup components for them to stop relying on hardcoded reactos/ path, and instead use a more dynamic (determined at runtime) path. NOTE FOR DEVS/SYSADMINS: The bootcdregtest build target, generating the special ISO that is fed to our test bots, remains exactly the same, and the files contained in the generated ISO have not changed. NOTE about the RAMDISK feature: I enabled it so that a user can remove the demo media (CD, ) and reuse the drive for other purposes, while still being able to use ReactOS. Of course this requires a large amount of RAM available. And thats also why I include the flattened liveimage files so that one can use the demo without the RAMDISK (when few memory is available). As is currently implemented, this makes the ReactOS all-in-one bootcd large (it gains a good 100 MB) due to duplicated space (the flattened files, plus the same inside liveimage.iso). I cannot do better (unless ditching either the RAMDISK, or keeping it but not include the flattened files) because ReactOS currently doesnt have a way to boot from disk images *that are not meant to be a RAMDISK*. The day when this difficulty is removed, a single disk image could be used either as the RAMDISK or the (non-removable) installation. A second remark is that I dont plan to have the 1st-stage GUI setup available when booting ReactOS in RAMDISK mode because, as a consequence of its current implementation, I would otherwise need to duplicate the installation CAB source in the RAMDISK image too, making it again larger. NOTE about the FreeLdr Boot Menu: Since ReactOS is not that stable currently, we like to boot it in debug mode, and redirect the output to a serial port (usually COM1). However some people dont have serial ports on real hardware, so we propose to boot with debug output redirected to screen. However this may slow ReactOS down, so we also like to boot ReactOS with debug mode disabled. Thats why I proposed the declination of these boot modes for each ReactOS installation contained in the BootCD (Live+Setup, with or without RAMDISK, and with debug enabled or not). The problem is that it clutters a lot the boot menu. A remedy would be to implement in FreeLdr the functionality of editing *existing* boot entries to change their associated boot options, so that one could add by hand the options to enable (or disable) debugging. This is currently unimplemented. The only implemented feature is to set up a new boot entry on the fly to boot ReactOS afterwards. NOTE for regress-testers: Possible remark that I may hear: I only care about installing ReactOS (perhaps just in unattended mode) and I dont care at all about the GUI setup nor about the Live-demo thingie, and your new BootCD is too large. I want to be able to download & use the good-old bootcd for regress-testing. . So what to do? Since we currently build and store the bootcdregtest ISOs, but are not publicly available through our www.reactos.org/getbuilds interface, I would suggest here to make them available to people, so that those who want to quickly DL and/or install/regress-test ReactOS could use these ISOs instead (which are really just the good old BootCDs, but with unattended installation enabled *and* with our test-suite included). They are not that much large, just a bit more than the old regular bootcd. Please let me know whether you have other remarks/comments/questions/suggestions/etc to make the new BootCDs better. Best, Hermès

7 years, 10 months

3
3
0 0

Status Meeting (June 2017)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place 29th of June, 19:00 UTC. We do it either in #reactos-meeting on Freenode, or on a very own standalone IRC server. In that case your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. And everyone is fine with that. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

7 years, 10 months

2
1
0 0

SVN url change?

by Hermès BÉLUSCA-MAÏTO

Hello all, Today I noticed that our buildbots couldnt connect to SVN to upload the commit changes, and therefore failed to build. Also I noticed that the usual SVN ViewVC address (which was previously https://svn.reactos.org/svn/reactos , for example) changed to https://svn.reactos.org/viewcvs/reactos/ (granted, there appear to be an automatic redirection to this new address). Is it an intentional change, or an unintentional one? We didnt seem to be warned prior to this on the mailing list! Cheers, Hermès

7 years, 10 months

2
2
0 0

Please don't read Windows source code

by katahiromz .

According to The Register, Windows 10 source has been leaked. But reading that codes is still illegal for ReactOS development, so we might fire you if you read in the case. ---- Please don't read the leaked source. Thanks, Katayama Hirofumi MZ 片山博文MZ

7 years, 11 months

2
1
0 0

ReactOS Hackfest 2017 - Are you in?

by Colin Finck

Hi all! I'm currently planning the ReactOS Hackfest 2017 in the Cologne/Bonn area in Germany. Currently, the plan is to book a meeting room from Monday, August 14 to Friday, August 18. We can then use the weekend before to get to Cologne and explore the city a bit. After the Hackfest, everybody interested can join us at FrOSCon in Bonn the weekend after. As booking a room there involves significant costs, I'd like to know who of you can definitely make it for the Hackfest and who of you is definitely out. Please reply now to prevent me from bugging you on IRC all the time! ;) Cheers, Colin

7 years, 11 months

8
8
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75164: [SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based on code by Samuel Serapion & MSDN. What needs to be fixed here, is the client/server code to communicate the...

by Colin Finck

hbelusca(a)svn.reactos.org wrote: > [SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based > on code by Samuel Serapion & MSDN. What needs to be fixed here, is the > client/server code to communicate the results back to the main test > app being running. Work in progress. I have implemented short and simple WineTest-compatible client/server code in localspl_apitest. The server is the application that is tested through rosautotest. For every test, it starts the client, sends the test name over a pipe and outputs the received testing output. The client simply has stdout redirected to a pipe and can then use usual WineTest ok() functions for testing. Check out rostests/apitests/localspl (server) and rostests/apitests/localspl/dll (client). Hope that helps! - Colin

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75083: [NTOS]: Use SEH inside CmQueryKey(), as it can be called with user-mode parameter KeyInformation. Remove unused code in CmLoadKey(). I've noticed that in cmapi.c / ntapi.c we do n...

by Alex Ionescu

On Sun, Jun 18, 2017 at 1:34 AM, <hbelusca(a)svn.reactos.org> wrote: > - if (!(CmpProfileLoaded) && !(CmpWasSetupBoot)) > + if (!CmpProfileLoaded && !CmpWasSetupBoot) > Why do you keep re-formatting other people's code in unrelated patches? You've been repeatedly asked to stop doing this. Best regards, Alex Ionescu

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75133: [NTOS]: Revert the pool tag change from r75128, and explain in comment why we cannot actually use it.

by Thomas Faber

On 2017-06-19 18:29, hbelusca(a)svn.reactos.org wrote: > + /* > + * Free it from the pool. > + * > + * We cannot use here ExFreePoolWithTag(..., OB_NAME_TAG); , because > + * the object name may have been massaged during operation by different > + * object parse routines. If the latter ones have to resolve a symbolic > + * link (e.g. as is done by CmpParseKey() and CmpGetSymbolicLink()), > + * the original object name is freed and re-allocated from the pool, > + * possibly with a different pool tag. At the end of the day, the new > + * object name can be reallocated and completely different, but we > + * should still be able to free it! > + */ > + ExFreePool(Buffer); I feel like ExFreePoolWithTag(Buffer, 0) conveys that same message without needing a huge comment?

7 years, 11 months

2
1
0 0

GPU testing machine is ready!

by Colin Finck

Hi all! A picture says more than a thousand words: http://fs5.directupload.net/images/170613/u4d8a59a.png As promised in the last meeting, I have brought to life a machine for testing GPU drivers with real GPUs under ReactOS. It combines a QEMU virtual machine with PCIe GPU Passthrough together with a KVM-over-IP card for feeding the real video signal back to a window. What you see in the screenshot is a real NVIDIA GeForce 9300 GPU attached to a ReactOS VM. We can now test the NVIDIA driver installation while enjoying the easy debuggability of a VM. My first report is already out: https://jira.reactos.org/browse/CORE-13423 Every developer interested in working on this can drop me a line and I will send you credentials for the server. Soon I will also add an AMD Graphics Card along with another KVM-over-IP card to let us debug the other big driver package. Thanks go out to Mr. Kromdijk for the generous server donation, Christoph for the KVM-over-IP card, and Hervé for the QEMU hints! Let's all get some flashy 3D acceleration into ReactOS!! :) Cheers, Colin

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75008: [USETUP]: Introduce SetupDeleteFile() and SetupMoveFile() (in addition to the already-existing SetupCopyFile()) in order to implement moving / renaming existing files. Will be use...

by Thomas Faber

On 2017-06-12 01:58, hbelusca(a)svn.reactos.org wrote: > +NTSTATUS > +SetupMoveFile( > + IN PCWSTR ExistingFileName, > + IN PCWSTR NewFileName, > + IN ULONG Flags) > +{ > + NTSTATUS Status; > + IO_STATUS_BLOCK IoStatusBlock; > + OBJECT_ATTRIBUTES ObjectAttributes; > + PFILE_RENAME_INFORMATION RenameInfo; > + UNICODE_STRING NewPathU, ExistingPathU; > + HANDLE SourceHandle = NULL; This variable fulfills the requirements for _SEH2_VOLATILE > + BOOLEAN ReplaceIfExists; > + > + RtlInitUnicodeString(&ExistingPathU, ExistingFileName); > + RtlInitUnicodeString(&NewPathU, NewFileName); > + > + _SEH2_TRY > + { Which part of this code needs SEH? That looks like it's purely hiding bugs.

7 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tthompson] 74970: [NTFS] - Add the most basic support for file creation. Expand diagnostic output, especially in NtfsDumpIndexRootAttribute(). Replace an ExFreePool() with ExFreePoolWithTag(). Add...

by Thomas Faber

On 2017-06-09 05:14, tthompson(a)svn.reactos.org wrote: > + RtlZeroMemory(&FilenameNoPath, sizeof(UNICODE_STRING)); > + FilenameNoPath.Buffer = Buffer; > + FilenameNoPath.MaximumLength = MAX_PATH; > + RtlInitEmptyUnicodeString does this for you On 2017-06-09 05:14, tthompson(a)svn.reactos.org wrote: > + FileNameAttribute->NameLength = FilenameNoPath.Length / 2; sizeof(WCHAR)?

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [phater] 74750: [MSWSOCK] Call explicitly DnsQuery_W. Copy host aliases if available as answer from the query

by Thomas Faber

On 2017-06-02 19:52, phater(a)svn.reactos.org wrote: > + aDstNextStr = (char*)((DWORD)aDstNextStr + (DWORD)bItmLen); DWORD cannot always fit a pointer. You want DWORD_PTR for this kind of math (or simply use char *).

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74742: [USETUP]: Creating a registry key with zero access is just plainly invalid. Fix it. It was not caught before because, we never ever booted a 1st-stage setup with a valid mounted e...

by Thomas Faber

On 2017-06-02 02:44, hbelusca(a)svn.reactos.org wrote: > @@ -341,7 +341,7 @@ > } > > InitializeObjectAttributes(&ObjectAttributes, &ServicesU, OBJ_CASE_INSENSITIVE, NULL, NULL); > - Status = NtCreateKey(&hServices, 0, &ObjectAttributes, 0, NULL, 0, NULL); > + Status = NtCreateKey(&hServices, KEY_ALL_ACCESS, &ObjectAttributes, 0, NULL, 0, NULL); > if (!NT_SUCCESS(Status)) > { > DPRINT1("NtCreateKey('%wZ') failed with status 0x%08lx\n", &ServicesU, Status); > > It doesn't really need full access, does it? Could have gone for something closer to the original, like READ_CONTROL.

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74741: [MKHIVE][CMAKE]: Make mkhive a bit more flexible, so that it can generate only specific hives on-demand (and not all of them always at once). I need this for building a single boo...

by Thomas Faber

I understand not making the change to how 1st stage deals with the registry in trunk. Why not the tool change though? Can't you have the new mkhive do the exact same thing it does now, and do it in trunk? The smaller your branch merge commit the easier it will be to avoid/pinpoint/fix regressions. On 2017-06-02 02:34, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Fri Jun 2 00:34:10 2017 > New Revision: 74741 > > URL: http://svn.reactos.org/svn/reactos?rev=74741&view=rev > Log: > [MKHIVE][CMAKE]: Make mkhive a bit more flexible, so that it can generate only specific hives on-demand (and not all of them always at once). I need this for building a single bootcd registry hive. > I commit these changes in my branch because it's too much über-advanced code for our trunk, yet... (and it will uncover deep "setup" hacks in NTOS' iomgr & pnpmgr as soon as I'll enable 1-st stage setup to have a proper registry present as done on windows). > CORE-13347 #comment Committed in r74741 but just in the setup_improvements branch for the moment.

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74733: [NTOS]: Minor code formatting + don't leak a handle in case of failure, in CmpInitializeHardwareConfiguration().

by Thomas Faber

On 2017-06-01 20:27, hbelusca(a)svn.reactos.org wrote: > /* EISA */ > case EisaAdapter: > - > + { > /* Fixup information */ > Interface = Eisa; > Bus = CmpTypeCount[EisaAdapter]++; > break; > + } This is a completely unnecessary change to somebody else's code that has no basis in our documented coding style. Uh... don't do that?

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74739: [MKHIVE]: Formatting changes only + sync back the names of the reg-inf functions with the ones where they are coming from (aka. Wine's setupapi/install.c).

by Thomas Faber

On 2017-06-02 02:00, hbelusca(a)svn.reactos.org wrote: > [MKHIVE]: Formatting changes only + sync back the names of the reg-inf functions with the ones where they are coming from (aka. Wine's setupapi/install.c). Those two goals clearly conflict with either other. Either keep Wine's function names AND formatting to keep things comparable/sync-able, or make the code follow our style.

7 years, 11 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74735: [NTOS]: Better clean up behind ourselves on failure paths (aka. closing handles). These functions are clearly not written with correct cleanup-on-failure concept in mind...

by Thomas Faber

On 2017-06-01 20:37, hbelusca(a)svn.reactos.org wrote: > + if (!NT_SUCCESS(Status)) > + { > + /* We failed, close all the opened handles and return */ > + // NtClose(KeyHandle); Please don't add commented-out code. What is that supposed to even mean? "I was too lazy to test this"? "All the other code depends on this leak"? "I think it would look prettier here"?

7 years, 11 months

1
0
0 0

Status Meeting - rescheduled

by Aleksey Bragin

Hello, I propose to reschedule our monthly meeting to Thursday next week (1st of June), as tomorrow is a holiday in some countries, and also I have tight meetings schedule this week. Regards, Aleksey Bragin

7 years, 11 months

4
3
0 0

mplayer -- branded name?

by Javier Agustìn Fernàndez Arroyo

Hey guys, An idea has just come to my mind, mplayer is an application that already exists for Linux: https://www.mplayerhq.hu/design7/news.html maybe we should change ReactOS´ player name so that we avoid possible future demands? what do u think?

7 years, 11 months

1
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74698: [USETUP]: Minor fixes & simplifications: - Remove a redundant NtClose call; - Return failure if NtQuerySymbolicLinkObject fails; - Use RTL_CONSTANT_STRING and RtlInitEmptyUnicodeS...

by Colin Finck

hbelusca(a)svn.reactos.org wrote: > -/* > - * ReactOS kernel > - * Copyright (C) 2002 ReactOS Team > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License along > - * with this program; if not, write to the Free Software Foundation, Inc., > - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > - */ > /* > * COPYRIGHT: See COPYING in the top level directory > * PROJECT: ReactOS text-mode setup You're taking away the information that this file is licensed under GPLv2 or any later version (as opposed to GPLv2-only, what some developers prefer). Also the entire license information is lost when this file is used as part of a different source tree. I have visited a seminar by our friend Nuno Brito last week, who has founded a company that deals with such topics (www.triplecheck.tech). There are some simple best practices we can apply here to get consistent and useful headers once and for all. The first would be using the established SPDX license identifiers from https://spdx.org/licenses (here: "GPL-2.0+"). This would also make our source files easily scannable by tools to get an overview of all licenses involved in our code and imported third-party components. If you or someone else is interested in working on this, let's draft a universal header for our files that is compatible with SPDX. Otherwise, I will have a look when there's more time.. Cheers, Colin

7 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [mjansen] 74693: [KERNEL32] Initial implementation for BaseCheckRunApp, calling into apphelp to check for compatibility fixes CORE-10368

by Thomas Faber

Testbots seem to dislike this commit, looks like 3rd stage boot is broken in some way. :( On 2017-05-28 21:27, mjansen(a)svn.reactos.org wrote: > Author: mjansen > Date: Sun May 28 19:27:51 2017 > New Revision: 74693 > > URL: http://svn.reactos.org/svn/reactos?rev=74693&view=rev > Log: > [KERNEL32] Initial implementation for BaseCheckRunApp, calling into apphelp to check for compatibility fixes CORE-10368 > > Modified: > trunk/reactos/dll/win32/kernel32/client/appcache.c > trunk/reactos/dll/win32/kernel32/client/utils.c > > Modified: trunk/reactos/dll/win32/kernel32/client/appcache.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/appcache.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/appcache.c [iso-8859-1] Sun May 28 19:27:51 2017 > @@ -16,7 +16,20 @@ > /* GLOBALS ********************************************************************/ > > ULONG g_ShimsEnabled; > - > +static BOOL g_ApphelpInitialized = FALSE; > +static PVOID g_pApphelpCheckRunAppEx; > +static PVOID g_pSdbPackAppCompatData; > + > +typedef BOOL (WINAPI *tApphelpCheckRunAppEx)(HANDLE FileHandle, PVOID Unk1, PVOID Unk2, PWCHAR ApplicationName, PVOID Environment, USHORT ExeType, PULONG Reason, > + PVOID* SdbQueryAppCompatData, PULONG SdbQueryAppCompatDataSize, PVOID* SxsData, PULONG SxsDataSize, > + PULONG FusionFlags, PULONG64 SomeFlag1, PULONG SomeFlag2); > +typedef BOOL (WINAPI *tSdbPackAppCompatData)(PVOID hsdb, PVOID pQueryResult, PVOID* ppData, DWORD *dwSize); > + > +#define APPHELP_VALID_RESULT 0x10000 > +#define APPHELP_RESULT_NOTFOUND 0x20000 > +#define APPHELP_RESULT_FOUND 0x40000 > + > + > /* FUNCTIONS ******************************************************************/ > > BOOLEAN > @@ -136,7 +149,120 @@ > DPRINT("BaseCheckAppcompatCache is UNIMPLEMENTED\n"); > > if (Reason) *Reason = 0; > - return TRUE; > + > + // We don't know this app. > + return FALSE; > +} > + > +static > +VOID > +BaseInitApphelp(VOID) > +{ > + WCHAR Buffer[MAX_PATH*2]; > + UNICODE_STRING DllPath = {0}; > + PVOID ApphelpAddress; > + PVOID pApphelpCheckRunAppEx = NULL, pSdbPackAppCompatData = NULL; > + > + RtlInitEmptyUnicodeString(&DllPath, Buffer, sizeof(Buffer)); > + RtlCopyUnicodeString(&DllPath, &BaseWindowsDirectory); > + RtlAppendUnicodeToString(&DllPath, L"\\system32\\apphelp.dll"); > + > + if (NT_SUCCESS(LdrLoadDll(NULL, NULL, &DllPath, &ApphelpAddress))) > + { > + ANSI_STRING ProcName; > + > + RtlInitAnsiString(&ProcName, "ApphelpCheckRunAppEx"); > + if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, &ProcName, 0, &pApphelpCheckRunAppEx))) > + pApphelpCheckRunAppEx = NULL; > + > + RtlInitAnsiString(&ProcName, "SdbPackAppCompatData"); > + if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, &ProcName, 0, &pSdbPackAppCompatData))) > + pSdbPackAppCompatData = NULL; > + } > + > + if (InterlockedCompareExchangePointer(&g_pApphelpCheckRunAppEx, RtlEncodeSystemPointer(pApphelpCheckRunAppEx), NULL) == NULL) > + { > + g_pSdbPackAppCompatData = RtlEncodeSystemPointer(pSdbPackAppCompatData); > + } > +} > + > +/* > + * > + */ > +BOOL > +WINAPI > +BaseCheckRunApp(IN HANDLE FileHandle, > + IN PWCHAR ApplicationName, > + IN PWCHAR Environment, > + IN USHORT ExeType, > + IN PULONG pReason, > + IN PVOID* SdbQueryAppCompatData, > + IN PULONG SdbQueryAppCompatDataSize, > + IN PVOID* SxsData, > + IN PULONG SxsDataSize, > + OUT PULONG FusionFlags) > +{ > + ULONG Reason = 0; > + ULONG64 Flags1 = 0; > + ULONG Flags2 = 0; > + BOOL Continue, NeedCleanup = FALSE; > + tApphelpCheckRunAppEx pApphelpCheckRunAppEx; > + tSdbPackAppCompatData pSdbPackAppCompatData; > + PVOID QueryResult = NULL; > + ULONG QueryResultSize = 0; > + > + if (!g_ApphelpInitialized) > + { > + BaseInitApphelp(); > + g_ApphelpInitialized = TRUE; > + } > + > + pApphelpCheckRunAppEx = RtlDecodeSystemPointer(g_pApphelpCheckRunAppEx); > + pSdbPackAppCompatData = RtlDecodeSystemPointer(g_pSdbPackAppCompatData); > + > + if (!pApphelpCheckRunAppEx || !pSdbPackAppCompatData) > + return TRUE; > + > + if (pReason) > + Reason = *pReason; > + > + Continue = pApphelpCheckRunAppEx(FileHandle, NULL, NULL, ApplicationName, Environment, ExeType, &Reason, > + &QueryResult, &QueryResultSize, SxsData, SxsDataSize, FusionFlags, &Flags1, &Flags2); > + > + if (pReason) > + *pReason = Reason; > + > + if (Continue) > + { > + if ((Reason & (APPHELP_VALID_RESULT|APPHELP_RESULT_FOUND)) == (APPHELP_VALID_RESULT|APPHELP_RESULT_FOUND)) > + { > + if (!pSdbPackAppCompatData(NULL, QueryResult, SdbQueryAppCompatData, SdbQueryAppCompatDataSize)) > + { > + DPRINT1("SdbPackAppCompatData returned a failure!\n"); > + NeedCleanup = TRUE; > + } > + } > + else > + { > + NeedCleanup = TRUE; > + } > + } > + > + if (QueryResult) > + RtlFreeHeap(RtlGetProcessHeap(), 0, QueryResult); > + > + if (NeedCleanup) > + { > + BasepFreeAppCompatData(*SdbQueryAppCompatData, *SxsData); > + *SdbQueryAppCompatData = NULL; > + if (SdbQueryAppCompatDataSize) > + *SdbQueryAppCompatDataSize = 0; > + *SxsData = NULL; > + if (SxsDataSize) > + *SxsDataSize = 0; > + } > + > + return Continue; > } > > /* > @@ -171,9 +297,11 @@ > Environment, > &Reason)) > { > - /* We don't support this yet */ > - UNIMPLEMENTED; > - Status = STATUS_ACCESS_DENIED; > + if (!BaseCheckRunApp(FileHandle, ApplicationName, Environment, ExeType, &Reason, > + SdbQueryAppCompatData, SdbQueryAppCompatDataSize, SxsData, SxsDataSize, FusionFlags)) > + { > + Status = STATUS_ACCESS_DENIED; > + } > } > } > > > Modified: trunk/reactos/dll/win32/kernel32/client/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] Sun May 28 19:27:51 2017 > @@ -904,26 +904,6 @@ > /* > * @unimplemented > */ > -BOOL > -WINAPI > -BaseCheckRunApp(IN DWORD Unknown1, > - IN DWORD Unknown2, > - IN DWORD Unknown3, > - IN DWORD Unknown4, > - IN DWORD Unknown5, > - IN DWORD Unknown6, > - IN DWORD Unknown7, > - IN DWORD Unknown8, > - IN DWORD Unknown9, > - IN DWORD Unknown10) > -{ > - STUB; > - return FALSE; > -} > - > -/* > - * @unimplemented > - */ > NTSTATUS > WINAPI > BasepCheckWinSaferRestrictions(IN HANDLE UserToken, > >

7 years, 11 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74621: [USETUP]: SetupLib: Add an ARC path to (and from) NT path resolver. It allows mapping between an ARC path as specified in freeldr.ini / boot.ini , to its corresponding NT path, if...

by Thomas Faber

On 2017-05-22 03:09, hbelusca(a)svn.reactos.org wrote: > --- branches/setup_improvements/base/setup/lib/arcname.c (added) > +++ branches/setup_improvements/base/setup/lib/arcname.c [iso-8859-1] Mon May 22 01:09:35 2017 > +PCSTR > +ArcGetNextTokenA( > + IN PCSTR ArcPath, > + OUT PANSI_STRING TokenSpecifier, > + OUT PULONG Key) > +{ > + HRESULT hr; > + PCSTR p = ArcPath; > + ULONG SpecifierLength; > + ULONG KeyValue; > + > + /* > + * We must have a valid "specifier(key)" string, where 'specifier' > + * cannot be the empty string, and is followed by '('. > + */ > + p = strchr(p, '('); > + if (p == NULL) > + return NULL; /* No '(' found */ > + if (p == ArcPath) > + return NULL; /* Path starts with '(' and is thus invalid */ > + > + SpecifierLength = (p - ArcPath) * sizeof(CHAR); > + > + /* > + * The strtoul function skips any leading whitespace. > + * > + * Note that if the token is "specifier()" then strtoul won't perform > + * any conversion and return 0, therefore effectively making the token > + * equivalent to "specifier(0)", as it should be. > + */ > + // KeyValue = atoi(p); > + KeyValue = strtoul(p, (PSTR*)&p, 10); > + > + /* Skip any trailing whitespace */ > + while (*p && isspace(*p)) ++p; isspace(0) is false so you don't need the *p check. > +PCWSTR > +ArcGetNextTokenU( > + IN PCWSTR ArcPath, > + OUT PUNICODE_STRING TokenSpecifier, > + OUT PULONG Key) > +{ > + HRESULT hr; > + PCWSTR p = ArcPath; > + ULONG SpecifierLength; > + ULONG KeyValue; > + > + /* > + * We must have a valid "specifier(key)" string, where 'specifier' > + * cannot be the empty string, and is followed by '('. > + */ > + p = wcschr(p, L'('); > + if (p == NULL) > + return NULL; /* No '(' found */ > + if (p == ArcPath) > + return NULL; /* Path starts with '(' and is thus invalid */ > + > + SpecifierLength = (p - ArcPath) * sizeof(WCHAR); > + > + ++p; > + > + /* > + * The strtoul function skips any leading whitespace. > + * > + * Note that if the token is "specifier()" then strtoul won't perform > + * any conversion and return 0, therefore effectively making the token > + * equivalent to "specifier(0)", as it should be. > + */ > + // KeyValue = _wtoi(p); > + KeyValue = wcstoul(p, (PWSTR*)&p, 10); > + ASSERT(p); This assert seems superfluous, you just dereferenced the pointer. Also, you incremented it just above and also (rightly) assumed it was larger than ArcPath. > +static NTSTATUS > +ResolveArcNameManually( > + OUT PUNICODE_STRING NtName, > + IN OUT PCWSTR* ArcNamePath, > + IN PPARTLIST PartList OPTIONAL) > +{ > [...] > +Quit: > + if (FAILED(hr)) > + { > + /* > + * We can directly cast the HRESULTs into NTSTATUS since the error codes > + * returned by StringCbPrintfW: > + * STRSAFE_E_INVALID_PARAMETER == 0x80070057, > + * STRSAFE_E_INSUFFICIENT_BUFFER == 0x8007007a, > + * do not have assigned values in the NTSTATUS space. > + */ > + return (NTSTATUS)hr; To me that sounds like an argument of why you _can't_ do that. (You know the Rtl versions of these functions give you an NTSTATUS btw, right?) > --- branches/setup_improvements/base/setup/lib/arcname_tests.c (added) > +++ branches/setup_improvements/base/setup/lib/arcname_tests.c [iso-8859-1] Mon May 22 01:09:35 2017 > @@ -0,0 +1,142 @@ > +/* > + * Tests for the arcname.c functions: > + * - ArcPathNormalize(), > + * - ArcPathToNtPath(). > + * > + * You should certainly fix the included headers before being able > + * to compile this file (as I didn't bother to have it compilable > + * under our (P/N)DK, but just under VS). > + */ Wine's test framework works okay for unit tests. You can make this an apitest by just #include'ing the C source file, then it can run on Testbot.

8 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev