http://reactos.com:8080/archives/public/ros-svn/2005-April/002066.html
or run
"ARCH=i386 make bootcd"
--- ea <ea(a)iol.it> wrote:
> Hi all,
>
> I can't build the bootable cd image.
> Is it just my local repository broken (14488)?
>
> ---
> 3: directory ./../bootcd/disk\reactos\system32\
> 3: file ./../bootcd/disk\reactos\system32\ntdll.dll
> 3: file ./../bootcd/disk\reactos\system32\smss.exe
> Can't open ./../bootcd/disk/../isoboot.bin
>
> make: *** [bootcd_makecd] Error 1
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi all,
I can't build the bootable cd image.
Is it just my local repository broken (14488)?
---
3: directory ./../bootcd/disk\reactos\system32\
3: file ./../bootcd/disk\reactos\system32\ntdll.dll
3: file ./../bootcd/disk\reactos\system32\smss.exe
Can't open ./../bootcd/disk/../isoboot.bin
make: *** [bootcd_makecd] Error 1
Hi Robert:
Yes 7Zip compresses sometimes (most of the times) more than WinRAR. In fact as far as I know they both use the same algorithm for text compression. 7Zip has 3 compression algorithms so you could try all and see for yourself. It also supports streams so you can compress things from the output of one of the algorithms and make it the input of the other. For example to compress executables you could use jcc and it´s output pass it to LZMA. It also provides larger dictionaries if you want. WinRAR´s maximun size is 4 MB so usually WinRaR files are larger. When it comes about speed WinRAR is faster. But I guess that´s irrelevant right now. On the other side I think that sourceforge someday should be enhanced to give users the option to download the files in the selected format, maybe providing a link to the decompressor. Maybe I fill someday the feature request form for sourceforge It will save us and maybe will save them some time.
Best Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Robert Köpferl
Sent: Sun 4/3/2005 5:08 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Ros 0.2.6-RC2 on sf.net
Having read your comments, I came to this conclusion:
I'll have a try with 7zip and if it compresses slightly less or better
than rar, I'll use 7zip (because it is free). For a test period I'll
provide both, zip and 7zip/rar and the user may decide which one will
win. Additionally I'll provide a file 'how to decompress.txt' in every
release. Wheras I think, people who come to download an OS know enough
to find one theirselves. Making exe-files is still an option but I
don't like it. So you have to convince me.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
it might seem stupid or girlish, but I want to invite any of you to
visit me in Vienna (wien.AT) for a couple of days. I would like to just
see some of these people (and of course have freeky kernel talks) who
make up this project. Get to know personally. Don't be shy and have a
try with my private email. (possibly use gpg/x.509).
If you think this Vienna is too far away - maybe next year I live less
far away from you.
With svn 14668 , Ros bugchecks when I click on the "my computer " icon
and o then on the "C" disk drive icon as per debug messages below.
This is a regression and it is always reproductible .
I cannot say exactly when it has been broken.
Any idea ?
-----------------------------
PM_OPEN_WINDOW: path=C:\
KeBugCheckWithTf at ke/catch.c:237
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x8004773e,0x00000000,0x00000006)
*** ntoskrnl.exe - Address 0x8004773e base at 0x80000000, DateStamp 0x0
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:8004773e <ntoskrnl.exe:4773e (io/mdl.c:130
(IoFreeMdl))>
cr2 6 cr3 d896000 Proc: 80d46990 Pid: f0 <explorer> Thrd: 80d50a68 Tid: f4
DS 10 ES 10 FS 30 GS 23
EAX: 00000000 EBX: 8004635f ECX: 00000003
EDX: 00000002 EBP: a1f76a88 ESI: 007ecdd8 ESP: a1f769d8
EDI: a1f76d74 EFLAGS: 00010282 kESP a1f769d8 kernel stack base a1f74000
Frames:
<ntoskrnl.exe:3c7d0 (io/cleanup.c:112 (IoReadWriteCompletion))>
<ntoskrnl.exe:3c8e0 (io/cleanup.c:211 (IoSecondStageCompletion))>
<ntoskrnl.exe:4694d (io/irp.c:498 (IofCompleteRequest))>
<vfatfs.sys:c65c (rw.c:775 (VfatRead))>
<vfatfs.sys:dcc9 (misc.c:110 (VfatDispatchRequest))>
<vfatfs.sys:de94 (misc.c:168 (VfatBuildRequest))>
<ntoskrnl.exe:4627d (io/irp.c:211 (IofCallDriver))>
<ntoskrnl.exe:46293 (io/irp.c:226 (IoCallDriver))>
<ntoskrnl.exe:4e6b0 (io/rw.c:154 (NtReadFile))>
<ntoskrnl.exe:38f2 (C:\DOCUME~1\home\LOCALS~1\Temp/ccucbaaa.s:178
(KiSystemService))>
<kernel32.dll:278f6 (file/rw.c:154 (ReadFile))>
Reaards
Gerard
Hi,
--- Phillip Susi <psusi(a)cfl.rr.com> wrote:
> Are you talking about being able to create usable ram disks at runtime
> and use them for general file storage instead of holding the system
> volume? I don't really see any use for ram disks other than holding the
> system volume so the media used to boot the system can be removed.
Yes thats the idea. We tend to get requests for one every so often though I don't know what people
use them for. There is a example driver with source code on support.microsoft.com that I always
point people to.
Thanks
Steven
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
--- Phillip Susi <psusi(a)cfl.rr.com> wrote:
> I seem to remember you added a special multiboot header to the kernel
> image but it looks to me like ntoskrnl.exe has a standard PE image header.
Alex changed this. ntoskrnl now is PE loaded from freeldr. I think it was needed for dynamic ACPI
and 3GB support.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
hbirr(a)svn.reactos.com wrote:
>- Fixed ExTimerRundown.
>
>
Hi,
Can you please explain some of your changes? You have introduced several
changes that I don't understand, such as cancelling the timer's APC
without actually making sure that it has an APC associated, as well as
slowing down the path and forcing additionnal locking of the DB lock by
using KeCancelTimer (which also uselessly checks if the timer is
inserted -- we are sure it already is).
Apart from that, thanks for fixing the silly bugs!
Best regards,
Alex Ionescu
Hey Brian, I've been having all kinds of weird problems getting
freeloader installed and working in a boot drive image for qemu. I seem
to remember you used to have to build it with djgpp instead of mingw for
some odd reason. I think it had something to do with mingw's ld
clobbering something up when you asked it to output a binary flat file
instead of a PE image. Is this still the case? Was that issue never
resolved?
Hello,
--- ea(a)svn.reactos.com wrote:
> Updated files:
> trunk/reactos/lib/wintrust/wintrust.def
Tappak if you are watching can you relicense wintrust as BSD v2 or LGPL/GPL? If not it will have
to be removed from SVN as it has a BSD 1 license header which is GPL incompatible. Same thing with
the wintrust.h
Thanks
Steven
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
sedwards(a)svn.reactos.com wrote:
>__USE_W32API
>
>
>Added files:
>trunk/reactos/lib/msgina/makefile
>
>Updated files:
>trunk/reactos/lib/msgina/msgina.c
>trunk/reactos/lib/msgina/stubs.c
>
>Deleted files:
>trunk/reactos/lib/msgina/Makefile
>
>
This library should probably be moved to reactos/subsys because it is
loaded exclusively by winlogon.
It seems that Longhorn drops the GINA. Is it confirmed? Is it due to a
broken (=insecure) design that can not be fixed? If so, should we spend
time implementing GINA?
Emanuele
mingw32-linux is not setting ARCH=i386,
this breaks make bootcd for it.
(although there is an easy workaround)
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
--- Richard Campbell <eek2121(a)comcast.net> wrote:
> *faints*
*grabs the smellinbg salts for Richard and waves hi to Phillip.
Phillip, welcome back! I was looking at some of your code a while back (RAM Disk Driver) and was
wondering if we should add support to it to be a general purpose RAM driver while keeping suppport
for loading from bochs images as it does now.
Thanks
Steven
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
Hi,
it seems we have now a file en.rc and En.rc. This will not work on windows.
- Hartmut
weiden(a)svn.reactos.com wrote:
>corrected file name so it matches the include in slayer.rc
>
>
>Added files:
>trunk/reactos/lib/shellext/slayer/En.rc
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
On Mar 30, 2005 12:49 PM, James Dodd <admin(a)doddnetwork.co.uk> wrote:
> I think people are right with the about page.
The whitepaper and FAQ will answer more than enough. The entire first
set of links at the top links to various 'about' topics.
> I've also moved the language bar to the top of the screen...
That I like.
> Even these companies are moving away from this and creating a more user
> friendly approach to their sites which intern represents their OS.
Yes, those *companies*. Apache.org seems to be doing fine with their
minimalist design.
> The new site at the moment does seem more appropriate to developers as
> apposed to attracting new audiences.
What new audiences? Developers are really what is most important to
this project right now. I'm going to stop short of chanting
"developers! developers! developers!" ;)
Cheers
Jason
Hi all
Jh sent me a better look: http://reactos.com/newsite/reactos_index.html
I think it looks better!
I've also reworded our slogan at the top to read what Steven suggested.
Magnus: I'm sorry but your critism is not constructive! Which links do
you want on the frontpage that aren't already there? You cannot link
to everything on the frontpage either!
Cheers
Jason
And needs an SVN account ;)
I'm glad to see everyone kept the project going without me, I am
impressed with the progress!
Hopefully now I can get back to contributing.
--- Robert K�pferl <rob(a)koepferl.de> wrote:
> I can think of an infrasturcture where one could update a list and
> gather packageinformation from all over the internet and install random
> apps hosted by theirs creators or sf.net
Yeah thats kinda my thinking. We maintain a database of all of the free Win32 software on
SourceForge and try to get them all to use MSI or NSIS to package them.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/
Hi,
--- Maarten Bosma <maarten.paul(a)bosma.de> wrote:
> As you might remember firk85 and me have started coding a package
> manager for ReactOS. More information and a download linkcan be found on
> the wiki on http://wiki.reactos.com/PackageManager .
>
> Since it is now so far that it is at least a bit useful, I'd like to ask
> what you think of adding it to the svn-tree ?
MSI already does everything you want to do. Add support for loading MSI packages by developing
your application on Windows and then it should work in ReactOS as we share msi.dll and msiexec
with wine. Vendors can already use Wix to package thier applications. For bonus points make it tie
in nicely with NSIS.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
Hi,
--- Maarten Bosma <maarten.paul(a)bosma.de> wrote:
> I missed to introduce a concept of the package manager here. Packages
> are not a Archive file with an instruction for installing like apt
> packages. The more an instruction to download the program, that might be
> running the setup with a special parameter or downloading an arrive
> file with the binaries. That is a little bit of BSD ports or Gentoo Emerge.
>
> This is why I think MSI files aren't the right think to replace the
> basic based scripts, that are used at the moment. It simply not what
> they have been made for. But if the vendor of the application provides a
> msi file of cause it can be used; with a "msi"-script-command.
I think the idea of a central repository containting information on Free(Open) Win32 is a good
idea.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
Hi,
--- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
> Why not?
> Its perfectly possible to include a CPL program on the same CD or zip file
> as a GPL program as long as they dont directly mix code (IANAL but this is
> what I understand). Linux distributions mix and match code of all different
> licences and get away with it.
Because we have developed this project like Debian or FreeBSD though we have a "Unspoken Social
Contract" GPL incompatible software will not be mixed in the same package or on the same medium as
GPL compatible software. I am perfectly happy to have WiX or any other OSS package shipped with
ReactOS on a Non-Free CD. It does not mean that I view the CPL as Non-Free, far from it, but in
the GPLs current incarnation it has been deamed GPL-incompatible. Maybe the GPL v3 will address
these issues and we can even ship WiX in the same package/cd as ReactOS but I still would rather
not have ReactOS become dependant on code developed by Microsoft as it may make them rethink the
idea of Freeing other packages in the future.
I would rather link, provide downloads to (apart from the main ReactOS package), and ship it on a
"extras" CD.
Thanks
Steven
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
--- Maarten Bosma <maarten.paul(a)bosma.de> wrote:
> If I understood you correctly you said that there is no need for
> developing a compleatly new system, a Packagemanager only had to provide
> a interface for the msi files.
Right, You can interface directly to the MSI database in the registry.
> First of all, I have to say that I don't know much about that msi stuff.
> So my question is how would the msi file and the program communicte ?
> The point with a packagemanager is that you choose to install lots of
> packages and leave your PC alone. So the package manager had to send the
> dessions of the user to the msi file and then the msi file had to do
> it's operations senlitly. And send reports to the package manager from
> time to time. And if something went wrong, it has to send a compleate
> error report.
Well MSI packages have a lot of options, more so than are used by most people. Most people just
write a Install Shield wizard and have the software packaged in a msi but it can do self-repair
and modification and all sorts of cool stuff. Most third partys now ship apps as MSI as its what
Microsoft supports or they use NullSoft Install System so making a easy to use interface to both
of them will win the most support. Its like a mini-sql database so you can even use XML to mess
with it in your Package Manager. If I understand correctly the Microsoft tool for creating MSI
packages "WiX", uses a xml file for input. The only problem is that WiX is CPL and not GPL so we
cannot ship it with ReactOS unless we make it a seperate download.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
NTFS is an important feature of Windows NT, it is one of the most
advanced file systems devised. It contains many security devices that
makes Windows NT secure. It is much more reliable than FAT.
Perhaps instead of waiting for someone to make complete NTFS support
in ReactOS (not that it shouldn't be done), we may make a filesystem
of our own that is designed with NTFS features in mind
(http://linux-ntfs.sf.net/ntfs/), but since we make it we have
complete support for it. I was thinking of the name MUSCLE, a pun of
FAT. I'm not exactly sure if the letter mean anything yet, but they
could be in the future ;)
--
Mike
Hallo,
As you might remember firk85 and me have started coding a package
manager for ReactOS. More information and a download linkcan be found on
the wiki on http://wiki.reactos.com/PackageManager .
Since it is now so far that it is at least a bit useful, I'd like to ask
what you think of adding it to the svn-tree ?
Maarten Bosma
Hello,
After doing some research, I've decided to go ahead and start a port of
ReactOS to Xen. For those in the Xen community not familiar with ReactOS:
it's an open-source (GPL) re-implementation of the Microsoft Windows
NT-based line of operating systems, aiming to provide binary compatibility
for both applications and drivers
(http://www.reactos.com). For those in the ReactOS community not familiar
with Xen: it's an open-source (GPL) virtual machine monitor that supports
execution of multiple guest operating systems with unprecedented levels of
performance and resource isolation
(http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html).
Initially I'll focus on getting ReactOS running as a guest OS. This should
benefit ReactOS primarily, since this will make it possible to develop large
parts of ReactOS (everything except for hardware drivers and some low-level
memory management) inside Xen. It will also give ReactOS access to some
hardware not natively supported yet (by using the Linux driver). The benefit
for Xen at this stage would be the development of ReactOS device drivers for
interfacing
with Xen, which could also be used for a Windows XP port. On the longer
term, I see no reason why ReactOS couldn't function as a driver domain. As
driver compatibility improves in ReactOS, this could provide Xen guests
access to hardware for which the manufacturer provides only Windows drivers
(due to Xens nature, not every driver
could be used this way, but I bet a large percentage of the drivers depend
on the kernel to do the really low-level stuff).
All in all, it seems a win-win proposition for both projects. And even more
importantly, I think it's a cool project :-)
I've made a branch in ReactOS svn, svn://svn.reactos.com/branches/xen, for
this port. Of course, the goal is to merge the changes into trunk
eventually. I expect the port to take at least a few months, my initial
feeling is that it should be done by the end of the year (there's lots of
other stuff in ReactOS I want to work on too). The wiki page at
http://wiki.reactos.com/Xen_port will be used to keep track of progress. The
game plan is just start working from the boot code, until a problem is hit.
Fix that problem and continue until the next problem.
Any support and help from the Xen and ReactOS communities are of course
greatly appreciated.
Gé van Geldorp.