64-bit numbers on a 32-bit system?

[Red Squirrel]

Is there a feasible way to deal with 64-bit numbers on a 32bit system, preferably in C++?

I need to parse out a csvde AD dump and some of the values such as the last logon datestamp is 64-bit.

 

[DaveSimmons]

MS compilers have the _int64 type (and Int64 in .Net), what C++ are you using?

 

[sourceninja]

the C standard has long long which is an INT of at least 64 bits.

typedef signed long long int64;

 

[Schmide]

Doesn't the date stamp overflow 32bits in 2038? You should be able to just use the lower 32bits, but doesn't this just fall into the time.h functions?

 

[Red Squirrel]

At this point I'll use whatever C++ is easier. I tend to stay away from VC++ and stick to standard and use devc++ but since I'm dealing with AD I might "cheat" and use VC++ as it might even have some AD functions built in. Come to think of it, is there easy ways in C++ to work with AD rather then parse out a dump? I know there's ways to do it in VB but I don't know much VB, I will pickup on C++ much faster if there is an API of some sort I can play with.

I want to be able to programaticly list users who have not logged in in NN days, maybe even delete/disable/move them, add exceptions (ex: don't touch users in a certain OU) and so on.

 

[SunnyD]

In MS land, there's _int64, LARGE_INTEGER, and LONGLONG.

Google mentions something about an int64_t type in <inttypes.h> in conjunction with Dev C++. Mayhap try that?

 

[Ken g6]

Yeah, in Linux Land, int64_t seems to be a macro that maps to the proper type, whether in a 32 or 64-bit OS. It also seems to work in Windows with MinGW. But I don't know about VC++.

 

[Schmide]

I decided to look it up.

SYSTEMTIME Structure

In windows it's 64 bits but it's a structure.

typedef struct _SYSTEMTIME {
  WORD wYear;
  WORD wMonth;
  WORD wDayOfWeek;
  WORD wDay;
  WORD wHour;
  WORD wMinute;
  WORD wSecond;
  WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME;

 

[GeekDrew]

I want to be able to programaticly list users who have not logged in in NN days, maybe even delete/disable/move them, add exceptions (ex: don't touch users in a certain OU) and so on.

Why not use PowerShell scripts? Unless you're just doing this as an exercise, I'd stick to a popular scripting language so that admins can easily read and understand what's about to happen to their AD environment(s).

 

[Nothinman]

Why not use PowerShell scripts? Unless you're just doing this as an exercise, I'd stick to a popular scripting language so that admins can easily read and understand what's about to happen to their AD environment(s).

As much as I hate Pow-Pow-PowerShell it would be a better choice than a custom, compiled binary. VB or JScript would probably be better too since you know those interpreters are already installed on pretty much every Windows machine.

 

[Red Squirrel]

We don't have powershell on our servers, though I will see if we can maybe get it installed. I know hardly anything about it, but from what I have done, it's pretty easy to pickup... so if it does have AD functions, then perfect, it will make my life easier.

 

[Nothinman]

We don't have powershell on our servers, though I will see if we can maybe get it installed. I know hardly anything about it, but from what I have done, it's pretty easy to pickup... so if it does have AD functions, then perfect, it will make my life easier.

You don't need PowerShell on the servers unless you plan on generating your reports, or whatever it is that you're creating, on the servers.