Re: [Freedos-user] DOS networking with embedded Realtek PCIe - 8168
> After fleshing out the net.cfg to a > bare minimum - leaving Ethernet-II framing /only/ - it is > working now ! I've received in-private request to display the contents of the so fleshed out NET.CFG. Thanks for asking. ! Here is the resultant, FWIW - it could hardly be simpler : --- NET.CFG - ; Link Support Max Stacks 8 buffers 6 1600 Link Driver rtgeodi NICNo 1 Frame Ethernet_II MEDIUM AUTO NetWare DOS Requester FIRST NETWORK DRIVE = F NETWARE PROTOCOL = NDS BIND --- Then loading and starting the protocol stack up-to and including the "packet" driver is as easy as : > LSL > RTGEODI > ODIPKT N.B. I suspect the "Netware DOS Requester" section in the above is not relevant and could be ditched also, but I haven't checked yet and I am cut-n-pasting what is sure working... HTH... -- Czerno -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS networking with embedded Realtek PCIe - 8168
After fleshing out the net.cfg to a bare minimum - leaving Ethernet-II framing /only/ - it is working now ! Thanks for the heads-up ! On Sat, 18 Aug 2018 19:10:33 -0400, Don Flowers wrote : | Make sure your net.cfg setting are | specific to rtgeodi. Usually rtgbodi is | default. Also rearrange frame | hierarchy; there are several odipkt driver | you may have to hunt try way back | machine On Saturday, August 18, 2018, Bertho Grandpied via Freedos-user < freedos-user@lists.sourceforge.net> wrote: > Had anyone been successfully DOS-networking using the RT Gigabit adapter > in Subj ... -- Czerno -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] DOS networking with embedded Realtek PCIe - 8168
Had anyone been successfully DOS-networking using the RT Gigabit adapter in
Subj, I will
humbly take their lessons. My new board (Biostar A68MD-Pro with AMD A10 CPU)
has embedded Realtek 8168 GB ethernet controller, for which I sought a DOS
"packet driver".
At Realtek's site, no packet driver, but they do offer an "ODI" driver
("rtgeodi.com") : which I got, and then ran in turn the usual trilogy of TSRs:
> LSL
> RTGEODI
> ODIPKT 1; comment : alternatively, PKT2ODI /B:2
This "trilogy" installs "successfully" - at least, each TSR in turn while
installing itself reports success.
In conjunction with an appropriate NET.CFG... and a TCP/IP network stack such
as Trumpet's, or built-in to DOS networking programs... it should've been a
piece of cake, in my experience, but alas ! *None work* ! Not any type
datagram seems to go in/out on the wire...
I know the adapter itself is "good" (works as designed in, sorry to have to
mention it, Windows 10).
Also, the Realtek test program in DOS sees, accesses the adapter and local
tests pass OK.
At this point I'm lost. Either the, Realtek provided ODI driver doesn't in fact
support the flavour of embedded adapter I have got, could there be a "secret
sauce" required to initialise the adapter ?
Ah ! I also tried the well known "net boot disk" (an image, run through
Gru4DOS, since this new machine - of course - doesn't have floppy).
Interestingly, /it/ didn't work either, though it identified the adapter
correctly; significant, for the net bootdisk uses another approach altogether
than what I have sketched above, namely it tries to install MS-DOS (NDIS)
networking. Didn't work either :=(
I am sure a number of people reading this letter are (much) more used to fixing
this kind of problems than I will ever be. Hoping for a heads-up (or just tell
me it won't work, so I don't lose my time and last hair on this enigma)...
TYiA
--
Czerno
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
On Mon, 8 Jul 2013 16:29:14 +0200 Tom Ehlert t...@drivesnapshot.de I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. this 'more' makes me think that you should prove your competence first I agree. The above quoted phrase was a late minute, unfortunate addition to my mail, that was meant jokingly - but now on reading it again I can see it does not reflect my true purpose, which has been to put an end to respective sarcasm and ire. Sincerely ! That more was meant to be no less, as in, ok, we're all ignorants, let's live with the fact and do our best to learn from one another. Oh, well... I retire the phrase and beg your pardon. Then again : Let's forget /name calling/ ? If you agree, I'm your man Concerning the subject - locating the main env immediately above the small 3 K ? block of FreeCom's PSP, I honestly cannot discern whether you are seriously in want of explanations or only asking in jest. It is not complicated, at least from an ASM programmer's perspective where you can organise your modules at will. Or were you questioning the feasibility from the perspective of or a complex modular 'C' language program ? Then the detailed how is beyond my limited competence, I /suppose/ it might be harder, possibly requiring compiler-dependent variations and /some/ amount of 'glue' coded in ASM. Coding details are not to derail this mail list, you'll agree. We might dig down slightly deeper in private email, or on the developers' list if it's of interest to the community. not rocket science. But as they say, the devil is in the details .. it looks like a real experienced programmer (you) has to show us confused youngsters how it should be done! I'm deep impressed. we have a black belt grandmaster on visit. unfortunately too busy to work, but we are so happy to receive good advice ;) I can take sarcasm still :=) There are even other enhancements that could be made in the same domain, an easy one is to give back the /initial/ environment Retiring this as already done by FreeCOM (yeah!) I have no idea why MS-Command doesn't , 4DOS neither. In particular, when one of those other Command's is the primary shell in MS-DOS 6+, the intial env block inherited from config.sys, is retained which causes incompatibilities with some older DOS programs. Bye ! -- Czerno -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom)
Hi again, Tom... that's how 'edit the parent/master environment' utilities work(ed), it's 'documented undocumented' behaviour, and FreeCOM behaves and has to behave) the same way. It's a good point, but it was not written in stone. Thus it is nice - for our purpose - that FreeCM taking compatibility to heart, adheres to this one :=) It will be nicer when compatibility applies to the placement of the ENV, too ! 'data' with some internal variable pointing to it, the master environment would be obviously swapped out (or located at :) I'm not certain the HMA would be an adequate container for, say, a a master ENV which could be 32 kilobytes large, say... See you... -- Czerno .. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Tom Ehlert wrote : sure your particular problem could be solved by freecom, but nobody will spend time on this. Still, Rugxulo, I think, has suggested one could ping Bart Oldemann with the question. Now, after you have pointed out very plausibly that FreeCOM does not hold hidden pointers to the master ENV, I must admit I do not see the point originally made as crucial any more. it can be solved as well or better by a small external utility; just have the first line in autoexec.bat be ENVLOW.EXE. Is that found in the FreeDOS distro ? Don't bother, I'll g00gle it... This list's Macej brewed his own tiny, simple mover and sent a copy for me to play with (thanks Macej).. It's amusing, but needs to be run several times in a row to get a chance to relocate the ENV properly :=) and moving program code around is probably easier in ASM then in C Undoubtably even better: you can do it yourself without learning C ;) Great relief, that! C was not around when I educated myself to programming in the 50s - early 60s,.by the way. I intend to do mine indeed - unless the envlow you mentionned is doing the job. Macej's is good as a proof of concept but does not quite do what I want done, which is leave no hole after it. DOS memory ought not to look like Swiss cheese (gruyere) Hmm, question may be considered closed for the moment being. Cheers -- Czerno -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi, Eric Auer ! PS: XBDA and moving it is not necessarily trivial. Our EBDA mover is working flawlessly AFAICT.Old code of mine actually, written for MSDOS 5+ before MS introduced the switches=/E option (or before I was aware of the switch?). Last week when I had discovered that the respective FreeDOS kernel's switches doesn't work (see below), we merged in new code to deal with it. My and the project's intention as a way to somehow repay in part what FreeDOS is giving us was to offer this generic MSDOS+FreeDOS EBDA mover for inclusion at the FD repositories as soon as all the project's people has had a chance to field tested the release candidate on as many DOS machines and configurations as they can. I must say, though, the reception which I got from Herr Ehlert on this list is making me wonder whether spontaneous contributions made in good faith are welcome and / or opportune. maybe Tom does not have the patience to explain you why there are good reasons why FreeDOS does things the way they are done, but you can trust him :-) As in, I should /trust/ someone blindly who /starts/ interacting by affirming that I /do not understand/ the point ? Which is funny because, as much as I claim I /do not/ grasp the C language, I will claim having a /good/ understanding of DOS's memory management, the API and the 'innards' as well, and even the implementation quirks (Microsoft's). So I /might/ take offence of what you call, mildly, Tom's lack of patience. Further to stating that I Czerno do not understand, and that he Tom does not care about your users, I have yet to read Herr Ehlert's statement of why it would be (dangerous? unwelcome?) for Freecom to allocate the master environment block in low memory using first fit. I'm open and ready to accept sound reasons, which must be FreeCOM specific then, just not the you wouldn't be happy stance ! Am I bizarre ? XMS swapping is done by FreeCOM, not the kernel... Indeed, my typo. SWITCHES = /E directive in Config.sys is ignored silently CfgSwitches says: ... /* allowed values: [48..1024] bytes, multiples of 16 ... You also want to read some of the related code. You are right that there is no feedback telling you step by step what happens with the EBDA, but making the kernel that verbose would also make it unnecessarily large. Well, I won't enter into that code in detail - I don't do *C*, remember ! but the FreeDOS kernel mover /does not work/ on *real* machines, ours /does/ work ;=) At first sight, FreeDOS makes assumptions which are much too restrictive (in present days, XBDAs are over 1 k byte in length, 6 kilobytes aren't rare.) Is there a FreeCOM 'blueprint' or design document for FreeCOM other than the code comments ? There are some text files, wiki / homepage documents... But generally speaking: If it is not part of the source download, it is probably not included. This is a problem with many projects of course. Well... the project which I keep mentionning won't include a COMMAND processor in the final distribution as self sufficient bootable images for a floppy or USB key. The final user may want to add one and we certainly want a command shell during project building. I'll be recommending 4DOS for internal use - license allowing. In case a future version of FreeCOM finally can be persuaded to locate the ENV low, like MS and all other Command.com flavours rightly do, shall we reconsider. Kind regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Bertho ???, You may call me Czerno, Herr Ehlert You can't escape having to explain what adverse effects you were evoking, now anyway. command.com is a 'normal' program. just allocating DOS memory will give you an environment at ~1800:0. not such a good idea. You are joking, Herr Ehlert, richtig ? Launching a basic FreeDOS+FreeCOM virtual machine while I'm typing... No upper memory. Using (Jack Ellis's, I think ) XMGR.SYS. MEM /D indicates the ENV would be at *526:0*, /not/ such a /bad idea/. And this is /with/ VMware's BIOS 5 kilobytes EBDA relocated low, mind you. Of course the kernel is in HMA, which may be what your reply eluded ! And EVEN if for some reason HMA was not available or not given to the DOS kernel, what makes you deem an environment at ~1800:0 not such a good idea ? I this all your deep reason for forcing the master ENV up at 9 ? In which way other than your respectable personal preference is it better? This is highly ridiculous. At least provide a choice. Leave it to power /users/ to determine for themselves what memory layout is best in /their/ situation. Ah, but - sorry, I was forgetting - you /don't care/ much about your users. No wonder you don't have many. usually ~9f00:0 is a much better place. and juggling memory around (beyond what is already done) was so far never necessary (and still isn't) How do you say arrogance in German, Herr /Doktor/ Ehlert ? Wiedersehen -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
You may call me Czerno, Herr Ehlert your email signature reads Bertho Grandpied y31415926536@... that translates to Bob Bigfoot, right ? Ask Yahoo!... Then if you insist on calling me Bertho, be my guest. And EVEN if for some reason HMA was not available or not given to the DOS kernel, what makes you deem an environment at ~1800:0 not such a good idea ? you would end up with 3 K COMMAND.COM, (resident part) 100 K FREE (remainders of freecom before resizing) 1 K command.com environment (at ~1800:0) How lame ! Of course, your Freecom shall have to play a minimum game of releasing its own initialisation code and data, resizing and possibly moving things along. Basic DOS system coding skills, not rocket science. This is/the/ official shell we are talking of, not some half baked throwable transient proggy, it deserves having a minimum of /intelligent design/ applied :=) There are even other enhancements that could be made in the same domain, an easy one is to give back the /initial/ environment (if any) received by your Command from its caller (or from Sysinit). It is of no use after the Master ENV is built. Freeing it would give FreeDOS an edge over MS Command. But the important is the above. You (or was it Eric) repeated that FreeCOM had to follow MS-Command, but in this respect it doesn't even start to try, I am /sorry/ to observe. What is the legal status of 4DOS in relation to FreeDOS ? There's a fully baked product, could it become /the/ main FD shell ? How do you say arrogance in German, Herr /Doktor/ Ehlert ? Arroganz. Itself ! I may sound harsh, but being accused of ignorance by more ignorant is the only word of excuse I will utter. Let's forget /name calling/ ? If you agree, I'm your man -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Att: Rugxulo Hi, Patience, young padawan. I had to look that padawan up on wOOkipedia (not a typo!) :=) http://starwars.wikia.com/wiki/Padawan Things like this take time and thought (and research and testing). Accepted. I've passed the message, now letting things ripen (and tone down) as appropriate. If you draw up a patch and it isn't accepted upstream into SVN, I can still mirror it somewhere (e.g. iBiblio) for you. I'm afraid no patch to FreeCOM is likely will be coming from me, for reasons already stated and rehashed. Should OTOH you (and the FreeDOS project at large) wish to offer the free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll contact you for arranging the mirroring. It's a simple, robust and tiny DOS device driver coded in ASM, a few hundred bytes altogether. maybe Tom does not have the patience to explain you why there are good reasons why FreeDOS does things the way they are done, but you can trust him :-) (...) Give him the benefit of the doubt, as he is one of the resident experts around here who has contributed a lot. I think I did give the, whatever, benefit - but maybe it was not apparent ? But even the smartest person in the world gets tired, too busy with real life, or just forgets some minor details from years ago. Sure. but the smartest person in the world won't convince me s/he cannot discard 100 K of temporary code/data and do some memory resizing, move part of itself out of the way if need be - before allocating memory. It's not exactly a beginning programmer's task, nor is it rocket science either. [...] want a command shell during project building. I'll be recommending 4DOS for internal use - license allowing. 4DOS is ambiguously licensed. I don't really recommend it, though there aren't a lot of full shell replacements available. If you can avoid some (most?) .BAT internal stuff, you may find it easier to replace: I /love/ 4DOS - been using it for 20 years - used to be NDOS. For internal use, it must be OK, right ? The question wrt to licensing was rather whether 4DOS.COM could be legally envisaged to become FreeCOM as FreeDOS official, or alternate official? shell. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/contrib/ Again, I take this to mean that (admittedly) FreeCOM is too hard to rebuild (preferably with TurboC). If you need help with this, feel free to try and ask specifically for assistance. Having never written a line in C makes it a no-no for myself, and no programmer on their small team will take an interest in what is outside the realm of the project. (It's definitely what I would call slightly annoying, but it's definitely not impossible to rebuild either.) Rebuilding is one thing, patching and debugging properly is another. This task takes a motivated, seasoned C programmer, who preferably were familiar already with FreeCOM. All I can do is try to argue it, knowing well it's a possibility that no one will be convinced and undertake it. On the other hand, if FreeCOM hasn't been revised since 2001, maybe it's not to early for 'someone' to give the old code a look and some fresh thought. Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1
Hi, Matej Horvat: I've spent the last three hours writing a tiny COM program that moves COMMAND.COM's environment block to the lowest address possible (using DOS's low memory first fit strategy). Nice ! Unfortunately, it does not seem to be able to find the environment block if used in AUTOEXEC.BAT after HIMEMX and JEMM386 were loaded in FDCONFIG.SYS (I only tested both at the same time, so I don't know which one causes the problem), My bet would be on JEMM as the one which messes with memory control blocks. but it works if run after AUTOEXEC.BAT has been processed (for some reason - but by then you may have TSRs loaded between COMMAND.COM and its environment, which may or may not be OK for your needs) or if those two drivers are not loaded. Yup. TSRs which are never unloaded would not be a problem, otherwise they could leave holes, but that's life... One could even re-run your program and try to relocate the ENV again into such a hole, if it's big enough :=) So for example, without HIMEMX and JEMM386, FreeCOM will allocate its environment block at e. g. segment 9F7F, but after running the program, the environment block will reside at segment 23B4, almost immediately after COMMAND.COM (it depends on the order in which you load TSRs). Thanks. It would work indeed because - as I was checking a few minutes before reading your mail - FreeCOM does maintain the master environment pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems to use the contents of that 'slot', not some copy it made, whenever it needs to access the ENV. At least a search (using debug!) did not find the environment segment, as data, inside FreeCOM's live memory. Of course it could be keeping the live ENV's segment in registers, but since that is C it's dubious registers are used for long time storage (contrary to what ASM code does profusely, at least mine). Of course, I presume your program does care to adjust the PSP:3C pointer. Please contact me off-list if you want to try it out. Well, thank you. A fully satisfactory solution ought to come from FreeCOM's initialisation itself, though. Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment
Bret Johnson wrote : From my perspective, whether the XBDA, master environment, or anything else is at the top of memory instead of the bottom shouldn't make any difference, as long as there's an MCB to identify and protect it. I see... following a very famous lead, you think that 640 kilo bytes are more DOS memory than anybody will ever want :=) your project doesn't like it, it sounds like it may be taking shortcuts or making assumptions that aren't necessarily true. The project, on which I'm a mere advisor, won't be affected, I believe, since it won't use FreeCOM in its definitive state. It's not my project,which is why I don't feel at liberty to talk more about it :-( I know FreeDOS doesn't (or at least didn't) create MCB's like it should when using the INSTALL= option in CONFIG.SYS, which has caused me some grief in the past. An interesting bit to keep in mind about FreeDOS. But it is quite different situations, your point is a property or quirk of FreeDOS system initialisation, while my report is concerned with FreeCOM - a comand interpreter, which, BTW, is not logically constrained to run in *Free*DOS. MS-DOS doesn't need the workaround. Right. However its treatment of INSTALL=ed programs is not beyond reproach either. I don't know if a workaround for your project could do something similar or not. I hardly see how a regular program launched by FreeCOM could relocate FreeCOM's master environment in a safe and generic enough way, that is to say, without runtime patching FreeCOM at specific, version dependent address(es). FreeCOM is what needs a fix IMnsHO. I suspect it is not a complicated one, and were I half proficient in the C language had a compiling chain ready I would gladly tackle the task. Unfortunately C was not even on the screen of the radar when I practised (a number of interesting) programming languages back in my youth. Cheers, -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Tom, How many users do you have ? I have no idea - and don't care. Of these, how many understands this level of detail, /and/ in addition, will care ? answering this question would imply that /you/ understand the problem. you don't. Now, is that not arrogance ! This kind of remarks is best avoided, it is not a way to prove your competence which has not been disputed anyway. I just wrote the code to put the environment where it is (in 2001), that's all. and it's placed where it is for a *very* good reason. just think a bit about it If there is such a reason, you should be able to state it, for the benefit of us all who are not geniuses like you. Please *enlighten* me ! the FreeDOS kernel relocates the XBDA. Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by default. this is either a bug, or your XBDA behaves somewhat different. An XBDA is an XBDA is an XBDA, furthermore this is observed on more than one machine. Im using a kernel v. 2040 with XMS swapping compiled in. An SWITCHES = /E directive in Config.sys is ignored silently - no error flagged. My conclusion has been that the option was reserved but unimplemented. Is kernel 2041 different in this respect ? an unrelated story. Agreed. Why these latter limits would be thus hard-coded is beyond me. b7ff is shorter then 'the highest location in conventional memory' Really ? 80x86 systems /other/ than the standard Wintel PC (a moving goal anyway) should be able to run a DOS efficiently. Think out of the matrix! let's not be formatted by years of IBM/Microsoft/Intel/PCI-SIG...whoever's... idea of what a PC/DOS machine must be like. Rant and digression over. ... Snipping repetitive stuff... Casually peeking at Freecom source, branch MAIN, init.c v 1.31, ... I'm not sure what is to be gained by using 'lastfit' even in upper memory. ... Hoping someone will take the challenge, left as an exercise to the reader. suffice it to say: you wouldn't like the adverse effects. Is there a FreeCOM 'blueprint' or design document for FreeCOM other than the code comments ? You can't escape having to explain what adverse effects you were evoking, now anyway. Bye ! -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment
Guys... Casually peeking at Freecom source, branch MAIN, init.c v 1.31, Freecom's rev 1.31 (Excerpt, from Sourceforge CVS, w/ line numbers) [code] 437 env_resizeCtrl |= ENV_USEUMB | ENV_ALLOWMOVE | ENV_LASTFIT; 438 if(forceLow) 439 env_resizeCtrl = ~ENV_USEUMB; 440 if(newEnvSize 16 newEnvSize 32767) 441 env_setsize(0, newEnvSize); [/code] et caetera, etc... I'm not an expert in C, not even close to a novice... With this duly noted, it appears it won't be hard for you Freecom code contributors / revewers (is this not you, Tom E.?) to edit the above module and possibly a handful of dependencies so that FreeCOM eventually will request the environment block using Firstfit instead of Lastfit strategy, at least when allocating from low memory. I don't care as much if it uses lastfit when the request is effectively UMBs only, although I'm not sure what is to be gained by using 'lastfit' even in upper memory. Hoping someone will take the challenge, w/ respect -- Cerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
In composing this reply from the terrible Yahoo! web mail, I'll be trying to /force/ hard end-of-lines, not flowed lines, at long last! fingers crossed. On Thu, 4 Jul 2013 dmccunney dennis.mccun...@gmail.com wrote: Placing the environment at the top of conventional memory is what MS-DOS COMMAND.COM did, and FreeDOS tries to be DOS compatible. With all due respect, you must be mistaken :-( I've used almost all versions of Microsoft from 3.2 to 8 (and assorted DRDOS versions also). They - or rather their 'command.com' always have asked for the /lowest available/ DOS memory block for their master environment, which is to say practically always the env has been immediately above the program itself. I've /never/ seen a compatible command.com, including 4DOS, use that alternate allocation strategy which you claim, incorrectly, was DOS's default ! Maybe, just maybe, your confusion arises from the Microsoft Command interpreter's internal use of the top of the TPA for its data (but /without/ any MCB reservation! When control is returned from a transient, they *check* for possible memory corruption in the unprotected are by way of a control sum). This is nothing to do with the environment anyway. I never had a problem because of it. One thing I used to run on my old PC XT clone under MS-DOS 3.3 and 5.0 was a freeware utility form Chris (CED) Dunford. It could map unused video memory in the segment above 640K to DOS conventional memory. Yep this is the kind of things you could do, although VGA memory was exceedingly /slow/ for executing programs from, nowadays we would map the memory in better ways - using EMM 4.0 for instance, or (with some chipsets) remapped physical memory even in CPU /real mode/. You never had a problem... precisely because you were using MS-DOS 3.3 and 5.0 at the time, giving you an uninterrupted 640+96=736 k bytes of '(un)conventional' memory ! With FreeCom's environment (and/or an XBDA) in the way, you'd have been much less happy. Although you'd still got that extra memory, it would've been fragmented hence much less appealing. COMMAND.COM putting the master environment at the top of conventional memory It didn't ! While it might be nice to relocate the master environment block elsewhere, like upper memory, it's hardly necessary. This is not what I'm requesting. I'm strongly suggesting that FreeDOS should locate the master environment it creates in a way compatible to MSDOS and thanks to your kind reply I do understand the reason it is not compatible, currently, is rather a misunderstanding than any legitimate design decision. Apologies if this sounds rude, it's not meant to be ! Kind regards -- Ninho -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
Hi Tom ! I'm surprised you have to question this! after ~12 years without anybody complaining, I'm surprised about you complaining. How many users do you have ? Of these, how many understands this level of detail, /and/ in addition, will care ? Methinks you were p.ssed off by my remarks, but there is nothing personal to them. Who is , or are, the 'appointed maintainer(s)' for FreeCOM ? Are you one of them ? Tis bad because the block in question exceedingly ill-placed (...) Of course the default placement of an XBDA (...) deserves the same blame but either the kernel or some utility will routinely relocate it down during Config.sys processing. the FreeDOS kernel relocates the XBDA. Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by default. Pray tell how, if there is a way, you tell the kernel to do the down move; despite what some doc says on the FreeDOS site, the switches=/E command does not work (but it does in MS-DOS). Not that I need it, we've written our own EBDA mover. *then* config.sys processing happens; possibly some driver maps a000- b7ff as conventional memory *then* comes command.com, and maps it's environment as high as possible. if b7ff is available, it will load it's environment there. if ef00 is available, it's loaded there. Why these latter limits would be thus hard-coded is beyond me. But never mind for the moment In these posts I am NOT meaning to consider UMBs. I should not have mentioned upper memory even tangentialy. Let's limit ourselves to a DOS on an AT-compatible system which is not capable of supporting UMBs - or that we do not want to configure for UMBs anyway. That is, basic DOS system with 640 k conventional memory. it looks like you have a particular strange setup that you are disturbed by command's environment. maybe you are mapping memory in/out dynamically ? Let the setup be as defined above, a compativle with no 'upper' RAM. under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. don't make things up I'm not making thins up, you needn't make derogatory comments. Then, that was off-topic and as I did write, unconfirmed. Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. sure. execute such programs, and you deserve no better. CtrlAltDelete will clean up ;) LOL. Admittedly the argument was far fetched. None the less, this is how MS does it). it was easier to do it the way it is, and so far nobody complained. HA ! Sincerity itself, at last! Now this I /can/ understand, and even sympathise with :=) Not in line with what Dennis wrote, though... that's a pretty good design decision. Only for so long as no one disputes it :=)... FreeCOM can't claim MS-Command.com compatibility until time it has an option, and I would suggest, the /default/, to allocate the master env block from the bottom, instead of the top of conventional mem. Besides, I hardly see how it was easier, your word, for FreeCOM to do it in the current way. I'd rather suspect whoever made the decision, back when, was confused, similar to how DM Cunney remained somehow apparently confused to this day. Optionally relocate to an available UMB. already done (in 2001). I know, a good thing - but not the question. Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Fw : (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ?
Dear List, I'm forwarding a new copy of a programmer's question I sent yesterday to Freedos-devel but for some reason apparently didn't reach to the list server - maybe stalled somewhere, or awaiting processing by the US NSA ? Of course there is a risk that you guys will suffer receiving 2 or more copies, in advance of which I send my most sincere apology. --- On Thursday, 7.4.13, Bertho Grandpied y31415926...@yahoo.fr a wrote : Objet: (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ? Programmers, Kernel people, hi ! What is (are) the recommended way(s) to assert programmatically one is running under FreeDOS, versus other common DOS brands and versions ? Precisions : - I am going for the simplest, yet reliable identification method. The problem posed here is to /reliably/ single out FreeDOS from foreign DOSes, NOT necessarily to get at FreeDOS (sub)version numbers (real or faked!). - Method should work in any reasonably current versions of FreeDOS - say 0.9, 1.0 and 1.1, whatever compilation options, and also be future proof w/ respect to FreeDOS, if possible. - Must be available at system initialisation time (callable from a device driver's 'init' routine, that is). Requirement 1 - simplicity - suggests that we should use a FreeDOS-kernel-specific API, if such exists. But reliability of the detection is /primordial/, so, if reliabity means we have to 'peek' into the kernel and 'walk' binary structures, so be it. Of course we can't trust blandly the general documented DOS API calls for version or even true ver, can we ? I believe true ver /should/ not lie but I also think (may be wrongly) that FreeDOS truever /does/ lie in certain circumstances, unfortunately. Obviously I could hack-and-design something by myself, however I would much much preffer to do things in the sanctionned way whenever possible. Thanks in advance. If this is documented well somewhere, a pointer will do for an answer. -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment
On Fri, 5 Jul 2013 15:45:34 GMT Bret Johnson bretj...@juno.com Hi Bret ! (long time, no see...) ... a user who is able, one way or another, to have usable RAM mapped above the 640 k so-called limit into the video memory' segments, up to 736 k (B7FFF), will be forced to use the added memory as UMBs instead of an extension of *contiguous* so-called conventional mem. Is this what you're trying to do (get more than 640k without using UMB's), and why you don't like the XBDA / master environment being at the top of conventional memory? I was giving this as one example of why FreeDOS having relegated the master environment copy to the top of conventional mem /can/ break things. I could have given quite different examples, nor exaples I could name old programs still available which were written as early as the times of MS DOS 2 (!) with the implied assumption that Command's env block follows immediately above its PSP's block. The exact reason which made me stumble on this non-conformity of FreeCOM's does not need to be discussed in detail, it is complex and would derail the discussion. Fact is, some project someone else is building has elected to use a FreeDOS boot disk for a basis, and this bizarre, unmotivated, design of FreeCOM definitely interferes negatively with some aspects of the project. It isn't ruining all, and we could well use another shell than FreeCOM - in fact, I think the project will be its own shell for a self-contained diskette or USB-stick of sorts. Now see! you've driven me into digressing from my initial purpose here again ;=) Back to FreeCOM : of course we, app programmers, could devise a utility for the purpose of moving that darned environment back to where it belongs, i.e., low contiguous DOS-managed memory. Leaving apart the fact that doing so from a transient DOS program and without leaving holes is not absolutely a trivial programming task, we would be still faced with the problem that, how are we supposed to reliably /find/ and adjust the pointer(s) that of necessity FreeCOM internally keeps to the environment ! Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with debugging, maintaining and enhancing FreeCOM) to provide the solution, be it a command line option, a permanent fix, or even an API. Hoping this could be at least some food for thought, and Taking the leave for now -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment
Hi Eric, this thread seems to mix two topics: Yep, things got mixed, I suppose it's my fault. Consequently I'll try to leavo out - not quote - the bits which, though they may be interesting, I think irrelevant herein (snip...) As Tom already pointed out, the location of the master env in FreeCOM is near the end of the free DOS RAM, but only AFTER you get the chance to load e.g. UMB drivers. And as I must stress once again, I am considering the /alternate/ case, when no UMBs will be provided for DOS use. I have been suggesting that in this case, FreeCOM ought to allocate the block that it reserves for storing the main (1st level) environment area. Similar to what other reference DOSes have done forever (well, starting since MS-DOS 2, I think DOS 1 did not have the concept of environment variables later borrowed from Unix... Also, the FreeDOS kernel allows you to control whether the BIOS XBDA data should be relocated. This was a lateral question, but still : how ? the kernel we use doesn't seem to obey a 'Switches=/E' directive in Config.sys, that is the MS-DOS way. So FreeCOM might differ from MS DOS, but still behave in a good way. I beg to differ vigorously - it behaves in a bad (tm) way. ...this bizarre, unmotivated, design of FreeCOM definitely interferes negatively with some aspects of the project. It isn't ruining all, Bizarre yes, unmotivated no. For example XMS swapping is one very useful feature of the complex FreeCOM memory handling. Like 4DOS by the way. I fail to see what XMS swapping (nice to have) is to do with my critique, though... Back to FreeCOM : of course we, app programmers, could devise a utility for the purpose of moving that darned environment back to where it belongs, i.e., low contiguous DOS-managed memory. It is still obscure to me why that darned environment is so much in the way for your project where it is with FreeCOM...? Suffice it to say it is an impediment to that project, plus a non conformance that will break other DOS apps for no real reason (that I can perceive) Leaving apart the fact that doing so from a transient DOS program and without leaving holes is not absolutely a trivial programming task, we would be still faced with the problem that, how are we supposed to reliably /find/ and adjust the pointer(s) that... FreeCOM internally keeps I may be mistaken, but should not just the PSP point to the environment? You are mistaken indeed. Command's, or FreeCOM's own PSP would point to /its/ initial environment (if there was any established by Config.sys command, as has been possible in /MS/DOS since DOS 6, I know not whether FreeDOS has a similar concept. Let's not digress again!). Thus, the environment pointer inside the command processor's (shell's) PSP is either NUL, else pointing to an initial environment of no significance nor use.(Digressing again, I have been known to free that useless initial environement). /The/ master environment is a brand new one built by Command while it initialises things, and sized according to Command's command line parameters (if this is the primary shell, in turn lifted from the SHELL line in config.sys). Command / FreeCOM has to ask a block from DOS using the usual allocation functions 48h etc, with appropriate choices of strategy. To sum up, repairing FreeCOM may be as simple as it passing the proper allocation strategy, i.e., don't include UMBs + find lowest suitable block as part of its DOS calls reserving that block. to the shell from DOS System initialisation.) Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with debugging, maintaining and enhancing FreeCOM) to provide the solution, be it a command line option, a permanent fix, or even an API. See above. Also, nobody is tasked with FreeCOM, as this is not a commercial product. I meant tasked in the sense of being the official maintainers, not as in paid for doing it. Unfortunately, very few people who are FreeCOM experts are around here recently... On the other hand, maintenance is so slow because there was so little left to improve. Understood. Maybe if whoever is familiar with FreeCOM sources would consider the elements I have tried to provide, they would not find it unsurmountable to repair (or diplomatically, revise) this aspect. Bye ! -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] command.com (Freecom) main environment location
Hi List ! I've seemed to notice Command.com locates its master environment block at the top of conventional memory, just under the video (and under a BIOS defined extended bios data aka EBDA, if any). Is this behaviour user-controllable with some switch while loading FreeCOM ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision overall IMHO, at least not if it can't be overridden :-( Regards -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com (Freecom) main environment location
On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert t...@drivesnapshot.de wrote : I've seemed to notice Command.com locates its master environment block at the top of conventional memory Is this behaviour user-controllable with some switch while loading FreeCOM ? what would be the purpose to change this ? whee would you like to have it ? Or otherwise, depending on the global FDConfig ? I could not find a way to change this - which is not a good design decision why is this not a good design decision ? I'm surprised you have to question this! Tis bad because the block in question exceedingly ill-placed, a user who is able, one way or another, to have usable RAM mapped above the 640 k so-called limit into the video memory' segments, up to 736 k (B7FFF), will be forced to use the added memory as UMBs instead of an extension of *contiguous* so-called conventional mem. Of course the default placement of an XBDA (in case there is one, that is, almost always nowadays) deserves the same blame but either the kernel or some utility will routinely relocate it down during Config.sys processing. We could have a separate utility for relocating Freecom's primary env, but, frankly, the command processor shoud be able take care of it itself. where would you put it and why ? The why has been explained. In addition, under /some but not all/ BIOSes, it seems the presence of a DOS MCB-covered zone under the 'video' area may perturb conventional memory reporting by the API of int 15/E820. Not confirmed. Want more ? OK, additionally, some (admittedly very rude, maybe very old) DOS programs will neglect to check where the memory 'above' them ends, and use any and all BIOS int 12 mem without reservation. for that reason the end of the 'transient program area' should as far as possible coincide with the end of conventional (int 12) memory. To where : by default, or absent DOS-managed UMBs, put it on top of the main FreeDCOM code (this is how MS does it). Optionally relocate to an available UMB. overall IMHO, at least not if it can't be overridden :-( Re-iterating ! -- Czerno -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] false info on the freedos home page?
Hi ! On Tue, 18 Sep 2012 15:29:38 -0500, Rugxulo rugx...@gmail.com wrote: MS-DOS / Win9x forced you to install in the very beginning of the hard drive. Uh ? What have you been smoking ? (smile)... MS-DOS will happily install to any primary partition on the first HD - and boot itself from the standard MBR, no hacking required, provided its partition is active of course. With a little hokus-pokus and alternative boot loaders, MS-DOS could also be persuaded to boot from other kind of partitions (secondary and/or patitions residing on a second disk). I presume you Rugxulo knew this and just were momentarily confused. Or did you mean to say something else, maybe that in default installations, starting from a blank hard disk MS-DOS would end up in the beginning of the disk ? Duh! Anyway, someone had to point this out for the record. -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
On Wed, 23 May 2012 09:22:03 Jack ...@earthlink.net wrote : Subject: Re: [Freedos-user] Virtual floppy change problem You are WRONG, Tom!! Is he ? or are you being RUDE, Jack ? UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. Not Tom, but I'd like to learn from /what exact source/ you got the definition for those bits. They are not universal, and we need look no further for why UIDE floppy caching may fail. Does that reference state that it applies to IBM-PC, PC-XT, PC-AT, PS2... or maybe some BIOSes of some particular brand and/or period ? In any case BIOS data byte [40:48] is /not/ documented in Ralf Brown's files, nor is it in Michael Tischer's book (other than HD/FD related). I have the source listing for a Goupil G5 BIOS ca. 1990 (a very faithful, and one of the rare authorised by IBM, PC-AT clones) - those bits aren't used for disk change lines. An authentic IBM AT BIOS is accessible on the net, I haven't found the need for fetching it, someone might check there also. /Possibly/ those bits were defined as floppy line flags in the PS2 'compatibility' RM BIOS , I have no idea - having checked a PS2 technical manual which unfortunately doesn't have the BDA details. Now, puhlease! don't feel accused - I'm sure you did not make those bits up and that they work in your test machines and even for the bulk of your users . That you wait for users' complaints before checking the soundness of your assumptions is another question entirely. You are entitled to choose any method that works on recent gear if you find it convenient. But rather than pretending to support floppies on the whole range of DOS-capable PCs, and claiming that those that do not conform to your model are junk (or is it the users' fault ?) - you /must/ find a way to programmatically assert that your far from universal method /will/ work and take measures otherwise. IMHO you can't leave it to the (clueless, always...) user to assert his or her PC is not conforming to UIDE's model. Regards -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
Reply to Ralf A. Quint (2012-05-21 00:45) Bertho Grandpied wrote: Raises the question of what a Ramdisk should do in order to properly identify itself to smartdrv... impersonate MS-RAMDRIVE, maybe ;=) For starters, use a media descriptor byte value of 0xFA in the BPB... This may be a good recommendation to make to someone who would write yet another ram drive for DOS systems. However an 'FA' media byte is *not* how MS-Sartdrive, aka Wincache, aka Bambino... would tell a ramdrive from a hard disk partition. Misc notes: - 1. MS-Ramdrive sets its media = F8 2 : contrary to popular belief, a media descriptor = FA *was* used by (some obscure) *real disk gear* known to (MS-)DOS. I suspect a mix of bad faith and lazy coding on behalf of MS, but - whose fault ever it may be, the problem - once recognised! - was easily worked around by explicitly excluding the RD on smartdrive's command line. yeah, that good old Microsoft bashing without hard facts trick, never gets old... :-( A great classic indeed;=) -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
--- En date de : Dim 20.5.12, freedos-user-requ...@lists.sourceforge.net freedos-user-requ...@lists.sourceforge.net a écrit : De: freedos-user-requ...@lists.sourceforge.net freedos-user-requ...@lists.sourceforge.net Objet: Freedos-user Digest, Vol 636, Issue 2 À: freedos-user@lists.sourceforge.net Date: Dimanche 20 mai 2012, 22h41 Send Freedos-user mailing list submissions to freedos-user@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/freedos-user or, via email, send a message with subject or body 'help' to freedos-user-requ...@lists.sourceforge.net You can reach the person managing the list at freedos-user-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Freedos-user digest... Jack ...@earthlink.net wrote : I've been mentioning smartdrive only for the fact that it lets the user explicitly remove one or several drive letters from caching, which is handy in some cases - not just floppies. Can't imagine WHAT cases, and no one has ever asked me to have UIDE cache or not-cache specific drives. Case in point : unless explicitly excluded, MS-not-so-Smart-Drive will happily cache certain RAMdisks (not MS ramdrive) which is counter-productive to say the least. This is very arguably a defect of smartdrive, which I don't expect UIDE can possibly share. I'd like to make a different point since several people have mentioned virtual machines - regarding DOS running in VMs, depending on the specific VM and OS, there may be little point in caching disk access altogether, as 1. some or all disks as seen by the virtualised system may in fact be files or otherwise streams from the host's PoV, and 2. for real devices caching would be done by the host (Linux, Windows, etc.) and/or the VM program anyway. Of course caches could still be used inside of a DOS VM for testing and tweaking DOS configuration, rather than for performance. Nobody is denying your drivers are sweet! THANK you!, after all of the above and all in other posts! You're welcome! (Other posts ? /I/ certainly can't remember bashing you or dissing your most excellent work anytime) -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
From: Ralf A. Quint f...@gmx.net At 02:45 PM 5/20/2012, Bertho Grandpied wrote: Case in point : unless explicitly excluded, MS-not-so-Smart-Drive will happily cache certain RAMdisks (not MS ramdrive) What ramdisks would that be? Your question is challenging my memory big time - I think it was seen with XMSDISK (and cousins thereof) but could've been some other ramdisks. A ramdisk that is properly identifying itself as such should not be cached by Smartdrive, if it doesn't, it is not the fault of Smartdrive... Raises the question of what a Ramdisk should do in order to properly identify itself to smartdrv... impersonate MS-RAMDRIVE, maybe ;=) I suspect a mix of bad faith and lazy coding on behalf of MS, but - whose fault ever it may be, the problem - once recognised! - was easily worked around by explicitly excluding the RD on smartdrive's command line. -- Czerno -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)
Hi, FreeDOS-devel ! Upon C. Masloch's harsh request\\kind invitation, I'm joining Freedos-devel now and shall continue this question here that started in Freedos-user. Apologies to anybody this change of venue may inconvenience. -- On Mon, 20 Feb 2012 11:15:00 PST BretJ bretjohn@***.com wrote in Freedos-user : Bertho Grandpied wrote: Therefore my first interrogation is, what set of device header attributes - and associated functions, including IOCTL codes - must be present /at a minimum/ for letting DOS access the disk properly ? Bret wrote : FWIW, this is what is implemented in my USBDRIVE: 01h - Media Check 02h - Build BIOS Parameter Block 04h - Read 08h - Write 09h - Write with Verification 0Dh - Device Open 0Eh - Device Close 0Fh - Removable Media 11h - Generic IOCTL DOS 3 13h - Generic IOCTL DOS 4+ 17h - Get Logical Device 18h - Set Logical Device 19h - IOCTL Check DOS 5+ USBDRIVE is installed as a TSR instead of in CONFIG.SYS, so doesn't need or support Function 00h (Initialize). I don't know if all of these are actually needed or not, but they are supported. (list of IOctls scrubbed for brevity, cf. Bret's original msg) Well, OK Bret, but this doesn't tell what the minimum set would be (as you conceded). Are the IOCTLs and functions 17,18,19h required ? Since support for these features has to be marked by corresponding bits #7 6 of the driver attribute, it is conceivable that a driver might not provide it. Unless of course DOS refuses to use (old?) drivers which do not advertise these functions. Someone knows ? Bertho Grandpied wrote: - Using a loadable driver for the block device implies DOS won't use /its/ internal buffers, so I don't have to care about DOS own buffers sizing, right ? Wrong. Of course you're right, I wasn't thinking out well. The reason you're even doing this in the first place is because DOS _will_ use its internal buffers. This wouldn't be necessary otherwise. IOW, you should still check the max sector size in the DOS List of Lists before you install yourself to make sure it's 512 bytes, and should refuse to install yourself if it's already 4096. Uh, here I'm confused, not following any more, please elaborate your point. Assuming we've loaded USBASPI.SYS [which provides ector access to the external disk using SCSI commands], my hypothetical driver wishes to support one or more FAT partitions on that external disk. Whether or not DOS has already increased its buffer size up to 4K before my driver loads from CONFIG, the driver had better be loaded or else DOS won't know to access the partition(s). IOW the role of the driver is not /just/ to inform DOS that it might have to adjust its internal buffer size, as you seem to be writing above; rather the main role of the loaded driveris to augment DOS by allowing it to well, read/write files and clusters and sectors to the disk, a feat DOS by itself would be incapable of (neither USB nor SCSI/ASPI existed when DOS was designed, so I guess we might pardon it). What am I missing of your above point ? The only way around this I know of is to install as an IFS (Installable File System / Network) driver, similar to how MSCDEX (and its clones) work. Bertho Grandpied wrote: - Besides, should I consider using the non IBM format bit in driver attribute ? From whatever docs I saw is unclear what non IBM changes exactly in how DOS uses the driver, None of the devices I've ever seen use the IBM format -- it changes the BPB. Probably a dangerous road to go down. Do you mean to say non-IBM ? UIAM again, the IBM (should be called MS) formats are the usual FAT disks. IOW non-IBM is when attribute bit 13 = 1. See a difference in driver function 2 in Ralf Brown's list : FAT sectors aren't transmitted, does it mean a non IBM disk may be non-FAT ? Again, I'm curious if anybody has experience with this unusual case. WHATEVER... Interestingly Novac's DI1000DD.SYS driver has attribute = 68C2 (or 68C0 for disks under 32 Megs). Yes, it's non IBM whatever that means! Regards -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)
Dear List... I'm calling back with respect to the 4k-sector USB disk drive. I'm considering writing a loadable DOS 'block' driver for it, as Eric Auer suggested. My experience with programming DOS driver is unfortunately more on the side of character devices than block, so, please bear with basic questions for a moment if you please. I would like to take the simplest approach possible first, even at the expense of performance. My driver would be little more than a 'shell' around USBASPI.SYS. Therefore my first interrogation is, what set of device header attributes - and associated functions, including IOCTL codes - must be present /at a minimum/ for letting DOS access the disk properly ? - For a tentative and probably naive self answer, could I get away with the driver attribute being all zeroes - and implement functions 0, 1, 2, 4, 8, 9 (alias for fn 8) /only/ ? Assuming this basic set of functions properly implemented, will the device work ? Do we /need/ 0D,0E (open/close) for instance ? - Using a loadable driver for the block device implies DOS won't use /its/ internal buffers, so I don't have to care about DOS own buffers sizing, right ? - Besides, should I consider using the non IBM format bit in driver attribute ? From whatever docs I saw is unclear what non IBM changes exactly in how DOS uses the driver, nor the (dis)advantages of that approach and the requirements it puts on (removes from) the driver. TIA ! -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte
From: Czerno (aka Bertho Grandpied) To: freedos-users Cc: Eric Auer Hi Eric! On the freedos-kernel list, you voiced such opinion about the future of big sector disks: that has low priority imho, as drives with large sectors are a temporary thing, will be gone with GPT partitions. Commenting here, since I'm not suscribed to the kernel list (and won't be, /quia non sum dignus/ : I'm not worthy). That IMO is in error. What is a temporary thing is advanced format /with 512 byte sector emulation/ (AF-512e). 4K (and possibly larger, eventuallly) sectors are going to stay, what will be gone is the emulationion layer. Manufacturers have no interest to reverting to 512 bytes sectors - since 4K sects allows them to advertise higher capacities (albeit much of the additional space is lost slack at the user files level ...) Even more importantly, the move will help the Redmond giant ensure that /all/ non current versions of its W*** OS quicly become unusable for most people of the Earth. I don't foresee them missing the opportunity ;=) Regards -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Replying to Eric Auer e.auer@***.de This refers to the following quote from an earlier 4 kB related mail: I stumbled upon a couple pages that say otherwise : the industry has agreed to sell AF disks only *until the end of 2014*! It was actually you yourself who said that on 25 Jan 2012 ;-) I can't deny I wrote the above - in my haste I omitted the all important e as in AF512-e. What the hard disk industry has agreed to, reportedly, is that they won't put disks without 512-byte-sector emulation on the market before 2015. On the other hand, almost all manufacturers have already switched their processes to produce hard disks with /physical/ 4096 b/sectors. Hitashi is the only important one who has not yet completely converted, I hear. A contrario, they are free to remove the /emulation/ from the firmwares of disks sold starting January, 2015. What they /won't/ be doing is reverting to 512 bytes per sector, that game is over. AF = Advanced Format = 4096 byte per sector, i.e. Advanced meaning if you find 512 byte better, you are not modern :-p Also, advanced format lets more data share less ECC error correction data, squeezing out a tiny bit of extra capacity and a bit of extra resistance to data errors... (skipping MSWindows relative alignment and other considerations ) Manufacturers have no interest to reverting to 512 bytes sectors - since 4K sects allows them to advertise higher capacities No. As Tom said, large sectors are only a workaround for WinXP and similar MBR partitioned operating systems. No, the disk indusctry had been pushing larger sectors for years and it was MS putting the brake until it was ready to deal with them. With GPT, you have no relevant limit to the number of sectors any more and sectors can be small again :-) Yes with GPT (or a revision of MBR with wider sector numbers) they /could/ be small again, but that isn't going to happen. 4K sectors (and possibly larger) are here to remain. Well, until mechanical hard disks disappear. On the other hand, everything is pretty virtual today anyway, and SSD / flash have better performance with access in larger blocks, but that does not mean that block has to equal sector. It could also equal cluster and FORMAT already supports making clusters of 4 kB or bigger align with 4 kB boundaries... ;-) The virtuality will also mean that you eventually have to load a PC BIOS interrupts legacy API module for EFI BIOSes. Luckily those also exist as open source, if vendors get lazy. UEFI is another can of worms (and Intel's implementation is huge and buggy) altogether... Everything is possible but /optional/ and I wouldn't bet PC vendors in general will include the BIOS module in future EFI PCs. No BIOS - no DOS! unless the kernel is deeply revised. PS: As you say you read this on freedos-kernel, but are only on freedos-user (where you mailed) I took the freedom to CC both. Thanks -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte
Hi Dennis! dmccunney dennis*** wrote : (albeit much of the additional space is lost slack at the user files level ...) Slack space will be a real issue? I don't see how. There would be a net loss for partitions sizes and file systems comprised of less than 4K bytes per cluster. You are right, not a big problem, in general. I was repeating what I read, without too much thinking. -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + TDSK
On Sun, 5 Feb 2012, Kenneth Davis jeremyd@***.org wrote : test kernel supporting 4KB sectors, note it limits buffers to 2 to avoid memory corruption on boot. Thanks for testing, Eager to try your kernel mods with real HW, but, there is a but! in order for my Iomega device to be recognised processed by KERNEL.SYS (rather than a specific user installed driver), I need to have USB support with int 13h emulation for that device installed BEFORE booting DOS. A PLoP boot diskette would've been ideal for this, EXCEPT... PLoP does not support other than 512 byte sectors on USB hard disks, at the moment. Actually I'd been in touch with PLoP's developer Elmar even before I suscribed on this mailing list. He renounced or at least postponed doing the changes, unfortunately, arguing a tiny number of prospective users and difficulty of testing over the internet. Maybe you (FreeDOS developers) would like to add your weight to my prayer for Elmar to reconsider ? He doesn't distribute PLoP source code UIAM. And, are you (you all!) aware of some other option ? -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + PLoP
test kernel supporting 4KB sectors, note it limits buffers to 2 to avoid memory corruption on boot. Thanks for testing, By an extraordinary coincidence - I am not making this up ! I received mail from PLoP's developer today, a short time after I had posted the following note to this list : A PLoP boot diskette would've been ideal for this, EXCEPT... PLoP does not support other than 512 byte sectors on USB hard disks, at the moment. Strike that out ! The great news is a new version of PLoP is available for download from http://www.plop.at/en/bootmngrusblog.html now *including /experimental/ support for 4K sectors ! * N.B. Be warned the author writes he doesn't think it works well or has a future. Caveat emptor, then. Also of note, PLoP's license has changed it is now free for use including commercial. Donations will be accepted still? Please watch what Elmar had to say about the change (at the above URL). -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
In reply to: Mark Brown eufdppue@ya???.com you *could* try USBASPI.SYS /V /W followed by DI1000DD.SYS This is what I tried first thing, and the DI1000DD.SYS [Ninja ASPI DISK DRIVER Ver2.00, 16368 bytes, MD5=9C240A5F1848F76893364AB3A26D545F] which I use definitely /won't/ work with 4K sectors. ( works for me ) You lucky boy :=) Now let's sort things out a little, please : - you are 100% positive your USB device presents 4K sectors to the host, NOT 512 byte ones ... are you ? - if you answered yes above, what *exact* version of DI1000DD.SYS have you been using, please ? I've been chasing the rare bird without success. Can you share a link, or the file itself, for testing purposes ? -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + TDSK
This is correcting my mistake, --- On : Tue 2/7/12, Bertho Grandpied y31415926536@y??? wrote : In reply to: Mark Brown you *could* try USBASPI.SYS /V /W followed by DI1000DD.SYS This is what I tried first thing, and the DI1000DD.SYS [Ninja ASPI DISK DRIVER Ver2.00, 16368 bytes, MD5=9C Oooops I took the MD5 from the wrong file (a version I've hacked), the correct 128 bit MD5 for the DI1000DD.SYS here is : MD5=662FF106A2C4012D212E8F99B62EC6E0 Sorry! Hope it helps... -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + PLoP
In reply to: Bernd Blaauw bblaauw@ho... Op 7-2-2012 15:05, Bertho Grandpied schreef: Also of note, PLoP's license has changed it is now free for use including commercial. Donations will be accepted still?. The question mark after the word still was un,intended (a typo). Sorry if it clouded the meaning of my message. I wished to draw attention on the fact that donations from happy users, companies as well as individuals are still accepted. The donation button is quite well hidden, and seems restricted to Paypal only. Vendors like ShareIt(.com) seem to work pretty well if he wants to sell stuff, it even offered the iDeal payment system that's common in the Netherlands (we're not a creditcard culture, sorry). Neither here. 'I never owned a card) I tend to pay for low-cost quality software if no equal free solution exists. Windows and VMware Workstation have been my most expensive purchases, followed by some collector editions of various games. I would gladly donate for PLoP, weren't I deprived of any salary, benefit or whatever income. In any event I'm going to try Elmar's experimental build and shall report the results. -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + TDSK
On Sun, 5 Feb 2012 22:56-0500 Kenneth Davis jeremyd@f***.org wrote : For testing only - warning may corrupt data!!! https://www.fdos.org/kernel/testing/4K/ Got'm alright! For information, had to downgrade URL protocol to HTTP:// (from http per provided link). Not sure if it's a temporary problem at the server or whether the httpS was a typo... Included is a test kernel supporting 4KB sectors, note it limits buffers to 2 to avoid memory corruption on boot. Also there is tdsk 3.2 with patch to allow 4KB sectors assembled with jwasm. source can be found on sf fdos svn - hack to limit buffers to 2 not there but available on request. this kernel is there to allow testing Thanks -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Kenneth J. Davis jeremyd@fd... wrote : Improved support for sectors other than 512 bytes has been committed, I am still working on it, default support will still be for 512 bytes (currently not while testing). I have tested 256, 512, 1024, and 2048 byte sectors with tdsk (currently my only way to test). Using max sector size higher than 3KB sizes corrupt memory chain during init (haven't tracked down yet). Nice move Jeremy ! I'll be sure to test trial it as soon as you are able provide a compiled kernel without the MCB corruption problem You are mentioning the 2K bytes/sector limitation with TDSK : conincidentally I too had the idea of using Ciriaco de Celis's tdsk, which I downlmoaded yesterday from FreedOS repository with an aim of checking (MS)DOS's problems w/ 4K sectors and found this annoying (in the circumstance) TDSK limit. TDSK is maintained by, IIRC, Mathias Paul - isn't Mathias on this list ? If so I was going to ask him if he couldn't do a quick and (not so) dirty build of the ramdisk driver with increased bytes per sector to ,at least, 4K instead of 2 ? Regards -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors + TDSK
Hi, Guys! Replying to self, sort of, and Jeremy at the same time. I've been glancing thru the ram disk, TDSK, source. Internal buffer (used for init only) was provisionned for one 4K sector, but for some reason author(s) limited sector size to 2K, as specified on the driver's command line. I boldly hacked the binary so it ignored the limitation and, behold, a first quick and (very) dirty test of a ~8 MBytes FAT12 based RAM disk *with 4096 byte sectors* in MS-DOS 7.1 with a rather fully loaded config SUCCEEDED! I was able to copy several megabyte files to/from the ramdisk (quick tests did include binary compare fo source to dest, and an examination of the RAMdisk with Norton's DISKEDIT revealed no problems). I'm not affirming yet there are no hidden bugs but, clearly, MSDOS CAN support this type of device with no or little problems ! This to me is great news, since it makes it worth developing a simple ASPI to DOS convertor for use with my external USB disk. MSDOS bugs, if any, may be limited to installing large sectored units which are to be managed by IO/MSDOS.SYS internal disk driver. Jeremy wrote : (currently not while testing). ?I have tested 256, 512, 1024, and 2048 byte sectors with tdsk (currently my only way to test). You may try to force TDSK to allow 4096 bps (not more without recompilation) by nullifying the sanity test for command-line size-of-sector, like I did ! Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Freedos-user Digest, Vol 581, Issue 2
Jeffrey ellsnjel@ao... wrote: Are there any plans for adding a shell escape character(like \ in UNIX) in FreeCOM? Left to be answered by those in the know... If so, what character would be a suitable candidate? If so, I think compatibility to 4DOS should be considered. FYI and IIRC, 4DOS uses the Control-X combo (prints as an up-arrow). You might consider using 4DOS 8 as a direct replacement for FreeCOM. Hth -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Escape character (reposted)
Reposting, reason : corrected Subject line. Apologies for my previous mistake, and for any inconvenience caused by double-mailing. Jeffrey ellsnjel@.. wrote: Are there any plans for adding a shell escape character(like \ in UNIX) in FreeCOM? Left to be answered by those in the know... If so, what character would be a suitable candidate? If so, I think compatibility to 4DOS should be considered. FYI and IIRC, 4DOS uses the Control-X combo (prints as an up-arrow). You might also consider using 4DOS 8 as a direct replacement for FreeCOM. Hth -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] USB/ASPI to DOS, 4K sectors.
Continuation of previous question, subj changed, was: Support for 4k byte sectors Leaving aside (Free)DOS kernel support for bigger HD sectors. Reminder : the following - should fit on one line - is a schematic of what is expected to work : Hard Disk -- USB (4K sectors) -- DOS with usbaspi.sys (ASPI manager) -- didd1000.sys (ASPI to DOS converter) The ASPI to DOS converter is the part that has to adapted, or else redone from scratch. I mm using Novac's excellent DIDD1000.SYS as a reference, unfortunately as distributed that assumes 512 byte sectors for hard disks. After some partial disassembling and study, it seems it is not an easy task to patch DIDD1000 *without access to source code*. The (non essential) int 13 implementation is relatively easy to fix, but the DOS interface (scan partition tables and install DOS volumes; execute DOS driver commands) is problematic, not the least because enlarging some buffer posited in the middle of the driver would offset all data and code situated after said buffer, both during the transient (installation) and permanent phases of the DOS driver's life... Intellectual property and legality matters set apart°, would it be easier to make a new ASPI to DOS, 4K aware converter from scratch ? Or rather, are there usable bases for such an endeavor (free source code) ? ° It is my understanding, in vague terms, that most stringent anti reverse engineering laws allow for independent fixes and enhancements to IP protected code, but IANAL. -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB/ASPI to DOS, 4K sectors.
In reply to: Bernd Blaauw bblaauw@home... Op 29-1-2012 12:21, Bertho Grandpied schreef: Hard Disk -- USB (4K sectors) -- DOS with usbaspi.sys (ASPI manager) -- didd1000.sys (ASPI to DOS converter) (...) The ASPI to DOS converter is the part that has to adapted, or else redone from scratch. I mm using Novac's excellent DIDD1000.SYS as a reference, unfortunately as distributed that assumes 512 byte sectors for hard disks. From scratch would be most likely, I guess Brett's USB drivers could work as a foundation for that, as he mentions int13 (and fdisk) support. We'll hear from Bret again I hope. I don't know if he has a separate SCSI emulation layer or rather a monolithic approach. Not possessing an UHCI controller, I've got no way of experimenting. Finding and purchasing such a controller also seems to get challenging. That, and the lack of EHCI (and higher) speeds is the problem of course with solution based on Bret's present drivers. He has already stated he's currently working on OHCI/UHCI. On the other hand, the USB interface problem is already resolved satisfactorily by USBASPI.SYS (several versions) - at least OHCI/UHCI/EHCI- The USBASPI.SYS I have been using (a Chinese? Yaya DIY hacked Panasonic version 2.27) works well and has no problems dealing with 4K sectors. Hence in this thread I proposed one should concentrate on the part which doesn't work yet with 4K sectors, the ASPI to DOS conversion : the part played by Motto Hairu or Novacs DIDD1000.SYS, or several similar. (...) It is my understanding, in vague terms, that most stringent anti reverse engineering laws allow for independent fixes and enhancements to IP protected code, but IANAL. I don't know about fixes and enhancements, but USA's DMCA aside, usually the cleanest way of writing another implementation of some piece of software is to use cleanroom reverse-engineering: * 1st team studies/disassembles/debugs and documents the program into a specification. * 2nd team creates a piece of software out of this specification Ideally, yes. But how do we DOS lovers recruit and feed those teams ? -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB/ASPI to DOS, 4K sectors - DOS ASPI specification in a nutshell
In reply to: Eric Auer e.a...@...de ... in vague terms, that most stringent anti reverse engineering laws allow for independent fixes and enhancements to IP protected code, but IANAL. You can manipulate software to fix interoperability bugs afair. My understanding too. usually the cleanest way of writing another implementation of some piece of software is to use cleanroom reverse-engineering: * 1st team studies/disassembles/debugs and documents the program into a specification. * 2nd team creates a piece of software out of this specification A much more clean idea: Just read the specs and star programming based on those. No reverse engineering, no voodoo to keep nonfree code out of your driver, because you will simply not touch any :-p ftp://ftp.isu.edu.tw/Hardware/ADAPTEC/adaptec/aspi_dos.ps This (book chapter?) document of only 16 pages describes a list of IOCTLs for ASPI support. Open SCSIMGR$, ioctl read using int 21 function 4402, cx=4, dsdx=pointer to your 4 byte buffer, bx=handle and receive a far pointer to ASPI. (...) Thanks for the reference URL. Actually this API is also well summarized in Ralf Brown's list (at int 21/4402) which is what I used while disassembling/studying the driver, DI1000DD. -- Czerno -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Just a note, Folks, /who/ said advanced format disks (presenting 512 byte sectors) are with us for ten years - or more, so we should be little concerned about having to support true 4K sector disks ? But I stumbled upon a couple pages that say otherwise : the industry has agreed to sell AF disks only *until the end of 2014*! This if true is way shorter than 10 years, and would IMO justify real work done on updating the kernel. I've not kept the links, ooops! but Google is our friend (is it?) By procrastinating one would be doing the same kind of costly mistake than, say, for IPv6 support (lack of it). Regards -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
In reply to : Eric Auer e.a...@de Realising I left away this point of your previous msg : Someone, maybe not Eric, asked what I have been using for accessing USB mass storage in DOS. Answer : a version of Panasonic's USBASPI.SYS. This allows access to 4k sectors using SCSI commands. Interesting, but would that be easier than using Bret's or Georg's USB storage drivers? I had a look at Bret's open source USB drivers, unfortunately they only support Intel/Via (UHCI) controllers yet. I also think they have hard coded 512 bytes per sector. In any case I only own non-Intel based (OHCI/EHCI) so can't use or test Bret's fine work. Haven't looked at Georg's drivers, which are not free/open anyway and annoyingly, the non paid for versions stop working after a few minutes IIUW. As long as somebody explains me how to write and read 4k sectors with those drivers, I should be able to show how to show 512 sectors and a transformed BPB on the DOS side, in that way making FAT32 partitions on that disk useable by unpatched FreeDOS with a simple loadable block device driver in a safe* way. I had success with Panasonic's USBASPI driver, specifically the non official 2.27x USBASPI.SYS (15,491 bytes dieted DOS driver) extracted from : http://www.mdgx.com/files/USBEXFAT.ZIP The download also contains other drivers which you may find interesting, including an USBASPI.EXE (untried by me). I'm making no representations or comment on the legality etc... but this is for education pruposes right ? The thing works for me, provides full ASPI access to the 4K sectors (32bit LBA support) I also made limited experiments with modding the block driver DIDD1000.SYS - the included int 13h provider is easily fixed, but the DOS block device driver proper would require much more disassembling and study than I could afford. Instead efforts should be devoted to writing an open source version. *I cannot stop you from breaking the wonder by reformatting that partition in a non-4k-compatible way, apart from write-protecting the boot sector. You cannot repartition disks through block device drivers anyway, so THAT part is safe. Also, DOSFSCK will be happy (will not notice anything strange) and CHKDSK skips FAT32 anyway. I look forward to seeing a demo from you and hearing from the rest of the gang too ... -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
In reply to: Bret Johnson bretjohn@ju... only support Intel/Via (UHCI) controllers yet. True. Working on that. Great :=) I also think they have hard coded 512 bytes per sector. No. USBDRIVE reads the maximum buffer size from the DOS List of Lists (as discussed some earlier in the thread), and uses that as its maximum sector size. If a USB disk has 4k sectors, but DOS can only handle 512 byte sectors, USBDRIVE won't load the disk. If DOS can handle (buffer) 4k sectors OK, USBDRIVE will load it and automatically mount any FAT partitions it finds. TY for the heads-up. Also as stated earlier, I don't personally have any disks with sector sizes other than 512, so this has never been tested (at least by me) on a real system. It would be a good thing if someone on the list having access to such a device /and/ Intel-based USB would experiment and report their findings... That's why you need to modify the kernel to handle 4k sectors, also as discussed earlier (at least with my drivers). Based on what Eric says, though, that doesn't work with the FreeDOS kernel. As I noted earlier, I'm sure the default disk driver MS DOS kernels can handle bigger sectors, /but/ there are problems to be fixed - as pointed to me by R. Loew, and I verified it too : MSDOS init module (patition scanner) discards partitions whose boot sectors indicate any sector size other than 512. Disks operated through user drivers (config.sys) should not be so limited. While trying a free fix for MSDOS could be attempted - but is the effort worth it ? - I would vote for FreeDOS to be enhanced. Does someone here know if DR/Open DOS recognises 512k sectors, either or both with its built-in disk driver and user drivers ? Because USBDRIVE provides an INT 13h interface, you can also use external drivers to mount/access the non-FAT partitions that may be on the USB disks (NTFS, EXTx, exFAT, ...). USBDRIVE won't mount non-FAT drives automatically, though. Understood. Regards -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
In reply to : Eric Auer e.auer@*.de Hi Bertho, trying to reiterate / re-explain my plan / idea: Fine ! a DRIVER could interface with any disk with any sector size and then just provide an int13 or int25/26 interface with 512 byte sector size for data transfer to DOS. As explained in a longer mail this week, it actually SHOULD work: Only a few values in the boot sector would differ from a native 4k sector FAT filesystem compared to a filesystem where things work in groups of 8 sectors of 512 byte each, which is exactly what you would get when you make a 4k disk I'm not opposed to this method, which I see as a workaround rather than a fully satisfying answer however. You insist on FAT32 compatibility , but what about FAT16 even FAT12 ?(Yes I like having a primary FAT12 partition, 32 MBytes or so, at the start of hard disks. But this is I ...) Alignment of the data (and FAT) sectors is more difficult to achieve for DOS partitions of these types than FAT32. Another potential drawback of the translating driver approach is write thrashing on sector writes unless disk driver does some delayed-write of its own, independent of any higher level cache... further complicating the matter. Finally I need hardly craw attention on a weird effect in the case of the very device which caused me to start this whole subject : the physical Hitachi disk has 512 K sectors, the SATAUSB bridge already does its own 512/4096 conversion (including internal buffering and, I'm not sure but possibly, delaying write back)... your proposed driver would in effect dutifully cancel the packing/unpacking done by the appliance's firmware ! This means you cannot make the RAW DISK visible to DOS that way, but you ONLY have to show DOS a modified boot sector to make the rest of an otherwise unchanged PARTITION work from native 4k sectors into show DOS 512 byte fake sec size. (snipped...) Kind of crippling a device if you ask me. I'm not saying it wouldn't be usable, and certainly better than no access at all - still ISTM the real answer is for the DOS kernel to be able to support native 4k sectors (that limit is also artificial but it seems the right figure at the moment, possibly forever as far as DOS extended lifetime goes; and 4k buffers aren't /that/ expensive, even without a special sparing allocation scheme, provided the number of buffers in fdconfig be kept within reason). Regards -- Czerno -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
On Sat, 14 Jan 2012 Michael B. Brutman wrote : As far as 4K blocks go, I wouldn't worry about it too much. 512 byte sectors will be supported either natively or by emulation in the drive itself for a long time to come - at least 5 to 10 years. Too many existing systems depend on a 512 byte sector and manufacturers are more likely to demand reasonable 512 byte emulation from the hard drive makers than to do anything themselves. I understand this is your and some others' opinion (J.R. Ellis ?) but it is not an exact evaluation of the problem - sure, stand alone SATA/eSATA disks should continue to provide 512-byte sector emulation for some time (though that 5 to 10 years estimate seems rather optimistic... time will tell); but the trend for external appliances is to present 4096-byte sectors ONLY. The appliance I own is a curious case : the actual disk inside is a 1 Terabyte SATA having standard 512 b sectors, but for some reason we can only try to guess - standardisation among a range of disk sizes ? directions from Redmond ? - the USB/SATA converter (bridge) is programmed to present 4096 byte sectors at the USB interface. And this is not changeable, for lack of the specs from either Iomega or the maker of the bridge itself (PLX, formely Oxbridge in this instance). While this is ridiculous, and sad, bet you most new disk appliances on the market are going to conform to this standard soon. Which is a reason the DOS kernel ought to support max_sector_size=4K at least as an special option, IMVHO. I am aware of a set of *commercial* patches to MSDOS which purportedly brings the support into that other DOS kernel (and even in Windows 9x). Having no revenue any more I haven't been able to try R. Loew's patches. Regards -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
Eric Auer e.a...@jpberlin.de wrote : Interestingly, even 3 TB disks are still sold with 512 byte sectors. Conversely, even 1 TB USB disks are already sold with 2048 byte sectors ;=) (...snipping much...) By the way - a DRIVER could interface with any disk with any sector size and then just provide an int13 or int25/26 interface with 512 byte sector size for data transfer to DOS. This scheme won't work if the disk has to be usable aslo in other OSes like Windows XP, Linux, etc. that recognise the 4k sectors natively ! Someone, maybe not Eric, asked what I have been using for accessing USB mass storage in DOS. Answer : a version of Panasonic's USBASPI.SYS. This allows access to 4k sectors using SCSI commands. A DOS driver similar to DI1000DD.SYS would be needed in order to access and mount the partitions. /Of course/ the standard DI1000DD has /hard coded/ 512k sector size for hard disks - but even it it was hacked/rewritten so it would transfer 4k sectors to/from the USBASPI interface, it won't work untill the DOS kernel work buffer and structures are adapted. I'm eager to see this prioritised, even though I am afraid I can't help - never learned C :( Regards -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
In reply to : Michael B. Brutman mbbrut...@brutman.com Michael, So the bottom line is that DOS will probably work just fine when natively attached to storage devices, and that will work for a long time. Appliance storage devices are going to break that if they can't emulate 512 byte sectors. precisely I'm not entirely sure that Linux or Windows will let you create a 512 byte FAT style filesystem on storage that is using larger sectors. These OSes interrogate or test the device and will use its native (apparent) sector size. What you are suggesting won't work unless you're thinking of adding a level of filtering drivers. If they can do that and you want to share data with them on your DOS system by directly reading the storage, then it's time to start writing some device drivers. ;-0 But we'll have to do it the other way around, I'm afraid Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
In response to : Bret Johnson Subj : MSDOS - increasing max sector size ... Likewise, it will ignore disks with sector sizes larger than what DOS says it can handle (this particular detail is part of the easily accessible DOS List of Lists). In the source code for USBDRIVE (starting at line 289 in the latest official release of USBDRIVE.A36), I have a comment that shows you how you can modify MS-DOS and IBM-DOS to handle sector sizes larger than 512 bytes. MSDOS technicalities may be slightly off-topic here :=), anyway... According to Rudolf Loew, increasing maximum sector size in LoL of an unpatched MSDOS will work up to 2048 byte sectors, not 4096 :( I have not verified it for a fact. (Incidentally R. Loew *sells* patches that bring the limit up to 32 kbytes in MSDOS 7.10, claims the author). In your own writing Bret, I think you say you did /not/ try 4k sectors. Too bad! -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
New follow-up ! In response to : Bret Johnson Subj : MSDOS - increasing max sector size quoting myself (sorry!) : According to Rudolf Loew, increasing maximum sector size in LoL of an unpatched MSDOS will work up to 2048 byte sectors, not 4096 :( I have not verified it for a fact. Wow! Never believe someone who's keen on selling something to you : ... Just done a quickie test using a MS-DOS 6.22 boot floppy (with MSDOS.SYS modified accordingly) : it DOES support 4k-byte buffers, contrary to R. Loew's assertion. Both the low work buffer and HMA buffers were 4096 bytes ! DOS seemed to work as usual... I'll have to test in depth for hidden bugs, also must test MS-DOS 7.1 for this (no time now). Shall report to this list - though of course not /directly/ relevant for FreeDOS. (Incidentally R. Loew *sells* patches that bring the limit up to 32 kbytes in MSDOS 7.10, claims the author). -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Hi Bret, Not Bret, but I'll provide answers to 2 of your points. BPB CHS geometry differs - but does a disk with 4096 byte sectors allow CHS based access at all? I hope it does not. you can't preclude it, it may for compatibility sake (at the int 13h interface). (big big snipping) By the way, is the 55aa boot sector thing and similar flags for fsinfo and 2nd stage boot sectors on FAT32 always at the end of the sector or rather just at the end of the first 512 bytes of the sector? The latter, i.e. at the end of the first 512-byte block. Which means a PC BIOS can't boot normally from a medium such as a floppy with /smaller/ than 512 bytes sectors, but /bigger/ sectors are not a problem. Regards -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Dear Freedos-user List ! On Tue, 10 Jan 2012 19:00:30 + (GMT) I wrote : Hi FreeDOS users and developers ! This is my first time posting to these lists, I hope I'm not breaking etiquette in the act. It's been a few days and I'm surprised my first mail hasn't been acknowledged in any way, let alone answered; strange, I've been part of various lists before, usually 'newbies' are greeted rather than ignored altogether. So I'll reiterate and articulate the above question just in case it was not clear : have I done something wrong ? should I try posting to the kernel or developers lists instead ? My question/request is about accepting larger sector sizes for hard disks (whether ATA, USB or otherwise connected). In other words, this is asking what the plan is for the FreeDOS kernel to be able to mount mass storage devices having 4 kilobytes per sector ? As said in previous message, I for one am ready to test development kernels against my USB disk appliance (1 TiB Iomega Prestige). Regards -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re : Support for 4k byte sectors
Hi, Bernd! should I try posting to the kernel or developers lists instead ? Truth is we're not sure, this 4K sector size thing comes in several versions: 1) emulation with aligned 512byte sector emulation 2) emulation with non-aligned 512byte sector emulation 3) native 4K (especially USB bridges apparently) DOS however shouldn't have problems with options #1 2. Number 3 is what I'm concerned with. In other words, this is asking what the plan is for the FreeDOS kernel to be able to mount mass storage devices having 4 kilobytes per sector ? If the disk has traditional BIOS partitioning layout (MBR, primary/logical partitions with FAT16/FAT32 filesystems) then it might be possible for the kernel to work with this as long as it is a data disk. But not so until some changes are made to the kernel I guess - unless I am mistaken, FreeDOS (and MSDOS as well) /assume/ hard disk sectors are 512 bytes. To change this requires reading the real sector sizes from the medium (BPB), also DOS buffers need to be enlarged to accomodate bigger sectors. Booting from a partition without 512byte sector-size is probably more challenging, Will require a 4k-byte-sector aware BIOS (or BIOS 'overlay'), I presume. Anyway booting is not a specific (Free)DOS problem, and not what I'm talking about. let alone guarantee file(-system) integrity and disk manipulating (defragmentation programs, filesystem checkers like CHKDSK and DOSFSCHK). Correct. But first things first, let's attack the kernel - adapting utilities comes later. GPT partitioning scheme isn't supported at all (nor is EFI/UEFI without BIOS emulation). With 4-kbyte sectors a partitionned disk can get as large as 16 terabytes and still use MBR... there's room left before GPT becomes a problem :=) freedos-kernel would be most appropriate list as the developers on there have most expertise. However they're also the ones who are rarely present due to other interests or obligations, so getting answers can take a while. You could also try freedos-devel for this specific technical question but answers might take as long as getting answers on the users list. People usually don't answer if they don't have the correct answer, thus things stay quiet for a while. OK, I am not going to disturb the more specialised lists yet. I'll assume and I hope we'll get word from the interested developer(s) on this here list as soon as he/they have something to say about the question. Thank you for the kind reply. -- Czerno -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
