Author Topic: stdlib, system(), & MS-DOS  (Read 8331 times)

Sukaeto

  • *
  • Posts: 570
    • View Profile
    • Sukaeto's web server
stdlib, system(), & MS-DOS
« on: 2004-07-19 23:31:11 »
Not sure weather this should be here or Unrelated . . .

Anyway, we're getting ready to roll out new PCs at the Uni (the order has been placed, they should be in in about 2 weeks.)

Someone had the bass-ackward idea of creating a ghost image for each of the about 2000 Faculty & Staff members' PCs (Don't ask.  Wasn't my idea.  I find it a rather ridiculous waste of time, storage, and bandwidth . . . especially coming from an IT department.) and I've been elected as one of the guys who's gonna make the images.

I'm trying to make this as effortless as possible (to hopefully make it a little less boring and time consuming), so I'm writing a batch file that'll automatically run ghost with the necessary parameters to just make the image without any user intervention (so I can just stick the boot CD in and go on to the next PC.)  The only problem is - figuring out how to get a unique name for each .GHO file.

We're having a bunch of outsource guys come in and take all the old PC's offline, so one of the things we're gonna have them do is rename drive C on each machine as they take it down to whatever the username of the person who uses that particular PC happens to be.

There are two of us working on this automated script, and so far, the other guy's written a little applet that'll look at a text file outputed by the DOS 'vol' command, and grab the name of the volume.  What we now need to do is set an environment variable to that value. (so that we can pass that variable in a batch file to ghost as the name to use for the image.)

I've managed to get the system("command") function in stdlib to run pretty much ANY command except the 'set' command.  It'll run, but won't set/change any environment variables.  I've also tried putenv("variable=value") with the same result (app runs, no change in env var.)

I guess I'm just wondering if any of you guys have any experience with these functions, or maybe another (probably better) idea for getting the username into a env variable to use in a batch file.  The boot discs I'll be using are modified Bart Network Boot CDs, using Win98.  (now, I've been trying to set the variable on a Win2k box . . . I'm thinking maybe, JUST MAYBE, it'll work in 98 . . . but hey, this IS Microsoft we're talking about here.)[/i]

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #1 on: 2004-07-20 00:21:42 »
Pull a BOFH.

BOFH = Bastard Operator from Hell

Micky

  • *
  • Posts: 300
    • View Profile
stdlib, system(), & MS-DOS
« Reply #2 on: 2004-07-20 06:57:43 »
Not really FF7 tech-related... but environment variables are a pain in MS-Dos. Because every process that gets created gets its own environment, that gets discarded when the process ends. Any changes are only visible to child processes of the process that made it.
Try to google for it, or look into MSDN. I'm sure there is some way to access windows' top level environment.
One alternative that you could use if you've got a bit more time is make a bootable Knoppix Linux CD. Then you can make the whole process a shell script. Bash is so much more powerful, like you can use the output of one command directly as the parameter or input to another one. You can mount the DOS partitions without problems and you can create an image with "dd".
----
Just a thought, did you try "set" in a shell window to see if you've got the user name already?

Sukaeto

  • *
  • Posts: 570
    • View Profile
    • Sukaeto's web server
stdlib, system(), & MS-DOS
« Reply #3 on: 2004-07-20 13:11:36 »
Quote from: Micky
One alternative that you could use if you've got a bit more time is make a bootable Knoppix Linux CD.[/quoute]

Oh, believe me.  You're talking to a Unix guy here.  That thought actually crossed my mind for a split second (though I don't think Knoppix would've been my first choice).  The problem with that is this University's close minded, slow acting attitude in IT.


Quote from: Micky
Just a thought, did you try "set" in a shell window to see if you've got the user name already?


The disc just boots to a Win9x command prompt, so unfortunately there's no user variable.

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #4 on: 2004-07-20 15:42:36 »
Quote from: Sukaeto
The disc just boots to a Win9x command prompt, so unfortunately there's no user variable.

What about creating a RAM disk, and store on the RAM Disk the Fetched user ID information etc.  The read that information into the enviroment (magically?).  Somewhere in the back of my mind I recall that applications have the option of creating a new environment and can modify the existing environment.

To be honest, using batch is probably not a good idea, perhaps making a compiled binary that handles your job is a better cleaner method, although it means people can't screw it up (darn!)

I suppose they would be against using something like BASH for win32 also?

Cyb

Micky

  • *
  • Posts: 300
    • View Profile
stdlib, system(), & MS-DOS
« Reply #5 on: 2004-07-20 18:38:48 »
Can you use perl or python?

DeadLajik

  • *
  • Posts: 53
    • View Profile
stdlib, system(), & MS-DOS
« Reply #6 on: 2004-07-23 22:04:00 »
Woah??

Do these PCs have the same exact hardware configuation as the old ones? I'm guessing they don't. Otherwise, why get new ones?

Anyways, you are going to have bigger problems once you put those ghosted images back on entirely different hardware. If you're lucky the systems will boot without problems. You will probably encounter at least some problems though with blue screens and/or illegal exceptions as drivers that are on the image look and try to talk to hardware that is no longer there. To me this sounds like a support nightmare.

Hopefully this is not what you are doing but if it is, I would just consider installing anew..

Sukaeto

  • *
  • Posts: 570
    • View Profile
    • Sukaeto's web server
stdlib, system(), & MS-DOS
« Reply #7 on: 2004-08-06 00:44:29 »
I don't mean to beat a dead horse here, but I just thought I'd make an update of what's going on.

I eventually ended up writing a script that created a batch file in the root directory of C:, which ran right before the PC was taken off line.

Everything seemed like it was going fine, until the day all the computers started coming in.

Now, I had inquired about getting a gigabit switch and a gigabit NIC for the 'server' we were uploading the images too.  That request was of course turned down.  I knew the ghosting would be slow with about 13 boxes uploading their image to 1 machine with a 100 Mb connection.  Little did I know just how slow it would actually go.  After almost 24 hours, half of them still had not finished, and the ones that did all seemed to be corrupt when I tried bringing them down on other machines.  I tried reducing the number of PCs, tried adding a few extra boxes to act as servers, and eventually ended up doing about 3 PCs, each crossovered directly into another box.  Ghost is still, for some unknown reason, running slowly.

My supervisor suggested taking a 80 gig drive, and one at a time connecting it to each PC and loading the image directly onto it.  Not gonna go over too well when there's some 1500 PCs that need to be backed up.

SOOOO, I began looking for some alternative solutions, thinking that now they'd be willing to let me try just about anything.  I ended up stumbling upon This guy's site.  I downloaded the ISO and burned it to a CD.

Turns out the thing is pretty easy to configure (well, for me it was anyway.)  Luckily, the NTFS module is included with it (just have to modprobe it in one of the startup scripts.)  I've managed to get smbmount and all of the required libraries on the disk, and somehow got that to work.  Now I'm working on writing a script that'll take all of the contents on /dev/hda1 and put it into a tar.gz file up on a server somewhere (I'm thinkgin about taking 5 or 6 of the new spares and making file servers out of them.  That way I'll only have 2 boxes per server.)  This way, if any user does happen to need something off of his/her old drive, all the guy responsible for retrieving the data will have to do is open that person's archive in Winzip, and find the files.

I don't know how it's gonna go (because frankly, there was no reason for ghost to be running so slowly when those machines were hooked up one on one), but I figured it worth a try.  I'm hoping that it'll end up being alot quicker, and Unix'll end up saving the day.  That way they'll be more apt to let me use it again in the future.

Quote from: DeadLajik
Anyways, you are going to have bigger problems once you put those ghosted images back on entirely different hardware. If you're lucky the systems will boot without problems. You will probably encounter at least some problems though with blue screens and/or illegal exceptions as drivers that are on the image look and try to talk to hardware that is no longer there. To me this sounds like a support nightmare.


No, no . . . you misunderstood.  Those images are not going on the new PCs, they're simply being made as backups (Just in case we have some user somwhere who's not saving stuff in the 'My Documents' directory, and doens't know what it means to back up data).  We'll be keeping a few of the old machines around (they're leased, but apparently some of them were actually bought out by the Uni) that would be used to bring the image down on.

None of that will matter, though, if my way ends up working out. :-D

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #8 on: 2004-08-06 03:21:08 »
Your boss doesn't know jack about networking, does he (or she)?

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #9 on: 2004-08-06 06:09:14 »
Quote from: Sukaeto

My supervisor suggested taking a 80 gig drive, and one at a time connecting it to each PC and loading the image directly onto it.  Not gonna go over too well when there's some 1500 PCs that need to be backed up.

BFI Approach! Brute force but.. Ignorant :)

Quote from: Sukaeto

Turns out the thing is pretty easy to configure (well, for me it was anyway.)  Luckily, the NTFS module is included with it (just have to modprobe it in one of the startup scripts.)  I've managed to get smbmount and all of the required libraries on the disk, and somehow got that to work.  Now I'm working on writing a script that'll take all of the contents on /dev/hda1 and put it into a tar.gz file up on a server somewhere (I'm thinkgin about taking 5 or 6 of the new spares and making file servers out of them.  That way I'll only have 2 boxes per server.)  This way, if any user does happen to need something off of his/her old drive, all the guy responsible for retrieving the data will have to do is open that person's archive in Winzip, and find the files.

I don't know how it's gonna go (because frankly, there was no reason for ghost to be running so slowly when those machines were hooked up one on one), but I figured it worth a try.  I'm hoping that it'll end up being alot quicker, and Unix'll end up saving the day.  That way they'll be more apt to let me use it again in the future.

If you are backing up 13 computers simultaneously you will be killed with network contentions.

SMB sucks as a network protocol.  Win98 hits a peek of 3megs per second. It takes me 20 minutes to move a few gigs worth of files between machines on a router at 100T.  Linux gets ussually 5 to 8M per second windows dogs it at 3 on a machien that's 4 times faster than the Linux box.

Anyhow 13 to one machine isn't going to work. Ever. Because the network bandwidth to the machine is still 100T.   8/13 is about 600K per second.  1 gig Image would take roughly 90 minutes at best. that doesn't include the fact windows is horribly inefficient or network conetention issues etc.  drop the figure to more like 60K/sec and that's more realistic. so you are talking 900 minutes or 15 hours.

Using a more efficient OS and one that is cooperative with the network instead of spammy helps a lot.

Cyb

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #10 on: 2004-08-06 10:48:47 »
Well Linux has a good network stack. That's one of the reasons it is faster for that purpose. Also, the 2.6 kernel has some optimizations in it.

I also hear that FreeBSD has a really good stack, too.

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #11 on: 2004-08-06 14:44:44 »
Quote from: sfx1999
Well Linux has a good network stack. That's one of the reasons it is faster for that purpose. Also, the 2.6 kernel has some optimizations in it.

I also hear that FreeBSD has a really good stack, too.

I believe Linux and BSD use originally the same stack, save BSD has licensing issues and I am not sure how licensing affects how things are developed on BSD.  so they could still be the same TCP/IP system.

Cyb

Sukaeto

  • *
  • Posts: 570
    • View Profile
    • Sukaeto's web server
stdlib, system(), & MS-DOS
« Reply #12 on: 2004-08-06 18:38:22 »
Quote from: Cyberman
Anyhow 13 to one machine isn't going to work. Ever. Because the network bandwidth to the machine is still 100T.   8/13 is about 600K per second.  1 gig Image would take roughly 90 minutes at best. that doesn't include the fact windows is horribly inefficient or network conetention issues etc.  drop the figure to more like 60K/sec and that's more realistic. so you are talking 900 minutes or 15 hours.


See, THAT wasn't really the problem.  The server I was originally uploading to is a brand new file server.  It's got an 800 Gig drive, and APPARENTLY a gigabit line going into it.  The bottleneck was the switch, only uploading at 100 Mb.  As for the spares . . . well, that'swhy I only wanted 2 machines on each of those.

Anyway, I've gotten my little script working (I also figured out how to use exclude files with tar.)  Right now, I've got 6 boxes uploading to the new server.  None of them are connected to the switch in the room here, they're all connected to drops that run directly to the main switches in the server closet (I had to use a few 50 foot cables, and disconnect a few of the un-necessary PC's in the office, but oh well.)  Everything seems to be doing good right now.

I had a few weird cases (ntfs drives wouldn't mount, no matter what I tried.), so I just set them aside.  There's only 2 of them so far, but I'm guessing there'll be a few more.  I'll deal with those last.

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #13 on: 2004-08-07 14:06:12 »
Quote from: Cyberman
I believe Linux and BSD use originally the same stack, save BSD has licensing issues and I am not sure how licensing affects how things are developed on BSD.  so they could still be the same TCP/IP system.

Cyb


I am pretty sure the 2.6 kernel has a new stack. The older BSD license was not GPL compatible (pre 1999) so they most likely had to write one.

As for these licensing issues, I am not sure what you are talking about. Many years ago they had a dispute with the original SCO I believe, but that was a long time ago.

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #14 on: 2004-08-08 04:56:02 »
Quote from: sfx1999
As for these licensing issues, I am not sure what you are talking about. Many years ago they had a dispute with the original SCO I believe, but that was a long time ago.


Hmmmmmm :)

Quote from: sfx1999
I am pretty sure the 2.6 kernel has a new stack. The older BSD license was not GPL compatible (pre 1999) so they most likely had to write one.

You answered your own question honestly SEE here non GPL compatible.  There is another problem in that winriver owns the company that holds the rights to BSD.  I think they are trying to cover things because Linux has eaten there RTOS space a lot for large projects. Anyhow BSD is owned by winriver because the company or group of people originally developing it was bought out  by them.

Cyb - I suppose this means Real Networks may try to buy out the people who developed Vorbis and the like? ;)

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #15 on: 2004-08-10 13:23:41 »
Quote from: Cyberman
There is another problem in that winriver owns the company that holds the rights to BSD.


Bzzzzzzzt! Wrong. The BSD license allows anyone to use its code in a commercial product, provided that they leave the notices in the source files and put a notice in their product that they use it. They also have to take full responsibility for their product.

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #16 on: 2004-08-10 17:09:11 »
Quote from: sfx1999
Quote from: Cyberman
There is another problem in that winriver owns the company that holds the rights to BSD.


Bzzzzzzzt! Wrong. The BSD license allows anyone to use its code in a commercial product, provided that they leave the notices in the source files and put a notice in their product that they use it. They also have to take full responsibility for their product.


Bzzzzzt back?
What are you talking about?
Read it again carefully.
I made no mention they changed there licensing in there.
That doesn't  mean that this cannot become a future problem. Stop reacting and start thinking.  It's just like the licensing of XFree86 changed (and as a consequence lost about 80% of it's sponsership in two weeks).  LICENSING CAN CHANGE, It happens with MS software almost every new release of there software.

Winriver bought the company so they could use BSD as they LIKE since they have a controling intrest. Make sense now?

Cyb

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #17 on: 2004-08-11 13:35:45 »
Are you saying Winriver Systems owns the University of Berkely? Or the FreeBSD foundation (non-profit) or the NetBSD foundation (also non-profit)?

Cyberman

  • *
  • Posts: 1572
    • View Profile
stdlib, system(), & MS-DOS
« Reply #18 on: 2004-08-13 21:55:13 »
Quote from: sfx1999
Are you saying Winriver Systems owns the University of Berkely? Or the FreeBSD foundation (non-profit) or the NetBSD foundation (also non-profit)?

They own the company who have the controling copyrights to FreeBSD.  That's all I am aware of.  What this implies .. I donno.

Cyb

sfx1999

  • *
  • Posts: 1142
    • View Profile
stdlib, system(), & MS-DOS
« Reply #19 on: 2004-08-13 22:32:33 »
Quote from: FreeBSD.com
FreeBSD is a registered trademark of Wind River Systems, Inc. This is expected to change soon.


Oh I see now the name is trademarked by them. The code is not copyrighted by them, though. The code is not copyrighted by just one person. Some are copyrighted by the University of Berkely and some are copyrighted by individuals.